
The Myth of the Rockstar Programmer - yadazula
http://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx
======
dexen
After reading numerous posts on the subject of 10x software engineers, I
reckon they fall mostly into two categories:

\- _`I have worked with / seen code of such ones'_ (often examples follow)

\- _`there were no such ones on any team I ever managed '_, with OP falling
into this category.

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.

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...

~~~
yummyfajitas
There also seems to be some ideological motivation for claiming rockstars
don't exist.

The existence of rockstars provides fodder for individualist ideologies. Many
people are more collectivist, so therefore feel the need to dispute the
existence of rockstars. This is a little bit evident here - you need a
rockstar team, with _diversity_. It's far more evident in the last post on
this same topic.

(Not quite a dupe, but it might as well be. [https://medium.com/about-
work/6aedba30ecfe](https://medium.com/about-work/6aedba30ecfe) )

Amusingly, it's also a very corporate philosophy. "No programmer is worth more
than any other, therefore to advance you must enter management." Tends to be
self selecting in such corporations, since everyone who isn't mediocre leaves.

~~~
SideburnsOfDoom
> No programmer is worth more than any other

I don't think that's what's being said. IMHO the message is:

\- No programmer is worth 10x the average. (though some might be worth 1/10 *
the average).

\- A high-functioning team is more important than a high-functioning
individual, and these two are sometimes at odds if you give free rein to the
"individualist ideologies".

Both are debatable and IMHO are _often_ true, but "No programmer is worth more
than any other", i.e. "all programmers have exactly the same worth" is not
Hanselman's point. It is an corporate anti-pattern.

"each person has different strengths and weaknesses and is growing at their
own rate" is recognised implicitly in a healthy working environment. Whether
management gets it or not.

~~~
bulatb
In the observation that kicked off the meme, a 10x engineer was someone who
was 10x more productive than the least productive members of the team, not 10x
more productive than the average.

~~~
SideburnsOfDoom
Yeah. If the least productive member of the team is clueless and gets nothing
done, then a competent programmer is literally _infinitely_ more productive
than that. It's not a very well-calibrated metric.

~~~
scarmig
It's pretty typical, I'd say, for the least productive member of a set of 10
programmers to have negative productivity...

------
bowlofpetunias
In the same vain I responded to Shanley's post: this is missing one type of
engineer that is common in our field:

* Average Engineer - Creates complex _problems_ in response to simple problems...

This is where the desire for rockstars / 10x engineers comes from. One person
to clean up the mess made by 10 others.

~~~
mtrimpe
That's exactly what I thought as well.

I'd very much prefer having the 10x engineer meme replaced by that of the 0.1x
engineer: the one that gets the same task done with 10% of the code and
effort.

The times I've felt by far most valuable is when I found a way to make that
multi-month project simply obsolete by just changing a couple hundred lines of
code in an unexpected place.

~~~
Someone
See also:
[http://folklore.org/StoryView.py?story=Negative_2000_Lines_O...](http://folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt):

 _" In early 1982, the Lisa software team was trying to buckle down for the
big push to ship the software within the next six months. Some of the managers
decided that it would be a good idea to track the progress of each individual
engineer in terms of the amount of code that they wrote from week to week.
They devised a form that each engineer was required to submit every Friday,
which included a field for the number of lines of code that were written that
week.

Bill Atkinson, the author of Quickdraw and the main user interface designer,
who was by far the most important Lisa implementor, thought that lines of code
was a silly measure of software productivity. He thought his goal was to write
as small and fast a program as possible, and that the lines of code metric
only encouraged writing sloppy, bloated, broken code.

He recently was working on optimizing Quickdraw's region calculation
machinery, and had completely rewritten the region engine using a simpler,
more general algorithm which, after some tweaking, made region operations
almost six times faster. As a by-product, the rewrite also saved around 2,000
lines of code.

He was just putting the finishing touches on the optimization when it was time
to fill out the management form for the first time. When he got to the lines
of code part, he thought about it for a second, and then wrote in the number:
-2000.

I'm not sure how the managers reacted to that, but I do know that after a
couple more weeks, they stopped asking Bill to fill out the form, and he
gladly complied."_

------
benjaminwootton
He's empirically wrong because I've worked with 10x developers.

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.

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.

I have also worked with a 10x developer who carried a small company of around
50.

~~~
seanmcdirmid
> He's empirically wrong because I've worked with 10x developers.

I believe you meant "He's anecdotally wrong because I've worked with 10x
developers."

To be empirically wrong, you'd have to contradict it with some empirical
rather than anecdotal evidence.

~~~
derleth
Anecdotal evidence _is_ empirical evidence. It's just not very convincing
because it doesn't come with any information about how common experiences like
those are, or what confounding factors might be at play.

Now, in this case, confounding factors probably aren't a problem, but if 10x
developers are one in a million or one in a billion, an anecdote about how
someone, somewhere actually met one once isn't very helpful to the rest of us.

~~~
_delirium
Validity of the observation is a potential confounding factor. There are
clearly people who impress their coworkers to the extent that those coworkers
believe the person is a 10x-average programmer. That's what this kind of
report establishes. But is the judgment of those coworkers correct? Is the
person _actually_ 10x more productive in any kind of rigorous, verifiable
sense? Generally these reports don't come with enough evidence to establish
that.

------
Paul_S
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.

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.

~~~
forgottenpaswrd
"Some people are stronger than you, some people are better coders than you -
it's OK. "

What some people fail to get is that coders have over human powers. A strong
person can't surpass human limits. He can't lift a car with his hands. But a
person with a machine can.

You can't short all the words in a book as a person, but a machine can in less
than a tenth of a second.

~~~
friendstock
Typo. Should be: You can't SORT all the words...

~~~
camperman
Maybe he really meant to reply to the Goldman Sachs comment :)

~~~
friendstock
:)

------
eloff
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.

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)

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.

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.

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.

