How to really identify a 10x developer

The sudden trending of "hashtag 10x developer" worries me. It worries me because it's not really about 10x performance, at least most of the time I've seen it. Instead, it tends to bundle two often overlapping movements which are unrelated to performance, but very much entangled in some rather nasty gatekeeping aspects of our industry:

The "no true Scotsman" fallacy about how a developer behaves that's been kicking around since the '60s SDC/IBM Vocational Interest Scale claimed only loners made good programmers.
The "I've already proved my worth, don't make me sit a programming test" attitude beloved of engineers who've amassed a few nice titles and previous employers on their CV, but not much actual engineering skill.

Well, I guess that's a bold assertion. So let's bring up a few of those 10x myths and the problems I have with them:

"They wear out keys associated with programming languages more than they wear out keys associated with spoken languages" - I'm a little worried that they're not writing concise code here. I'm a lot worried that they're not communicating with anyone else.
"They rarely look at documentation or StackOverflow" - so they assume they're always right, rather than checking, and they never work with anything that has interesting corner cases or failure modes?
"They hate meetings" - and here was me thinking their 't' and 'e' keys got spared because they were such great verbal communicators.
"They think it takes too long to teach others, and they don't keep normal team timings" - ah cool, I was getting a little worried these superbeings might be humble, non-arrogant and easy to work with.
"They expect to be judged on their achievements; if they've built a major app for Google, they don't expect to sit in an interview and do a simple kata" - got me there, I don't think I've ever seen a difficult personality with irregular timings sit and coast on the achievements of a team who are glad not to have them around.

There's some hilarious skewering of these precepts around the Internet, and not being a 10x comedian I'm not going to attempt sticking my own in here. You know where to find the good stuff. (Hint: Twitter). But what is lacking is a decent definition of what a 10x developer really is if you can't identify them by picking anyone who's wearing a leather trenchcoat in summer and staying up until 3am to hack the Gibson. So here goes:

A 10x developer is a developer who ships features to production at around 10 times the rate of a notional "average" developer.

Cool. So how would we identify them? What clothes do they wear, how do they speak, what are their unique cranial deformities?

A 10x developer usually completes a well-devised and fairly administered practical coding task noticeably faster than a typical candidate.

That's it. No more, no less. They might turn up in an Assemblage 23 T-shirt and carrying a rucksack with wires sprouting from every pocket, they might turn up in a sundress. They might live alone in a basement flat full of vintage routers, they might have three kids, two Labrador retrievers, a semi-detached house and an estate car. They might be 21, they might be 60. Give them a fair coding test not encumbered by fake difficulty, trick questions or mind games. If they can get shit done at what feels like it might be around 10 times the rate of your average candidate once out of interview conditions and on a real world task (and around 100 times the rate of your "what am comput0r?" folks), then by definition they're a 10x developer.

Alright, I've done my bit on the diversity soapbox for now, and I've thrown a tautology out into the wild. Let's dig into the concept a little more.

What makes a 10x developer 10x?

I think this is a far more interesting topic. I've had the fortune to work with a few people in this category over the years, and that feeling of being on a team where it's all gelling and features are flying out the door every two weeks is incredible.

One surprise is that the 10x people weren't necessarily great coders, at least in terms of following all of the design patterns and naming conventions and what have you. They did know their languages reasonably well (and it was inevitably languages plural), but the 10x-ness didn't come from spending every evening digesting textbook after textbook or eating a lasagne made out of network cards.

What defined 10x people was more what they didn't do. They didn't spend hours agonising over structure, or making sure they'd picked the perfect framework, or worrying about the test pyramid. The 10x people write some code to get a thing done, and enough tests to be confident that it's working, and enough pipeline to get it to where it needs to be.

The magic unicorn bit here is that when they do this, whatever nascent structure happens is generally okay. It's not perfect, and they're not under any illusions it's perfect, but you generally get something that makes sense and can be evolved, expanded or beaten back into shape as necessary. This is why I'd find it very suspicious if someone was disproportionately wearing out their 'i' or ';' keys - my experience was always that 10x developers wrote less code to get their aims achieved.

