I don't like this re-framing of "the 10x engineer" to be someone who writes 10 times as much low-quality code.
It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
I don't think there are any myths involved, we can name people. Fabrice Bellard leaps to mind. A bunch of the OSS maintainers. These people are just observably (much more than) 10x more productive than the standard developer. People cast from the same mold turn up from time to time in the corporate world too.
Part of it is problem selection, part of it is hard work, some fraction appears to be genius. But it is obvious and observable, I've seen average developers at work and they just won't achieve the results the top performers get even if given 10x as much time.
One explanation of the denial of the existence of 10x developpers I find interesting, but can't remember where I read/heard from, is related to the stakhanovite movement [0].
Basically it's in the 30's in Russia, where a coal miner, Alexei Stakhanov, had a mythic productivity and inspired people to reach that said mythic productivity, as an example. While Stakhanov really existed, it's not factually established that he managed to produce what is claimed.
Same goes for 10x developpers. Is there at least a name for some of them and a concrete example of what they managed to produce ?
The same reason shows why the bimodal and 'branded' name is such a strange thing to focus on.
Why only 10x? And why not try to make your 1x into 2x?
It's like if sports fans spent all their time talking about a potential player who could deliver exactly 10 times more goals than everyone else. Why is this a topic that needs to be brought up so often? Why have we 'software engineer'-ised the idea that some people are much more important for productivity?
I should clarify that by referring to it as a myth, I'm not denying in my post that there are people who are 10x as productive as most people.
The "myth" is that there was a formal study done and these performers were identified. The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
This has since evolved to a further myth that 10x programmers exist, but are somehow always harmful and should be avoided. There are plenty of articles examining "The 10x programmer myth" which, with no more evidence than the original assertion, put forward that 10x programmers should be avoided.
And here in this article, it gets re-written again, that they aren't even 10x as productive, and just produce ten times as much in terms of LOC but it's all terrible code!
> The reality is that the study was looking at the difference best and worst performers, not best vs average, which is an important clarification.
That is an important, often misunderstood, clarification, but I think it’s also subtly incorrect.
It’s 10x higher than some minimally competent level, not 10x higher than the worst in the field.
I think the original studies (certainly later follow-up studies did this) excluded results from participants who did not complete the assignment at all. That makes some sense from a data analysis convenience standpoint, but truncating the left tail and then saying some are 10x better than the absolute worst (that you truncated in the previous step) isn’t fully representative of what we see in the field.
In any case, people on here tend to be extremely sceptical of social science results, and demand much better standards and reproducibility.
Except that particular 1968 paper, which is held up and treated as gospel, because it helps to confirm rather than challenges their personal experience.
If we are going to demand better, we should do so consistently. Reproducing that result with more rigour would be a useful start.
I group the skepticism that I see around this topic into two buckets.
One is "it's not 10x, but is maybe 4 or 5x"; the other is "if differences exist at all, it's definitely less than 2x".
I get/have sympathy and agreement for the first type on a technically-precise level, but it also doesn't really change any of my behavior as a technologist or people/org leader.
The second type of skepticism I just don't understand at all from people who have worked more than a couple years in industry.
> The reality is that the study was looking at the difference best and worst performers, not best vs average
This is a myth, the worst performers didn't complete the task or delivered a faulty solution, those were removed from the study so you didn't see the worst.
Best to worst would be much much larger than 10x, however finding anything larger than 10x would take a very long time as it means waiting around for the slowest to finish.
Edit: And if you add back all of those worst performers, best vs average would also shift significantly towars 10x.
A myth based on another myth... OTOH, it's definitely easier to be more productive if you cut corners (or "incur technical debt" if you want to say it in a more sophisticated way). Generally, a more productive developer will know where to focus their effort, e.g. understand the business logic so they don't spend time handling cases that won't happen in practice, know where tests are most needed and leave other areas for later, automate repetitive tasks or find tools that make a task easier, etc.
Sometimes it’s not even about cutting corners. Just pushing back against poor meeting culture and declining pointless meetings can easily give you a 2x boost.
That almost always ends with an architecture that only the original author can change, so hard disagree ^ _ _ _ _ ^
It's really pointless to quantify the productivity of a developer via numbers. It's a conjunction of knowledge, intelligence and ability to express this as code.
And also communication. I find it weird how everyone is talking about the code, but a huge part of the job is communicating properly with others so that you don't produce useless code, and that others know how to properly integrate with it.
Yeah I'm also sick of seeing articles cite this mythical trade-off, where any increase in programming output must be correlated with being a bad team member, churning out bad code, and generally being a pain to work with.
Anyone that's worked with engineers can tell you that there are simply some people getting more done than others, in the same amount of time. Are there people producing bad code? Yes. But I don't think output is inversely correlated with code quality. In fact the people I've worked with that have the most output, also had some of the highest quality code. I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers. He probably exists somewhere, but not with the sort of prevalence that justifies every programming productivity article ripping on his archetype.
In our team's current project, the engineers who can be described as "10x engineers" are the slowest when it comes to delivery of features. They have been transferred to a legacy project with lacking tests, messy spaghetti code full of bugs. They spend a lot of time adding tests, refactoring the code to be more modular, removing various cruft. It looks like they are much slower than the previous mediocre engineers, and they produce a lot of code, but it pays off: while the userbase is increasing, our bug reports rate per month has decreased by 2x in a matter of 1.5 years. So I think the amount of code output is only part of the equation.
If a system is impossible to maintain, that system is nothing of value, and therefore doesn't fit to any sensible definition of 10x.
I have always assumed that the 10x means value creation, not some kind of "lines of code" output or other nonsense. And for sure there are 10x programmers, maybe even 100x. I have been mostly working at startups and you see these early stage decisions and designs that create huge costs when the company starts to scale, similarly you have some decisions that might save huge amount of costs during the company life time, or allow better revenue generation etc.
> I've never experienced this mythological 10x rockstar figure that works alone creating impossible to maintain systems, and I've worked closely with dozens of engineers.
I've seen this plenty of times.
Recently I was trying to explain the pros and cons of micro-services, and more importantly, microrepos, with regards to automated testing. The lead engineer that said he'd quit if I colocated the tests with the app.
Same place, they replaced all deploy system with argo, but every environment is pinned against main, which means you can no longer test a change without it going to all environments at the same time.
In both cases, the engineers are actually much higher skilled than average and churn out / lead change, but they'd rather be chasing a fad and just don't care if their changes shit on other parts of the SDLC.
That case sounds more like you being 0.1x developer about obsessing over test automation, where the 1x guy just didn't seem them to be worthwile.
Personally I have had clashes during my career with people who obsess about unit testing way too much in places where it just doesn't add any value (in fact destroys it by requiring lots of work and additional mainteinance). Value in the end is quite a subjective thing so it doesn't make sense to argue that much about it.
So have I, and I'm pretty impressed you could decipher that from a single comment, and it doesn't reflect poorly on you at all that you immediately drew such a conclusion from someone refusing to discuss pros and cons of solutions.
When I first heard "10x" I assumed it meant someone who had "10x" the effect with the same amount of effort. Someone experienced who can judo-chop problems away (if they're allowed to). Someone who force-multiplies everyone around them rather than being just another grinding cog.
But nowadays "10x" just goes into the same pile I throw "agile" and other meaningless terms.
This. My understanding of 10x engineers was, even if a bit tongue-in-cheek, always positive. They are the smart guys and girls that know what they are talking and think ahead a few miles. It sure can be overwhelming when you hear them talk, but if you let it sink it in, it makes sense.
But we as a society should not pretend that this is what you have to be. There are just some smart people in the world, but they are rare. You don't need to be one to be a good person.
If you’ve played the game RuneScape, you know well that some players accomplish feats that are hard to comprehend.
You have people gaining billions of experience points or tens of thousands of boss kills in the same amount of calendar days the average player accomplishes tens of millions or hundreds of boss kills.
I don’t see why this couldn’t be the case for software engineering. I have a wife and kids and spend 10 to 15 hours doing sports a week. I’m maybe more efficient than average since my career has gone well, but there are people who are way more efficient and way smarter than me. Couple that with them being able to spend twice or more the number of hours, and you might arrive at similar 10-100x productivity numbers that you see on the game RuneScape.
> It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.
There were several studies, and it’s about being 10× as productive as the worst not the average.
For me the 10x engineers don't write the same code as others faster, they come up with approaches and ideas that others simply don't think of, resulting in huge gains in terms of development speed and/or product features.
I too thought that immediately but I’d encourage you to read on (if you haven’t already) as the rest of the article — a list of bolded statements about good engineers with further explanation in each paragraph — is pretty solid in my opinion.
It might not have been a rigorous study and may largely be a myth, but the myth is about engineers who are 10 times as productive, even accounting for quality.