------
d23
> 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.)

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.

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 _at least_. 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.

As a sidenote, I find this obnoxious:

> 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:

"I hate Quora, so I'll just steal their content and post it here."

~~~
tanzam75
> As a sidenote, I find this obnoxious: > "I hate Quora, so I'll just steal
> their content and post it here."

It's not Quora's content. Quora's TOS explicitly states that users retain
ownership over their contributions. Quora only gets a non-exclusive license.

Scott Hanselman works for Microsoft. Nade Waddoups works for Microsoft, wrote
an internal document at Microsoft, and then posted part of it to Quora as an
answer.

Therefore: The copyright is held not by Quora, or even by Nate Waddoups -- but
by Microsoft. And since Scott Hanselman is performing a PR function at
Microsoft through his blogging, he has the right to post that content on his
blog.

~~~
shanselman
That's a little complex of an explanation. I could still argue fair use.
Regardless, it's a coincidence that this guy works for MSFT. I don't know him.
I just stumbled on the Quora post.

The link from my post also explains why Quora is evil, I'm detail, FWIW.

------
InclinedPlane
It doesn't take a "rockstar" or a "ninja" or "guru" or what-have-you to be a
significantly above average developer.

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.

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.

~~~
UK-AL
Its the guys who layout the overall design, making it is easily extensible and
not prone technical debt who make a software project. They may not be the most
productive in producing code, but they allow others to be so.

It's usually the same guy going over others peoples code, and reducing
technical debt.

~~~
InclinedPlane
Another thing, a lot of the most important work in development is relatively
unglamorous. Most of the time it's better to have a craftsman at work than a
diva steering your product in the wrong direction for the sake of looking cool
in the moment.

------
arbuge
>>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.

A somewhat confusing attempt to use the 9 women analogy here - it doesn't
prove the author's point in any way.

I've worked with rockstar coders and engineers and my empirical experience
suggests he's wrong.

------
kens
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 __/

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.

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.

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.

------
forgottenpaswrd
I disagree strongly. I created a software company, I have an amazing team, I
know a little about this.

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.

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.

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.

If you look at all big software accomplishments you will discover a very small
team of incredible rockstar developers.

What this man is saying is that you need a team, no divas. But who says that
Rockstars can't create teams?

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.

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".

~~~
bostik
> _Rockstars programmers exist_

Of course they do. The laws of probability ensure that. People and their
traits usually follow a normal ("bell curve") distribution. Some individuals
are at +2.5 standard deviations, and some even at +3.0 but they are rare.

Using the table from [http://www.mathsisfun.com/data/standard-normal-
distribution-...](http://www.mathsisfun.com/data/standard-normal-distribution-
table.html) we can get some nice numbers to show just _how_ rare they are.

A +2.5 developer is better than 99.38% of the entire population. (1 in 160)

A +3.0 developer is better than 99.87% of the population. (1 in 770)

That kind of talent can not be easy to find, let alone attract. So relying on
getting such stars is gambling against some pretty bad odds. Some companies no
doubt have found that they can improve the odds of attracting those off-the-
charts developers, but for the rest of us mortals...

