We're a place where coders share, stay up-to-date and grow their careers.
Good list, but like it or not, the existance of the "10x developer" is a statistical certainty, and has to do with productivity not volume of knowledge. The pareto distribution shows that in almost any field, 20% of the people do 80% of the work. For those that are in the 20%, they are the "10x".
The problem is less about some developers doing more work than others but the combination of stereotypes that make this "10x developer". Nearly every use of "10x developer" I've seen comes with caveats like "programs through the night", "doesn't like meetings", "only uses dark themes", "knows every line of code", "doesn't work well in teams" etc.
What makes a developer good or not is none of those points (who cares what theme someone uses). The best developers people will more likely match up with the 10 points I've listed. Programming at any reasonable scale requires working with a team and I doubt the productivity of a single "10x developer" would be able to "beat" a team of developers who are smart/helpful/work well with each other.
I also think that it's a misconception that 10x refers to speed or productivity. You won't see them doing a 2 week sprint in 2 days, they might even appear to be progressing slower because they are thinking designs through for hours, paying attention to small details and researching connections between concepts. But at the end of the day, they are able to solve really difficult problems and produce more maintainable systems.
When I see a job listing asking for a rockstar developer, I read that in my head as "We hope you get energized working weekends and holding an understaffed team together!"
Interesting take. Do you have some data to back that up?
I think the myth of the 10x developer is well established. But its a myth. People remember it from the book Peopleware by Tom DeMarco, et. al. But often forget the main lesson of the book that I will quote here:
"You May Want to Hide This from Your Boss
Among our findings of what did correlate positively to good performance was
this rather unexpected one: It mattered a lot who your pair mate was. If you
were paired with someone who did well, you did well, too. If your pair mate
took forever to finish, so did you. If your pair mate didn’t finish the exercise
at all, you probably didn’t either. For the average competing pair, the performances differed by only 21 percent.
"Now, why is that so important? Because even though the pairs didn’t work
together, the two members of the pair came from the same organization. (In
most cases, they were the only ones from that organization.) They worked in
the same physical environment and shared the same corporate culture. The
fact that they had nearly identical performances suggests that the wide spread
of capabilities observed across the whole sample may not apply within the
organization: Two people from the same organization tend to perform alike.
That means the best performers are clustering in some organizations while
the worst performers are clustering in others. This is the effect that software
pioneer Harlan Mills predicted in 1981:
'While this [10 to 1] productivity differential among programmers
is understandable, there is also a 10 to 1 difference in productivity
among software organizations.1'
(H. D. Mills, Software Productivity (New York: Dorset House Publishing, 1988), p. 266. )
"Our study found that there were huge differences between the 92 competing organizations. Over the whole sample, the best organization (the one with the best average performance of its representatives) worked more than ten times faster than the worst organization. In addition to their speed, all competitors from the fastest organization developed code that passed the major acceptance test.
"This is more than a little unsettling. Managers for years have affected a
certain fatalism about individual differences. They reasoned that the differences were innate, so you couldn’t do much about them. It’s harder to be fatalistic about the clustering effect. Some companies are doing a lot worse than others. Something about their environment and corporate culture is failing to attract and keep good people or is making it impossible for even good people to work effectively." (De Marco, et al. Peopleware 3rd Ed 2013. p46-47)
The book basically concludes by proposing that the better organizations are those that create better working environments. The book that originally came out in 1987 is probably the reason many companies like Microsoft and others gave every developer their own office in the 90s.
People have forgotten the main point of the book and actually look at the very things that the "statistics" showed did not matter so much.
At work you probably notice a guy that's way better than you. But such a guy in a better company would be even more awesome. And in a worse company he'd look like a chump to you even if you're a junior.
The pareto distribution is very well known and studied. I'll leave it up to you to google it and read up on it.
The Pareto principle doesn’t mean that 80% of the code is written by 20% of the developers. It was observed in wealth distribution and even then it was observed that 20% of people “owned” 80% of wealth, not “generated”.
The only data I can find in software development is from Microsoft who found that “80 percent of the errors and crashes in Windows and Office are caused by 20 percent of the entire pool of bugs detected”.
If 20% of your team are doing 80% of the work then surely there are serious issues with the team...
The pareto distribution has been observed in more than just economics, it has also been observed in many different workplaces. I doubt if you looked for specific references of it to developer workplaces you probably won't find much, but it is considered to be near-universal across different types of industries, and there is nothing unique about the industry of software dev.
"If 20% of your team are doing 80% of the work then surely there are serious issues with the team..."
Absolutely, which explains why many workplaces are such a mess (particularly large corporate ones where they have enough staff to fit the mean).
I think your point was a little obscured by the way it was made.
Yes, in literally any system there is some sort of distribution curve. There is definitely such a thing as a bad, passable, good, better, best spectrum in any line of work. There is a 20th percentile and an 80th percentile and maybe those in the top 20 percent are "10x" developers according to your definition.
Do they perform ten times the work of anyone else in the shop? Hard to say. If so, then you probably have a mess of a workplace.
This article is focusing on some of the prevalent stereotypes and how they aren't necessarily indicative of whether or not someone is in the top 20 percent, making the argument that instead of pure evaluation of "productivity" (which is nebulous at best... Is that Lines of Code? Completed stories? Impact to team velocity? Speed at solving fizzbuzz?) that there are instead some other non-technical and leadership aspects to the "10x" engineer that pushes the whole team forward rather than being a purely individual contributor divorced from their team...
So I think there's some common ground here for everyone :D
Well, no. The Pareto Distribution is a parametrisable line on a graph - without evidence, it shows nothing. You clearly have faith that it applies to productivity of developers, and indeed it might, but without data statistics tells you nothing. This is without trying to get into defining what "productivity" means, which is terribly difficult.
With my statistician hat on, a far more sound argument for the data-minimalist is as follows: Given the number of developers in existence the probability there there does not exist a developer who is ten times more productive than the mean is vanishingly small by the law of large numbers, therefore the 10x developer exists. This statement holds pretty much regardless of the definitions of "productive" (assuming the distribution of the productivity of developers is long-tailed) or even "developer".
Whether or not the above statement has any worth is left as an exercise to the reader.
My gut feeling is that it'll follow a normal distribution curve (bell curve) rather than a Pareto distribution, possibly skewed up or down depending on various factors like team morale, buy-in to the project, and environmental factors (Oh WHEN are they going to fix the air-con in here?! It's too hot to think!). Most people don't like to do worse than average for the team because obviously they don't want to be seen as dragging their velocity down - but equally if one person does so much more than anyone else it can create bad feeling because it's putting pressure on everyone else to perform better than they're comfortable doing & it's making people look bad. Nobody likes a teacher's pet, so to speak.
We're a place where coders share, stay up-to-date and grow their careers.