1/10X

A classic piece of software lore is the "10X programmer". That is, the difference in productivity between programmers is not just a bit, it's a whole order of magnitude; the best programmers are 10 times more productive than the worst. It's something I'd heard repeated a lot of times, and I kind of assumed it was yet another poorly-supported software development factoid. However, it's actually backed up by a fair bit of evidence, at least by the standards of software development. In fact, the difference may be as high as 20 times.

But those numbers are just nuts. I mean, an average person can probably do a 100m sprint in 15-20 seconds. The current world record is just under 9.6 seconds. If sprinting had the same variation as software, the fastest time would be 10 seconds and the slowest would be 1.6 minutes. And, let's be clear, the studies were not comparing amateurs to professionals, the variation was between professional programmers. Professional sprinters, as opposed to amateurs, are generally expected to have a time close to 10 seconds. The equivalent for sprinting would be something like 1.05X.

Numbers that high suggest something beyond just differences in how long it takes to put code into a computer. 10X says to me that there's an exponential hidden in there somewhere; something that happens early in a project that reinforces itself throughout the life of the project. That something can't be writing code, which is hard but not that hard, but it does sound a lot like design: making decisions about code. Each decision compounds with each new decision, and those decisions have a drastic impact over the productivity of the project.

So I don't think the 10X effect is because good programmers work faster, but rather that they work in a way that avoids making more work. Bad programmers make bad decisions. Those decisions make everything else take longer, and they compound together with future bad decisions. A good programmer can avoid getting into that situation in the first place but, crucially, a good programmer deep into a badly designed program is not going to be 10X anything.

Which means that a better way to think about it is 1/10X. That is, good programmers are able to make things 1/10th as difficult for themselves, and thus do 1/10X the work. Chuck Moore controversially claimed that he could solve a problem in colorForth using 1% of the code it would take someone else to solve it in C. But note the crucial distinction: he didn't say he would take someone else's C and and rewrite it in Forth to be 1% of the size. Rewriting it would make it a bit smaller, sure, but the biggest difference is that he would redesign it.

It's worth thinking beyond software, too. Any situation where your decisions compound with themselves would show similar variation. And the crucial thing is that someone looking and seeing only the most recent decision would say "you're not doing anything that much better, your problems are just easier to solve". But you need to look at the entire chain of decisions; each problem is a consequence of the decisions that come before it. The real trick is to avoid letting your problems become difficult in the first place.