At what point did we stop making fun of that 10x engineer thread and started taking it seriously? Who forgot that 10x was a silly little thing that made zero sense in the real world?
> Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring perfor- mances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one.
He goes on to explain that because the primary cost in software development is the overhead of coordinating minds, a company is far better off paying for just a few really good programmers than they are 10 times that number of mediocre ones. Whether or not there's such a thing as a 10x programmer in isolation, this seems pretty self-evident and valuable to keep in mind.
If that’s really the primary cost, surely one of the metrics they studied variation in is the coordination cost imposed by the programmer on the company, they didn’t just naively assume the cost was the same but output different, right?
Because it seems like if it does vary, you’d want to minimize it by hiring the easiest to coordinate, and that might offset output differences in sone cases.
The lie is that anyone can become a 10x [insert thing here] just by trying harder. Self-improvement is a real thing, but everyone can’t be 10x or 6-sigma or world class.
Strive, reach, sure… but ultimately, just make sure you live your life. You only get one, and the clock’s ticking.
I often think of the Gene Hackman line in Heist: "I try to imagine someone a little smarter than myself, and I try to imagine what he would do."
It's not a level playing field, there are people who are just way more efficient and effective than the norm. Whether it's drive, focus, creativity, or knowledge (usually a combination of them), there are people who solve more problems and solve them better than average.
I don't know the literal number, but some folks are just better at it than others.
Perhaps you are just in a bubble and haven't met one?
I was at a conference once talking to a recruiter, when he stopped mid sentence and literally ran after one of these 10x engineers that had walked past.
John Carmack is definitely 10x or 100x (or 1000x) compared to me on low-level graphics programming, just factually, not that it says much about either of us.
But the '10x programmer' idea is soaking up and refueling some fanaticism. Let's all double down on the concept of high performance, for no particular reason we can agree on.
Putting an actual individual factor on it and especially on engineer productivity, like we were at a line factory producing everything in a repeatable and measurable way is more questionable. 1x, 10x, 1000x? People here are discussing 10x becoming 2x, it sounds very mathematical. Now if there is an actual scale with an industry baseline and an individual measurement, I'm more than interested to learn about it and I think employers should fairly compensate engineer based on the scale factor you would put on your CV.
After about 6 months on his team it became apparent that he was very good at communicating to his management, very good at writing excess complexity into his code, and very good at preventing the developers he was leading from taking on large or impactful projects.
My takeaway was that he was more of a "turn-everyone-else-into-1/10X" developer. I jumped onto a different team as soon as the opportunity came up (as did most of the folks who worked with him).
https://dariusforoux.com/prices-law/
> Price’s law says that 50% of the work is done by the square root of the total number of people who participate in the work.
Price's square root law: Empirical validity and relation to Lotka's law https://www.sciencedirect.com/science/article/abs/pii/030645... (behind various paywalls)
If you're on a team of 10 people, 3 of those people will be doing about half the work. And then 7 are doing the other half. If there are 10 work units, the 3 are doing 5/3 of a work unit each and the 7 are doing 5/7 of a work unit each for a ratio of 2.3x
---
Yes, 1/10th developers are common - especially in larger teams. And there are also -1/2 developers too where someone will spend half their time just cleaning up after the -1/2 developer.
And just with the nature of teams, larger teams are going to have a significant fraction of the team doing very little work (note: this applies to consultancy teams too and if you get a team of 20 people to work on the project, you really should just get a team of 4 and stay on top of them as it will be less work to manage).
The Net Negative Producing Programmer - G. Gordon Schulmeyer, CDP ( https://web.archive.org/web/20160305234708/http://pyxisinc.c... )
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
> Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]
> The ratio of programmer performance that repeatedly appeared in the studies investigated by Bill Curtis in the July/August 1990 issue of American Programmer was 22 to 1. This was both for source lines of code produced and for debugging times - which includes both defect detection rate and defect removal efficiency. [5, pp. 4 - 6] The NNPP also produces a higher instance of defects in the work product. Figure 1 shows the consequences of the NNPPs.
[5] : Curtis, Bill, "Managing the Real Leverage in Software Productivity and Quality", American Programmer July/August 1990
[6] : DeMarco, Tom Controlling Software Projects: Management, Measurement & Estimation (New York: Yourdon Press, 1982)
[21] : Shneiderman, Ben Software Psychology: Human Factors in Computer and Information Systems (Cambridge, MA: Winthrop, 1980)
[1]https://twitter.com/skirani/status/1149302828420067328?s=46&...
The idea itself has a certain sultry allure. That probably helped keep it wedged in the back of the mind long enough to find those kernels, rather than being immediately forgotten.