~~~
wesnerm2
You're mistaken about the laws of probability. The normal distribution arises
from sums of the same distribution. This is most frequently found in sample
averages, which is . More accurately, sample averages follow a student T
distribution, which converges to a normal distribution as sample size
increases to infinity.

In general, humans do not follow a bell curve for complex traits. For
instance, it's common to see bimodal/multimodal distributions when there are
major demographic differences in the population such as gender, race, economic
class, etc. Standardized tests have bell-curves because they are "normed."
Experimental questions are thrown out if they are not correlated very well
with the result.

Also based on the Chebyshev's inequality, +2 std dev has a minimum percentile
of 75%. +2.5 has a minimum percentile of 84%. +3 has a minimum percentile of
89%. +k has a minimum percentile of 1-(1/k^2)

~~~
yummyfajitas
Not only that, he seems to be conflating standard deviations with productivity
multipliers (I'm not exactly sure how to translate his +2 to productivity, I
could be misinterpreting), which is definitely wrong.

~~~
bostik
Heavens, no. That wasn't the idea, and certainly not my intention. It was
merely a numerical standard deviance value, nothing more.

Granted, the people at the high end of the scale are _probably_ more
productive when facing more difficult problems but that's all. "How much more"
is then an altogether different question. I'm not sure if one could even put a
figure on it.

------
bostik
I would have preferred somewhat more content, but the article still had this
absolute gem at the end:

> _it 's diversity of thought and experience in a team that makes a Rockstar
> Team_

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.

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.

------
sliverstorm
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.

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.

------
frostmatthew
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.

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.

Anyone know any companies that pay their best engineers multi-million dollar
salaries? (if so please let me know where to apply!)

~~~
crazygringo
Because it's notoriously difficult to measure programmer productivity,
companies are generally going to be incredibly hesitant to offer "rockstar"
programmers salaries that match their capabilities. There's no box office take
or album sales or stadium-filling metrics to rely on.

"Rockstar" programmers generally need to go and (co-)found their own companies
to make their multiples of millions. The great difficulty is that being a
rockstar _programmer_ doesn't always make you a good product/business person,
and the best programming can't save a crappy business. But people like Gates
and Zuckerberg are the ones who make it happen.

But if one day we find the holy grail of accurately measuring programmer
productivity... (though I don't think that's possible...)

~~~
frostmatthew
That's another thing I've found funny...often the very same people who say
measuring programmer productivity is difficult are the ones saying some devs
are ten times more productive than others.

------
illumen
Allow me to retort: Fabrice Bellard, Linus Torvalds, John Carmack.

~~~
jmadsen
Pity...go to any job board, you'll see 50 of them needed on any given day

Those aren't the "rock stars" hiring companies are talking about. They don't
need & couldn't afford Linus.

Rock star is just a label they slap onto the job description.

~~~
ak39
>Rock star is just a label they slap onto the job description ...

... often to arouse the ego of possible candidates.

I can't imagine why any recruiter wouldn't see the deliberate attempt at
patronising candidates when they advertise "Looking for a Rock star
programmer." Oh, hang on ... I know why: appealing to and strongly arousing
ego is one of the quickest way to get responses.

The team matters more than the individual. Hiring with overt calls to rock
stars is surely going to damage communication and collaboration with the
current team.

------
bjornsing
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?

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.

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...

You can't talk about productivity without defining the task, and software
engineering is a field with extraordinary span in the difficulty of tasks.

------
azakai
> 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.

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?

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.

------
ef4
The author is exactly backwards on the issue of team scaling.

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.

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 _of any size_. Bigger organizations can still work on more
separate projects in parallel, but they won't out-develop us on any particular
one.

~~~
dennisgorelik
"n!" communication problem, not just "n^2".

------
Jugurtha
Well, you can't get into electronics and not hear about Bob Widlar, Jim
Williams or Bob Pease..

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).

------
memracom
"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.

I believe that this is the real secret behind Google.

------
pstack
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.

------
skrebbel
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.

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.

If this is true, there can only be two options:

    
    
        - Hanselman only ever worked with mediocre engineers
        - Hanselman only ever worked with truly competent engineers.
    
    

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.

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?

------
adamconroy
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.

And people who say that 10x programmers do exist because they have worked with
one, are in fact themselves the -10x guy.

------
harel
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.

------
rob05c
In my experience, Managers often mistake Cowboy Coders for Rockstars.

[http://c2.com/cgi/wiki?CowboyCoder](http://c2.com/cgi/wiki?CowboyCoder)

