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 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).
Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
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
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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