TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The 10x developer is not a myth

26 pointsby brikis98over 11 years ago

6 comments

plorkyeranover 11 years ago
My problem with the notion of the 10x developer is that I've never seen a reasonable study into what a 1x developer is. An order of magnitude gap in productivity between the best and the worst is a massive understatement. I've worked with programmers with net-negative or zero productivity, and being ten times more productive than that is trivial. Thus, the real question is whether or not the people who are a tenth as productive as the very best developers happen to be average, and to answer that we'd first need a much better idea of what the "average" developer is.
LordHumungousover 11 years ago
There's a bit of a difference between science, where you are trying to find insight on unanswered questions, and engineering, where the problem space is usually well understood. In the former a single brilliant individual can have a huge impact, whereas in engineering it is usually teams that do so. My problem with the "rockstar developer" idea is not so much that it is incorrect, it is that it places the emphasis on the individual over the team, which is the real unit of productivity.
TillEover 11 years ago
&quot;Star&quot; athletes are an interesting example. Are they 10x better than the average professional athlete? Well no, probably not. Pick whichever objective statistical measure you like, and you&#x27;ll probably find that the top five players in the world are maybe 2-3x better than the average pro.<p>Similarly, it&#x27;s trivial to find thousands of guitarists on YouTube with enormous technical ability, who will never become famous.<p>I&#x27;d suggest that the top 10-20% of developers are actually quite good, and being obsessed with the top 0.01% isn&#x27;t very useful.
评论 #6467163 未加载
评论 #6467440 未加载
eitlandover 11 years ago
As I have pointed out before I have seen on first hand the difference between someone who is great and someone who is filling out the blanks. This is from a few years ago:<p>The &quot;10x&quot; consultant would delete hundreds of lines of code and keep the functionality. He would rewrite things and make them simpler. And in between he was helping the rest of us, explain architecture and generally make sure we were able to follow.<p>On the other hand I have seen other consultants, who were definitely smart[1], who would still do things like:<p>Use tiles (a templating framework for java&#x2F;struts) to implement authorization. (Cleaning up this fell on me. : )<p>Add style tags to the body of the page (once the designer found and fixed this it solved all the perceived performance problems we had.)<p>[1]: If you had seen that code you would have agreed. It was some kind of weird artwork :-&#x2F; It worked perfect but every little change took full concentration, a significant amount of time and added to templates spanning hundreds of loc.
dcreover 11 years ago
I&#x27;ll save everyone the trouble.<p>&quot;Yeah it is!&quot; &quot;No it isn&#x27;t!&quot; &quot;Yeah it is!&quot; &quot;No it isn&#x27;t!&quot;<p>I do like your other article about converting imperative list processing code into functional style, though. <a href="http://brikis98.blogspot.com/2013/05/10-recipes-for-turning-imperative-java.html" rel="nofollow">http:&#x2F;&#x2F;brikis98.blogspot.com&#x2F;2013&#x2F;05&#x2F;10-recipes-for-turning-...</a>
angersockover 11 years ago
One of the skills, I think, of being a 10x developer is picking the right tool for the job--picking a language and level of abstraction that will as cleanly and simply solve the task at hand.<p>It takes a good amount of experience and knowledge to know when to, for example, prefer assembly to C to C++ to Bash to Ruby to Prolog--not only that experience and knowledge, but the wisdom to see how that choice affects the other people on your team or future people maintaining the code and environment.<p>(This is an area in which I wish I was further developed.)