On "10x developers"
Yesterday, a VC posted a Twitter thread about "10x engineers and how to spot them.'' It is a frankly terrible thread, and predictably, it became the latest Internet Pile On(tm), which we all know is Twitter's favorite pastime. I added my own thoughts in another thread, which I want to replicate here for posterity and then expand on a bit more now that I have a real keyboard and not just my phone.
First, here's my original thread, lightly edited for clarity, paragraphs, and links:
Hi. Senior engineer with 20 years experience, including "lead a multi year effort to overhaul and modernize a massive code base involving hundreds of developers.". I'm sure some would call me a 10x dev.
I have some comments here...
Most of this thread is a collection of random stereotypes of antisocial developer with autistic tendencies. That was offensive and wrong when it was first propagated in the 70s. It's even more wrong today. I really hope the thread was meant satirically, because otherwise the author has demonstrated he should never be allowed anywhere near a hiring role, or really any position that may have influence on staffing at all.
Second, the entire 10x dev concept is grossly misunderstood. Both by those that continue to spread this kind of nonsense and those that make fun of people for it. Sadly no one bothers to read the original source anymore.
As far as I know, the 10x dev meme derives from Fred Brooks' "The Mythical Man-Month", which is an excellent book that everyone in tech should read but most haven't, which is why they have no idea what they're talking about.
For the VC set who see Dilbert's Pointy Haired Boss as someone to aspire to, a 10x dev is an excuse to hire one or two genius do-everything devs rather than actually build a team they have to pay for. Also, a cover for sexism/racism in some cases (but not all).
The pushback to it, unfortunately, is just as innane the other way: devs are all about equal and all that matters is team building and synergy and empowering and leading from behind and whatever other anarcho-egalitarian silliness is in vogue this month.
Both of these viewpoints are flat wrong, and neither have anything to do with Brooks' original description. Brooks observed that there is a wide range of skill levels and expertise among developers (true), but not that one produces vastly more code. They don't. They best designers produce designs that have fewer intrinsic bugs, and require 10x less code with fewer edge cases.
The key word there is not developer but designer. Code needs to be designed. Design is an advanced skill that takes time and practice and mentorship to achieve. And that only sometimes translates between languages/environments/contexts.
How does someone get to be a good designer? Practice, educational failures (learn from mistakes), mentorship, and lots of peer review. It takes collaboration to become a good designer, of code or anything else.
So no, hiring all 10x devs is not a thing. If you try you'll mostly get prima donas, not good designers. If you try to use the nonsense in the OPs thread as indicators you'll be guaranteed to get a dysfunctional team. In fact, a team full of great designers only, even actual ones rather than that made up nonsense, will be ineffective because they'll end up designing by committee and produce a big ball of mud. You need clear leadership. Again, actually read Brooks.
Conversely, the idea that the ideal lead dev does nothing but "empower" others all day rather than actually produce anything is hippy dippy fantasy land. Not letting a good designer design is a complete waste of time, money, and people. You want a mixed skill level team, and a diverse background team, for many reasons. But that includes and acknowledges that skill level, and skill area, varies widely, and that's OK.
So how do you recognize a 10x designer? It has nothing to do with the background color of their monitor or other asinine things like that. What you should be looking for are things like:
Do they ask Why? and challenge assumptions without being self-important jerks about it, but instead trying to build an accurate shared mental model?
Do they have a good sense of context and when something is an appropriate solution, and when that same solution isn't?
Do they sieze upon teachable moments to educate and help the rest of the team improve, even if it takes more of their time than just doing it themselves?
Do they actively solicit input from others before making a design decision, even if in the end it's their decision?
Are they willing to be challenged constructively on their decisions, and can they change course when a valid argument is made?
Are they able to identify and preempt edge cases in the design, rather than with 100 conditionals in the code?
Can they freely admit when they're out of their depth and seek help as easily as they give it?
Those are the attributes you want in a senior dev, and yes, they can and will produce a 10x better system. Not 10x faster or cheaper, 10x better structured. And no, there is zero correlation with what school they went to, their race, sex, favorite text editor, or wallpaper.
And it's OK to hire people who aren't all of those things. Really. Don't hire just that. Hire juniors for them to mentor to build the next generation of designers, and to constructively challenge them. A good designer needs that challenge to function. Hire domain specialists, too.
The individual does matter. The team composition does matter. You don't want all 10x designers. You want a mix of designers, algorithm gurus, specialists, generalists, and juniors. Thank you for coming to my Ted Talk. Now go read "Mythical Man-Month" for yourself.
(I'll also add one more sign of a top-tier designer/architect/developer: They view good documentation and code comments with equal importance to good code and good architecture. Don't @ me.)
For reference, this is the earliest reference to the concept of a "10x developer" I can find:
Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.
—Fred Brooks, The Mythical Man-Month, page 202
That's technically from Brooks' essay "No Silver Bullet" from 1986, and is then included in the 2nd edition of "Mythical Man-Month". In context, he is talking about the need to provide ongoing and long-term mentorship to potential great architect/designer prospects the same way businesses actively mentor potentially great management prospects, as both great managers and great architects/designers are highly rare.
In the follow-up, Cal Evans pointed to another source on the "10x developer" image from Joel Spolsky. Joel offers some actual data to back up the idea that, yes, the range of skill level between programmers is huge, with a very wide standard deviation, too. Developer performance is literally all over the map.
This should not be at all surprising, because as anyone who has actually worked in software development can tell you, developers are not are interchangeable cogs that crank out lines of code at some predictable rate you can put into a projection spreadsheet. That anyone still hires project managers who think that (and build estimates around it) is a rather strong condemnation of the software industry.
Yes, some developers really are better than others. Some designers/architects really are better than others. Yes, the difference can be massive, even "an order of magnitude". If your response to someone talking about a "10x developer" is to point them to http://10x.engineer/, which flippantly proclaims:
Then you are in fact wrong and just being a petulant pseudo-egalitarian. You would make a lousy colleague, team lead, or manager.
As Marco Rogers also pointed out in the follow-up discussion, the image and brand around "10x developer" the term is not at all about people who perform well. Basically nothing in the stereotype-ridden original thread has any bearing on development capability, but it does, as Marco points out, serve as a great way to pick out people who fit a stereotype (usually young white male Californian fresh out of college and convinced of his own superiority), pump up their egos, and use that to try and extract way too much work out of them as a cost savings.
Sometimes management instigates that as a way to get cheap labor and to avoid thinking about diverse teams. Sometimes the developer does it to themselves as a way to inflate their ego, their pseudo-power, and excuse their misanthropy. Sometimes it's both. Any time you see one of those comical job-adverts go around that purports to be looking for someone with 30 years PHP experience, 15 years Go experience, 10 years React.Js experience, and "able to work in a fast paced environment", that's the same mechanism at work. (And yes, some of them are real job advertisements, not fake ones. It's kinda sad.) See also: "full stack developer".
That is the sort of harmful stereotype-reinforcing, asshole-protecting BS that people are usually responding negatively to, and rightly so.
But that doesn't mean rejecting outright the concept of developers coming in wildly different skill levels that vary greatly depending on context, or that small teams tend to perform better than huge ones, or that sometimes the proper team size is one if it's the right one person. All of those are true... they just don't in any way correlate with the "brogrammer" stereotype nor do they excuse someone just being a jerk to be around.
The ideal team has a mix of skill levels and skill areas and backgrounds, with a clear leader who is actually powered to make decisions rather than just "empower" and "lead from behind" all day (I've worked for a place that tried that, it was awful), but who actively tries to build and improve the team in the process rather than lord it over people. That means both high technical skills and high people skills. Such people are rare, but that doesn't mean pretending they don't exist to make yourself feel more egalitarian.
We need to reclaim and defend the "brand" of such people. It's been corrupted by the "abusive 10x" image the original poster so aptly summarized, but we cannot allow that to undermine the value that senior-level people really do bring, and deserve credit for. And we need to do it without pretending that senior-level people are really just cat herders and teachers who don't do their own work (a pattern I see all the time on Twitter). You want and need both, and arguing extremes against each other is going to only hurt everyone.