What's Behind the 10x Programmer?
It's not their experience level or choice of programming language. It might have nothing to do with them at all.
I first read about 10x programmers in Peopleware by Tom DeMarco and Timothy Lister. In this classic, the authors summarize a study they ran from 1984 to 1986 to try to uncover the root causes of developer productivity. Their findings are modest, but since then, the myths of 10x programmers have gotten out of hand.
Let’s look at the source.
Even before they started, there had been studies that show that performance at various activities had fallen on similar curves.
The best performer was 2.5x better than the median one.
The top half was an average of 2x better than the bottom half.
And, the best performer was 10x better than the worst one.
So, the source of the 10x number wasn’t Peopleware, but had been a known result of previous studies. Unfortunately, those results aren’t cited in the book, but they do quote a 10x finding from 1981 that was re-published in Software Productivity by Harlan D. Mills. I just ordered it, and I’ll report back after I read it. But, even in that quote, it’s implied that the 10x finding is between the best and worst programmers. When the 10x programmer phrase is being thrown around, I’ve never heard anyone say that they mean 10x better than the worst. And they are usually comparing co-workers, which is also not substantiated in the data.
In their study, DeMarco and Lister specified a small program and asked pairs of programmers at organizations to work in their normal work environments to implement it, using whatever languages and tools they normally used. The pairs of programmers worked independently.
In the entire set of programmers, DeMarco and Lister replicated the results of the prior studies and found that the best did indeed outperform the worst by 10x. But, inside of an organization, the results were highly correlated—the 10x finding was between organizations, not within them.
So, it’s not so much that we have 10x programmers. We have 10x organizations.
And, what set those organizations apart? Lots of quiet, uninterrupted time.
The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.
In addition to collecting data about the programs and how long it took to write them, the authors also collected objective data about the environment, like how quiet it was, the size of the personal space, etc. There was a stark difference between the best and worst environments.
I found out about this first hand when I worked at Trello. I had originally heard about Peopleware from Trello co-founder Joel Spolsky in his blog post about it on Joel on Software:
Ever wonder why everybody at Microsoft gets their own office, with walls and a door that shuts? It’s in there. Why do managers give so much leeway to their teams to get things done? That’s in there too. Why are there so many jelled SWAT teams at Microsoft that are remarkably productive? Mainly because Bill Gates has built a company full of managers who read Peopleware.
And then his follow-up post with his office design:
Most software managers know what good office space would be like, and they know they don’t have it, and can’t have it. Office space seems to be the one thing that nobody can get right and nobody can do anything about.
Well, it’s my own damn company and I can do something about it, so I did.
And he did.
My first week was at Trello was in the NYC office, which was built out a lot like the one in that blog post. I loved spending time there, but I was remote. Luckily, that attitude towards quiet didn’t end at just the space.
Since 2020, remote work has become ubiquitous. This solves the quiet space problem for a lot of people. But, it doesn’t end there. The study from Peopleware didn’t just cite the site, but it was also the noise and interruptions that were facilitated by the facilities. You can work from home and still get interrupted. In companies that went remote without remote practices, that happened a lot because they didn’t have asynchronous work practices. At Trello, we did, and we published a guide about how to do it.
The Peopleware study found a correlation (not a causal relationship) between the environment and productivity, so we don’t know if an organization adopting these practices would actually change anything. It could be that the productivity was in the individual all along and that the organization merely attracted or retained them with their quiet environment. I was certainly attracted to work at Trello based on its reputation of respecting quiet time. But, I’m optimistic that the changing the organization would help, since having an extended flow state has been found to be a key driver of developer productivity.
So, how does understanding the source help you, the programmer who wants to become more productive? For one, you should probably drop the idea that you can become 10x more productive unless you work at literally the worst organization. But, if you have a median job, you could probably become 2.5x more productive by finding a new job where the leadership values quiet time. Maybe a 10x programmer is just one that chooses their job wisely.