61–70 of 186 posts
I spent Saturday digging out a basement with my son. The kid was a machine—for sure he did an order of magnitude more than I did. There's your 10x right there. If you can see it with picks, shovels, and a wheelbarrow, it's hardly implausible that you would see it in software. The research literature on programming productivity sucks, but not because 10x is a myth. It sucks because we have no reliable way of measuring…
While the article correctly highlights the lack of rigorous scientific studies on 10x engineers, it also generalizes a bit too much from anecdote to make the argument that they are mythical creatures. A more reasonable argument is that the hypothetical existence of 10x engineers explains little about the productivity of most organizations. Personally, in the couple decades I have been in this business working in coun…
My starting point is this study by biz school professors (unfortunately paywalled) about how power law distributions define employees in sales, scientific research, entertainment, and really much of skilled labor: http://onlinelibrary.wiley.com/doi/10.1111/peps.12054/abstra...
In effect, it's common for 20% of employees to be responsible for 80% of a company's productivity.
I'm a writer at Priceonomics, so you can read the blog post I wrote about the research and the topic here: http://priceonomics.com/whats-so-special-about-star-engineer.... I'd love to hear what HN thinks in the context of this thread.
It's a longread. I think the most important points are:
1) You find star performers in many industries
2) Star performers are not inherently more productive - context is important. They are talented but also benefit from the system supporting them. In one study, the performance of 10x Wall Street analysts crumbled when they switched employers if their team did not come with them.
3) If you get obsessed with 10x employees and A players - and lose sight of important points like the importance of team - you will become Enron. Really. Enron lived and breathed the A players motto until their idolizing of "talent" lost all connection to reality. You can find a link to a great Malcolm Gladwell article on the topic in my post.
People who don't believe in 10x programmers don't understand that they themselves are probably 3x or 4x programmers, thus to them a 10x programmer is probably only a 2.5x or 3x programmer relatively speaking. There are a lot of 1x programmers out there. So many that it's very easy to be an "above average" programmer. I am not a 10x programmer, but I'm not a 1x programmer either. I've met people who are 6-10x programm…
I think you don't know how to read.
John Carmack was 10x.
He is good at optimizing and using algorithms, but I don't think anyone says he is that good at writing programs. He popularized and sped up a lot of the techniques already in use. Raycasting wasn't anything new when John Carmack used it to build Wolf 3d (it was described as far back as 1982, 9 years before Wolf3d). It was also used in other games by other developers around nearly the same time, with games that were in development a lot longer.
There are many environments in which NNPP's are pretty much the standard, programmers that produce more problems and bugs than actual working and sustainable solutions.
In such an environment any competent developer will quickly stand out and will easily be labelled as a "x-times engineer", when all they actually are is just good at their job where others fail miserably.
The 10x myth is a way to give a positive spin on the shockingly common incompetence in our field.
While the article correctly highlights the lack of rigorous scientific studies on 10x engineers, it also generalizes a bit too much from anecdote to make the argument that they are mythical creatures. A more reasonable argument is that the hypothetical existence of 10x engineers explains little about the productivity of most organizations. Personally, in the couple decades I have been in this business working in coun…
Your words are extremely accurate to me. There ARE 10x engineers but it takes a lot of experience to even have a chance at becoming one. A new grad ( even out of somewhere lik e Stanford ) has no chance to be a 10x engineer especially in a startup landscape (assuming a small startup with few extremely experienced engineers) without proper mentorship. The only people that i would say are 10x have worked at larger comp…
I'd go so far as to say there are 100x engineers -- but it's not that they personally achieve 100x more than another programmer sitting in front of the computer. It's that they have the vision and talent to set a project up the right way from the start, so that the normal programmers can be productive. They're the difference between a project being delivered in 2 mos with a new batch of properly-working features coming 1 mo after, or a project taking 2 years with 8x more programmers, crashing half the time, and further features becoming impossible.
And then there are -2x engineers, who mess up things in the code base so bad that every hour of their work takes two hours for other programmers to fix or undo.
Then there are engineers that accomplish things that other engineers simply cannot. Call these infinity-x engineers.
No matter how much people want to call the 10x engineer a myth, there is a truly gigantic variation in productivity levels, which is especially magnified at architecture-level roles (where productivity can have a multiplier-effect on other engineers, for better or worse).
While the article correctly highlights the lack of rigorous scientific studies on 10x engineers, it also generalizes a bit too much from anecdote to make the argument that they are mythical creatures. A more reasonable argument is that the hypothetical existence of 10x engineers explains little about the productivity of most organizations. Personally, in the couple decades I have been in this business working in coun…
However, an couple of anecdotes and some 140-character broadcasts hardly sway me that pronounced productivity differences are a myth.
I have known developers who, given a moderately complex programming task, will complete it within a reasonable amount of time. The code will be correct with no more than the expected bugs, and the design will be OK as a stand alone piece of code. The design will not be ingenious. It will not take other parts of the system into account. It will not have simple tweaks done in preparation of future design change request…
I always thought of 10x engineer not as one that writes 1000 LoC while others write 100 LoC. Rather, as one that says, at an early stage of development "let's do it this way" and the total amount of manyears spent on the project (including maintenance etc.) happens to be 100 rather than 1000, which would be the case if second best approach is pursued.