After reading numerous posts on the subject of 10x software engineers, I reckon they fall mostly into two categories:<p>- <i>`I have worked with / seen code of such ones'</i> (often examples follow)<p>- <i>`there were no such ones on any team I ever managed'</i>, with OP falling into this category.<p>Which is to say, the existence (or absence) of 10x software engineers appears to be party recognition problem -- managers do not want to believe one `rockstar' is responsible for most of team's output.<p>The other part, is the sampling bias: managers don't get to work with the Torvalds, Bellards, etc. Such software engineers often don't need to be, or aren't managed while producing their most important code. Neither they do respond to ``we are hiring rockstars'' types of job ads...
In the same vain I responded to Shanley's post: this is missing one type of engineer that is common in our field:<p>* Average Engineer - Creates complex <i>problems</i> in response to simple problems...<p>This is where the desire for rockstars / 10x engineers comes from. One person to clean up the mess made by 10 others.
He's empirically wrong because I've worked with 10x developers.<p>A few years ago I worked with a guy there whose output, productivity, and smart solutions combined with godlike C++ coding ability made him probably 100x more effective than anyone else in the place.<p>This was in the front office at Goldman Sachs, so the rest of us weren't completely useless. He was just in a different league though.<p>I have also worked with a 10x developer who carried a small company of around 50.
Collaboration overhead. If you replace 10 average programmers with 1 good programmer he doesn't need 10x productivity to match the combined productivity of 10 programmers (which is not a sum). On top of that, programming productivity is also a qualitative measure that goes beyond feature X working correctly. One person can code it in such a way that every time it needs changing it's easy to work with - thus saves uncountable hours in the future.<p>Not all men are created equal - I don't see why anyone would rail against that. Some people are stronger than you, some people are better coders than you - it's OK. Compare yourself with last year's you instead.
This isn't backed up by evidence or a sound argument, and comparing the capability of women to have babies with the productivity of programmers nicely sums up the intelligence of the argument.<p>Teams follow the 80/20 rule as well. 20% of the developers do 80% of the work (there is actually evidence in support of this, but I'm not going to look it up now)<p>Rockstar developers are a real thing. I work with some. I like to think I am one. I'm not talking about loud developers which the author seems to conflate with rockstar developers. I'm talking about the quiet thoughtful guys who have an amazing grasp of how everything fits together. They see the problem in amazing detail with all it's hairiness and then devise a simple, elegant solution for it.<p>Rockstar developers are the guys who solve the right problems. And there's an infinite gap between them and the bottom guys, because for some problems, the worst developers will never solve them. They tend to be around 10x as productive as above-average developers on the hardest problems. On easy problems there's a much smaller difference.<p>In my free time I work on a multi-threaded high-performance ACID relational database with concurrent algorithms, custom memory allocation and layout, hybrid index data structures and garbage collection algorithms. I don't know too many developers who can solve those kinds of problems, so I like to think I'm special. But all humans like to think that, so maybe I'm not actually a rockstar developer and I'm really just average-delusional. Who knows.
> Reality is a normal distribution curve. Lots of good average senior developers, some amazing outliers and some junior folks with potential. (and some folks that suck.)<p>Strange, but this doesn't seem to be the case for me, or at least the people that I've had to interview and work with. I've run into far too many developers who have no business installing apache much less making anything of use for a client.<p>I don't consider myself a "rockstar," but when you put me next to one of these folks my productivity is going to be 10-fold better <i>at least</i>. On top of that, the things I build will be reliable and maintainable -- their will be a mess of technical debt that breaks every few days.<p>As a sidenote, I find this obnoxious:<p>> I hate Quora so I won't link to them, but here's a modification of a great answer from Nate Waddoups that was taken from some internal engineering paperwork:<p>"I hate Quora, so I'll just steal their content and post it here."
It doesn't take a "rockstar" or a "ninja" or "guru" or what-have-you to be a significantly above average developer.<p>Often the biggest hindrance to product quality (including performance, reliability, and usability) as well as to development velocity is technical debt. Having a team member who consistently churns out lots of new stuff of excellent quality is great but not nearly as important as someone who is sensitive to and adamant about eliminating technical debt. The cost of such debt balloons exponentially over time and becomes more and more difficult to pay down the longer it's allowed to grow. But even a fairly modest amount of effort consistently applied before technical debt grows out of hand can realize massive gains compared to the more typical scenario where the technical debt is allowed to grow until it threatens the viability of the entire product before it's addressed.<p>This may not seem very "rockstar" but ultimately it is such folks who keep the system clean who have the most disproportionately large impact on the quality, viability, market success, and total development cost of big projects.
>>People love to say that a rockstar can do the work of 10 regular engineers. That's just nonsense. 9 women can't have one baby in a month, and 10 "rockstar" developers can't replace 100 regular ones.<p>A somewhat confusing attempt to use the 9 women analogy here - it doesn't prove the author's point in any way.<p>I've worked with rockstar coders and engineers and my empirical experience suggests he's wrong.
My theory is that the time taken for an engineer to solve a problem is a hockey-stick/exponential curve based on the complexity, something like __/<p>The key thing is the knee of the curve is in a different position for different engineers. Basically, up to a certain point, you can crank through a problem pretty well. But once problems reach a certain level of complexity you'll slow down. And at a higher level of complexity, you're just going to go in circles and not going to get anywhere.<p>The point of a "rockstar" is not that they are 10x faster on the flat part, but their curve is shifted so they are on the flat part while another engineer would be on the exponential part. In other words "rockstar" depends on the problem. Knuth is unlikely to build a basic CRUD application 10x faster than an average HN programmer, but if the problem is building a typography system, he's probably 100x as productive. Likewise, if I had to build a Javascript compiler engine, a self-driving car, Minecraft, or a translation system, I would be stuck around 0% productivity while a "rockstar" would deliver. But "rockstar" depends on the project: on a simpler project, many more people would be able to deliver well.<p>TL;DR: for a particular project, people who can do that project well are 100x more productive than people who are overwhelmed by the project. But this line moves depending on the complexity of the project.
I disagree strongly. I created a software company, I have an amazing team, I know a little about this.<p>Rockstars programmers exist and they do because they can do machines do work for them, instead of having five people do the work the can do the code 5x to 100x or 1000x faster.<p>They could automate almost everything, even coding(creating new languages when needed specially for the task) and debugging itself, creating testing code, making failures very hard to happen.<p>A normal programmer will create new problems, not solve it. She will put mechanisms in place in order for the company to depend on her. She could not be faster but she could certainly make the others to slow down to her level. Beware is she gets to manage Rockstars, she will do everything to put others down, pointing fingers. They are experts excuse makers.<p>If you look at all big software accomplishments you will discover a very small team of incredible rockstar developers.<p>What this man is saying is that you need a team, no divas. But who says that Rockstars can't create teams?<p>One thing you can't do of course is putting Rockstars at the orders of some mediocre person or even argue when you don't know what you are talking about(you need to do your homework first). It is not comfortable.<p>What this person is saying is that he fears managing a team of people smarter than him, so he just prefers having people that are "normal".
I would have preferred somewhat more content, but the article still had this absolute gem at the end:<p>> <i>it's diversity of thought and experience in a team that makes a Rockstar Team</i><p>People who complement (and cover) one another's skills, are mostly self-directing and are not afraid to ask "stupid" questions - they are incredibly valuable, together more so than as individuals. I've had the joy of working with/in such teams twice in my career. Problems didn't just vanish, they very rarely materialised.<p>Eventually all good things must end. Projects end, priorities change, people move on and teams get disbanded. The reality check after such a joyful experience can be shocking.
My main takeaway from the rockstar/ninja programmer thing- many people seem to believe that the average programmer produces net negative value, i.e. causes more problems than they solve.<p>I'm still uncertain whether I believe this, although I'm sure we all feel like we are carrying the team some days. If it were true, it would mean that firing half of all programmers could be the biggest improvement to the software industry ever seen.
Each time something like this is posted to HN many are quick to come to the defense of the 10x engineer as not a myth. Since so many HNers are founders/CEOs/CTOs/whatever I wonder how many of them making comments that 10x engineers are "responsible for most of team's output" are actually paying their "rockstar" engineers ten times average.<p>The best baseball players make much more than the average player, the star of a Hollywood film makes far more than most actors, and true "rockstars" make a heck of a lot more money than the vast majority of musicians.<p>Anyone know any companies that pay their best engineers multi-million dollar salaries? (if so please let me know where to apply!)
Isn't it obvious that the myth or reality of the 10x engineer has a lot to do with what the engineer is supposed to do?<p>Say that the engineer has to independently develop the general theory of relativity to solve a problem, then I'd say Einstein would have been about Inf times more productive than the average engineer at solving that particular problem.<p>If on the other hand it's the usual "migrate this crap code from that crap platform to this shiny new golden one" kind of work, then you'd have more of a bottleneck in how fast you can push the buttons on the keyboard...<p>You can't talk about productivity without defining the task, and software engineering is a field with extraordinary span in the difficulty of tasks.
> People love to say that a rockstar can do the work of 10 regular engineers. That's just nonsense. 9 women can't have one baby in a month, and 10 "rockstar" developers can't replace 100 regular ones.<p>This is completely unconvincing, and begs the question: why is software development a sequential fixed-time process like having a baby? Where is the evidence for that?<p>On the other side of things, there are lots of people - just look in the comments here and in previous related stories - of people that clearly say they have worked with devs that are 10x more productive then the average. Why does the author feel the need to deny that? That's the real question.
The author is exactly backwards on the issue of team scaling.<p>Even if I grant his premise that 10x engineers don't exist (which I don't), let's just presume 2x engineers exist. So is a team of four 2x engineers equivalent to a team of 8 1x engineers? No -- the smaller team is vastly more effective, because of the n^2 communication problem.<p>This is why strong individual performers are so valuable. Give me my top pick of 10 developers, and we will ship the product at least as fast as any organization <i>of any size</i>. Bigger organizations can still work on more separate projects in parallel, but they won't out-develop us on any particular one.
Well, you can't get into electronics and not hear about Bob Widlar, Jim Williams or Bob Pease..<p>There is such a thing as rockstar engineer. The thing they had in common though was that they're really good, yet are kind on others. They were also extravagent, but that's just who they were. Read about how Jim Williams behaved during his interview, and you'd see what I mean (for the less curious, he was in shorts and sandals, moved really close to the recruiter and started to interrogate him).
"In fact, it's diversity of thought and experience in a team that makes a Rockstar Team" -- this, a million times this. You don't get rockstar results without deep thought and questioning everything. The most efficient way to do this, and the easiest way to create this in your company, is to build a diverse team.<p>I believe that this is the real secret behind Google.
The most important reason we have to insist on the "rockstar programmer" being a myth is that it takes attention away from the CEO that wants to be the rockstar. Rockstars also have more leverage, which chaffs the suits who want you to be just another drone that they can shuffle around like an office chair.
I suspect that the strong disagreements between people on this thread on whether 10x engineers exist or not say more about the diversity of HN'er team composition than anything else.<p>If you put a competent coder among a bunch of not-entirely-stupid, well willing, but mediocre programmers, he can quickly be 10x as productive. He will also clearly stand out as such. Put the same coder among other competent coders, and nobody will notice anything special.<p>If this is true, there can only be two options:<p><pre><code> - Hanselman only ever worked with mediocre engineers
- Hanselman only ever worked with truly competent engineers.
</code></pre>
Hm. Given recent stories about Microsoft's employee quality downfall, something about my thesis must be wrong. That, or Microsoft really does mostly hire people in the rightmost quartile of a bell curve.<p>But anyway, no matter whether this idea makes sense, I believe that it never pays to try to hire "10x people". If you find that you managed to find one, it simply means that the most of your team has been underperforming. Get rid of them and replace by one or two other decent ones. Maybe the first mr 10x has some friends?
The 10x programmer myth is all about relativity. I suggest there are no 10x programmers, only -10x programmers which make the normal ones look really good.<p>And people who say that 10x programmers do exist because they have worked with one, are in fact themselves the -10x guy.
I never liked the words rockstar and programmer being associated together. The only valid use case for that is if a member of a very successful rock band, with fans and groupies becomes a programmer as a second job. Only then he's a rockstar programmer.
In my experience, Managers often mistake Cowboy Coders for Rockstars.<p><a href="http://c2.com/cgi/wiki?CowboyCoder" rel="nofollow">http://c2.com/cgi/wiki?CowboyCoder</a>