The 10x programmer

Ever since the popularization of the software engineering bible, “The Mythical Man Month”, software engineers have loved to debate the merits of one particular concept in the book: The 10x programmer. I can’t remember exactly how it is stated, but something along the lines of the fact that “good” programmers are generally 5-10 times more productive than mediocre programmers.

This claim seems to elicit a wide range of visceral reactions and opinions from all over the spectrum (opinions on the Internet?! gasp). People get really into debating whether this is a thing or not. Just google The Myth of the 10x programmer and you’re sure to get loads of opinions.

Personally, I have never had any trouble believing this to be the case. I consider myself to be a fairly decent developer, but I’ve also had the privilege of working with a few folks that just blew me completely out of the water. Most of these folks now work at the big 3 or a few equally prestigious companies. I have to say that it’s a humbling experience to personally watch (while holding a stopwatch) someone spend 15 minutes to write a program that you were struggling to write for several days! Let’s say that I spent 2 x 8 hour days working on this program. 0.25 hour / 16 hours is a factor of 64 (way more than 10x!) in productivity.

Likewise, I have worked with some folks where I was the one on the 10x side of the equation. I have had situations where I could trivially envision the problem space, knew a wide range of the possible solutions and hammered out a working prototype in the amount of time where the other person was writing up a fundamental question on StackExchange. Knowledge, experience, practice and judgment come together to make some people orders of magnitude more productive programmers than others.

Some people have used sports analogies to describe the scale difference between levels of skill. That metaphor can be helpful, but I do think that this is particular to computational disciplines. The reality is that computers are probably the single tool in the history of the world that one can leverage into multiple orders of magnitude of productivity gain.

There is one concrete example that comes to mind. At my job, we run a complicated web application that provides a front-end for people to download data about climate change. It has a ton of components, many of which we wrote ourselves, and there exist many possibilities for how to set up the system. For our developers, it is imperative that they be able to work on the code in an isolated environment to be able to test their changes, play with the UI, reproduce bugs from production, etc. This is very common, unless you have some serious cowboy coding tendencies in your shop. So generally when people join the team, their #1 task is to set up their development environment.

You would think that this process could be mostly automated, and it is to a large extent. But with so many pieces, things happen. Dependencies get out of sync, or become unavailable, not every base system is the same, yadda yadda yadda. Problems come up and the new team member has to solve them or work around them. So, how fast does it take people to do this?

Our most senior developer can routinely set up a new dev environment (or production environment for that matter) on nearly any system in about an hour. Most of that time is spent waiting for the automated installs to happen.

We had one new hire come on board with quite a bit of past experience and it took this person three full days (21 hours) to get the environment up and running.

We had a university intern come on board with some experience (a lot of experience for a university student) and it took this person the better part of a month to get the environment up and running (20 days x 7 hours = 140 hours).

Now, I’m not criticizing our developers that took 21 and 140 hours to get their dev environments up and running. They have been great programmers for us and have done some incredible work. But I think that it’s very telling that there is an order of magnitude difference between the productivity for this particular task. I believe that there are a lot of other tasks to which you would see a similar response.

And what if we extended this out to another order of magnitude. Let’s suppose that we had someone on our team who didn’t have any training in computer science or software development (formal or informal). Would their productivity drop by another factor of 10, taking 1000 hours or half a year to complete the same task? I really think that that’s within the realm of feasibility.

So not only do I believe that the “myth” of the 10x developer is not a myth, but I believe that it doesn’t just apply to two sets of developers: average and unicorn. There’s a compelling case that the whole distribution of programmer productivity can be described by a power law. On one end of the distribution you have folks that cannot, given an infinite amount of time, complete fundamental programming tasks, and on the other you have folks that can create things that you never even imagined were possible.