I first heard of “10x” software development through the writings of Steve McConnell. Code Complete remains one of my favorite books about writing good software (The Pragmatic Programmer, Writing Solid Code, and The Clean Coder are also on that list). Steve McConnell’s rarely updated blog (titled 10x Software Development, contains the following tagline:
Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell’s thoughts about how to move toward the "10" side of that 10:1 ratio.
This article, and this one, are probably the best views from the McConnell side on 10x. They cover a lot of the studies and anecdotal information about the 10x concept. Although the original study cited a 10-fold difference in productivity and quality between different programmers with the same levels of experience, I use the 10x label to describe those software folks who “merely” differentiate themselves in terms of output and quality significantly more than their peers. While I will use the term “10x” throughout this post for conformance with the topic, it’s not an exact multiplication. For me, the term means, significantly higher output and quality.
Recently, there was a bit of buzz about this article about the Myth of the 10x Engineer. The meat of the article includes some valid criticism of the studies citing 10x Engineers, and as someone who is generally a skeptic, I acknowledge that the studies have holes. I think there are a lot of misconceptions about what a 10x engineer actually is, so the controversy doesn’t surprise me.
The article begins with the following statement:
I was a 10x engineer for 7 months and then I was a 0x engineer for a year and a half. You burn the candle at both ends. You end up with alcoholism and depression. You’re talking about a very small subset of people. And they might end up in divorce and financial ruin. When people think you’re a 10x engineer, they think you have skills that you don’t. You invariably let people down.
The full article (which, by the way, is very nicely written and worth the read) makes a very good case against the validity of the studies about 10x, and includes several statements from the author’s twitter followers supporting the quote above.
Not a Myth?
But I interpret 10x much differently, and think a lot of commenters miss the point. This, in my opinion, is at least partially due to the “10x” label.
But more importantly, 10x isn’t about working 10x as hard. It’s not even about working twice as hard. It’s not about effort. Being 10x (or significantly more impactful, or whatever you want to call it) is about making smart choices and taking care in your work. I’m sure if I were to put fifty similarly proficient developers in a room and ask them each to implement a known set of algorithms or implement well defined functionality into an existing app, or any other task where the problem and solution are largely understood, that there will be some variance in the time it takes each of them to finish the tasks, but the best in the group would maybe be twice as fast as the average – if that.
Where 10x software engineers excel is in adaptive challenges – where the problem may be understood, but the solution is an unknown (and where the problem may change as the solution emerges). 10x engineers recognize patterns, they know when they’ve hit a dead end, and they can zoom from the 10,000 foot big picture down to minutiae and back again in an instant. They aren’t significantly more productive than their peers because they work eighteen hours a day or even because they type at a whirlwind pace. They are more productive because they solve problems 10x faster than their average peer. They are more productive because there’s less waste in their work – they are careful enough to do things right the first time, but have enough breadth of knowledge that they find the correct choice sooner. You can’t make yourself into a 10x engineer by working harder or longer – you make yourself a 10x engineer by studying and practicing your craft, by investing in learning, and by challenging yourself to continuously make better decisions about how you work.
All that said, not everyone needs to be – or can be a 10x – and that’s ok. But I, for one, want (and love) to work with 10x developers so I can learn from them, learn how they learn, and perhaps discover a few tips to improve my own output and value.