codypo

As someone who's spent thousands of hours on our current Pylons codebase, I'm very interested in knowing how difficult it'll be to move my now-legacy Pylons 1.0 apps to the new Pyramid framework. They don't make mention of that. They do say that Pylons 1.0 apps will run within the Pyramid framework through a fallback handler to an existing Pyons app, so we're not hopelessly screwed, but that does sound a little kludgey.

A larger concern of mine is, given the enormous amounts of time and money we've spent on developing for Pylons, why would I port over to Pyramid? Why wouldn't I just port over to a more stable web framework, less likely to deprecate the technology on which our entire business is based? It definitely sounds like a neat framework, but I don't see as much value in neat technology when it shows a disturbing tendency to pull the rug out from under me.

We're big fans of virtualized development environments at my startup. Not only is it very helpful in preventing weird environment-related bugs like the autor states, it's a huge shortcut when it comes to bringing new developers onboard. Rather than have them spend hours tracking down links to all the right versions of your various libraries and installing things in the appropriate order, you hand them your image. For us, setup time for a new developer has gone from about a day to about 30 minutes, and most of that is time spent downloading Virtual Box.

In addition, if you get a little too clever and accidentally wipe out something crucial in your environment, you just spin up a new VM. It's a tremendous timesaver.

I enjoyed the section on creating quality, not quantity, and its emphasis on minimizing variance. I can see how these heuristics could be applied to most startups.

The section on diagnosing should be taken with a grain of salt, though. If your company ever gets to the point where you need to monitor everything at subsecond level to catch problems or analyze and understand every layer of your stack to see how it performs, you've already won. That amount of attention to scalability means your company has a huge base of users. Not only that, it means you have the large and impressive engineering resources to devote to that problem.

That's definitely not my startup, and so the tools described, while definitely useful (and probably fun to build!), aren't anything approaching a priority for me. In the words of the stereotypical Yiddish grandmother, you should be so lucky to have those sorts of problems!

One of my cofounders has a PhD in neuroscience. Whenever I am stuck on a technical issue, he encourages me to get up and exercise for a while. His reasoning is that vigorous activity increases bloodflow to the brain, which in turn leads to creative problem solving.

Anecdotally, this has served me well so far. Our entire architecture came to me during the middle of a hellish session on the treadmill.

Currently reading A Short History of Nearly Everything by Bill Bryson. So far, it's a really charming history of science (and well, everything else), starting from the Big Bang. Bryson has never let me down before.

I just finished Shadow Divers by Robert Kurson. That was an intense book! If you like deep sea adventure or anything U-boat, it's a worthy read.

Not only is it very political, but it forces some baffling decision making.

Assume I have a team of 10 in which 5 are wonderful contributors, and that, due to stack ranking practices, only the top 1/3 of my team gets consideration for big bonuses and promotions. Here, I'm incentivized to immediately hire 5 warm bodies, thus ballooning my team to 15, so that the top 1/3 get the recognition they deserve.

It's actually rational to do that if I'm concerned that those 5 excellent performers will leave without that recognition. The incentives that appear due to stack ranking are really, really bizarre.