How? Well, the structure of a program tends to be informed by the core of the problem being solved. If you get that core wrong (e.g. assume a distributed data problem has strong referential integrity) then that will pollute every layer above it: clunky interfaces, error checking for self-induced errors, a forest of mappers, and vestigial tails of "check pi is still 3.14" endpoints. Where regular old 1x developers often go wrong is trying to apply the same structure to every problem and struggling through this morass. If you get it right, suddenly all those translation and multi-dimensional abstraction layers disappear, and the controller code is something you knock out in an afternoon - not because you're shit hot quick, but because there's less of it.

Where the 10x people are really good is identifying what that core is, and getting straight to work on it. This looks like instinct from the outside, but I think it's more a combination of two things: having tried lots of different approaches to problems in the past and being able to recognise where they apply, and being willing to face up to the scariest part of a problem rather than defer it. Now this is where you do get some overlap between reality and fever dreams of long-haired guys in mirrorshades, because knowing some of the contents of Knuth or the Gang of Four book will help with the former. What doesn't matter so much is how someone knows those contents; whether it's CS degree, practical experience or a generous textbook budget doesn't make much difference as long as someone can recognise the moment to use a graph traversal algorithm over a brute force search.

This, incidentally, made them excellent mentors in my experience. Sorry influencers. If someone is being productive by writing less code, and they're writing less code because they understand where to attack the problem and what to attack it with, it follows that they're able to explain exactly what they're doing and why. The only problem is that sometimes it flows a bit fast for us mere mortals to understand. I often found myself getting out of a pair programming session and spending the next hour Googling things. (This is a sign of good mentoring, as opposed to handholding and infodumping someone into learned helplessness).

What this tells you about interviewing for such people is... look, don't bother scrying for some kind of secret sauce, they'll be fast and effective when you do some coding together. Yes, you might see someone go immediately for what you thought was the "clever bit" of your exercise, but don't start assuming you've identified the only "clever bit" worth prioritising and making that a formal scored objective!

So, point of all this is that you shouldn't be presupposing that someone with poor personal hygiene and a lax attitude to interview start time is going to be great, or that someone who doesn't present as "traditional nerd" is going to be awful. But more than that, as I've mentioned before even if your recruitment pipeline is a finely-honed machine for attracting and identifying 10x developers, it straight up doesn't matter.

Team and environment are far more important.

10x environment > 10x developer

This is the uncomfortable truth. Decent people (i.e. at least 1x developers) in a good environment will over time outperform 10x people in a bad environment.

This has been gone over so many times it's probably redundant for me to even mention it, but the classic summary:

Do small things frequently.
Give teams problems to solve, not solutions to implement.
Test results and modify behaviour accordingly.
Eliminate waste wherever it is identified.
Don't get distracted by silver bullets.

If you don't do that even the 10x people end up down in the place where they're no more effective than the 1x or indeed the 0.1x people: creating arbitrary numbers to go on spreadsheets, sitting in the corner of 30-person meetings listening to "project managers" discuss what solution will be foisted upon them, or having a productive and interesting discussion with their favourite recruiter.

Conclusion in sight

A lot of the current "10x developer" hype is misguidedly trying to bring back the old astrology of software developer personality types, as explored in this excellent Thougtworks post. Look - as an industry, we've done nearly 60 years of harm to ourselves by assuming there's a "type" which makes a good developer, can we maybe have a go at not perpetuating that into the next decade and beyond?

Besides which, it feels like this is another one of those distractions away from the uncomfortable reality that your structure and the way you treat your teams is the thing causing your problems, not the lack of some semi-mythical lone wolf bedroom coder who's going to crank out thousands of lines of code per hour providing you fuel them with Relentless and music with a blackletter typeface on the album cover. (They exist, I've worked with them, I'm not actually convinced the results are "10x" when measured in feature delivery over the long term. That's not to say such people shouldn't be hired, but you should have a plan to help them be effective in a team environment.)

And don't let anyone with an inflated ego convince you they shouldn't be subject to some level of practical means test because they look geeky and have a cool CV. Personally, I'd be sceptical of any company who didn't set me one as part of their hiring process.