How to get a 10x developer

6 Jan 2020

Pontification  Project Management  Rant 

Originally posted at

Long time readers will note this post as being similarly clickbait as my earlier ‘How to be a Rockstar developer!‘. Don’t worry, hopefully there’s useful information here.

(I’ve been inspired here by Keavy McKinn’s post ‘Thriving on the Technical Leadership Path’, which talks about many good things, but a lot of is about how to make an organisation better, and so get more out of people without breaking them. Also ‘It Doesn’t Have to Be Crazy at Work‘ by Jason Fried and David Heinemeier Hansson, which feels idealistic in places, but there are also a lot of sensible ideas there about one particular way to get more out of people while maintaining sensible work/life balance choices.)

First, let’s clarify what we mean here. A 10x developer is a mythical beast capable of doing 10 times the work of another programmer. This all goes back to a study in 1968 which was mentioned in The Mythical Man-Month (a book I would recommend, despite it’s age). The study was based on getting some programmers to solve some simple problems with code (a numerical sort, finding a path through a maze, etc), and they saw anywhere up to a 20x difference in speed for various parts of the task, with an average difference overall of up to 10x. For this sort of problem it’s not exactly surprising that some were a lot faster than others, because if you’ve done similar things to those sorts of puzzles before then you’re likely to be a lot faster in solving them. but this doesn’t necessarily correlate to how you are with solving different types of problems, which is the core problem in these sorts of observations.

There’s also been the observation that one way to be a 10x developer is to be a jerk. If you’re refusing to go to meetings, don’t parcel out any work to others, and generally make your workplace have to work around you (e.g. Brent in The Phoenix Project to a large extent) then of course you’re 10 times as ‘productive’ (from a ‘lines of code produced’ perspective) as the rest of your team, as you’re dumping work on everyone else. Similarly, if I stopped writing tests I could probably output a lot more code much faster, but it would be laden with tech debt and not as useful. I could maybe get away with it for a bit, but this is very rarely useful (and only with the consented buy-in of your whole team in emergency situations). Most of the time it’s just making today cheaper by pushing the costs to others and/or just my future self.

The idea of the 10x developer is a myth with toxic side-effects, a variant of the ‘hero developer‘ (a similarly toxic myth). Except it’s arguably worse than that.  Imagine that there was a set of developers out there that you could relatively easily identify (at least within a couple of hours of interview) as true 10x developers, and they had none of the downsides I’ve mentioned so far. How could you acquire, keep and usefully use them? Well, your first problem is that you probably don’t have hard enough problems for them to be worth it for you—the majority of problems facing most developers aren’t that hard from a development perspective. The hard parts of the job usually concern people and business requirements (and legacy software that you’re not allowed to abandon, no matter how much you want to), and so you’re probably not willing to pay enough to get someone who can do 10 people’s worth of output.

That’s an entirely sensible perspective, as the restrictions of your business probably wouldn’t actually let a theoretical 10x developer get up to 10x speed—meetings still run at 1x speed, as do code reviews, etc. In theory if you were willing to pay enough for several of these people and had a hard problem to solve (e.g. general purpose distributed databases), you’d figured out how to make money at it and were in a startup situation where speed potentially wins over everything else, then maybe these developers would  be useful. On the other hand, if you’ve figured out how to use them effectively, so can your competitors, and the extent to which you can get them up to that full 10x speed is directly proportional to how much they’re worth to you, which probably means some sort of bidding war with the competition. This is great for the developers, but makes it hard to rely on them still being with you in six months time, and so makes relying on their talents harder, which reduces the extent to which you can use them effectively.

This feels like a good time to find a better option. I’ve somewhat hinted in that previous paragraph towards how to actually get 10x developers: make them. Or more accurately, make the environment such that everyone speeds up, as having one ultra-fast developer is of limited use, but having 20 of them is incredibly powerful. In other words, here’s how you get 10x developers: tooling, process and social improvements.

So, to start with:

Doing these things is harder than just saying ‘we only hire the best’, but it’ll get more out of the people you have, and maybe you don’t hit 10x, but a systematic 2-3x is already a massive gain.

Previously: Solving Docker’s ‘wait for database’ problem Next: Weird software licenses you may have not tried yet