
Super-star programmers - lauterthanbombs
http://www.economist.com/blogs/babbage/2012/06/super-star-programmers?fsrc=gn_ep
======
drharris
Forgive potential ignorance here, but people often quote Joel Spolsky as
saying things like: "...the trouble with using a lot of mediocre programmers
instead of a couple of good ones is that no matter how long they strive, they
will still produce something mediocre."

What really genius-level things has Fog Creek done? I remember demoing
FogBugz, and it was marginally better than its competitors, but it was far
from a complete game-changer. Trello is ok, but it's only marginally better
than a whiteboard with post-it notes. None of these reinvent an industry, or
provide something so outstanding that people rush toward it.

Don't get me wrong; I think Joel has a lot of good ideas in general, and Stack
Exchange is indeed a game-changer. But as someone who continually talks about
hiring "rock star programmers", I simply don't see a result that I'd consider
"rock star" equivalent. But, maybe I'm missing something?

Edit: More than that, I don't even consider myself a rock star developer, just
a normal developer who loves learning new things and getting a lot of stuff
done. I'd be thrilled to work for a Google or Microsoft, but what would
attract "rock star developers" to Fog Creek? Basically, are fancy chairs
enough? Isn't the most attractive thing a super interesting problem domain?

~~~
ajross
I'm constantly fighting that same urge. The problem is one of domain. UI
coding for straightforward data models (which is 90% of all "web" development)
just ... isn't very hard or impressive. Great programmers in that regime
produce software that is smaller, cleaner, tighter and higher quality. But
it's still just a bug database or social thing or web store, etc... Anyone
(even mediocre programmers) can look at it and say "I know how that works."

There's plenty of rock star coding out there, of course. But it tends to be
either hidden inside companies due to secrecy concerns (Google's scaling
architecture or the NVIDIA driver stack, say) or exposed in the open source
community instead of the startup world (Fabrice Bellard is a great example
here).

Startups all say they want rock stars, but then they put them to work doing
"better versions" of the same boring stuff we all recognize. Which, if you
think about it, is sort of what startups are supposed to do.

~~~
vbtemp
Although the article never used the word "super star", it's something I see
around HN and the startup world quite a bit....

I sort of snicker when I see startups post jobs looking for "rock star" coders
[1]. What self respecting person would call him or herself a "rock star", let
alone _apply_ for such a position? Maybe it's just a gimmick to get mediocre
developers to get to work on boilerplate web work..

[1] I also saw a job posting recently where they were looking for a coder "to
work on hard problems and _blow a hole through the universe_ "... Why not have
them blow bullshit of their face while they're at it? Is this just HR trying
to sound too cool, or what?

~~~
excuse-me
Next time you see someone ask for it - simply reply with your request for a $M
salary.

After all what does a rockstar get ?

~~~
to3m
I have to say, I was more hoping for the groupies and gak myself. A million-
dollar salary from a programming role is so unrealistic.

~~~
excuse-me
I suppose it depends on what kind of rock star.

Words never heard backstage = "That's the banjo players Ferrari", "That
supermodel is sleeping with the drummer"

~~~
evincarofautumn
Not sure about that—a lot of famous guitarists were originally pickers, and
while the electric guitar may be a sexier instrument, most of the drummers
I’ve known have actually been very attractive.

------
forgotAgain
As I reached about half way through the article I got bored and my mind
starting having stray thoughts

\- god this is long. Isn't it ironic that a superstar programmer would have
been bored by now and stopped reading.

\- momentarily after that, I guess I just admitted that I'm not s superstar
programmer.

\- momentarily after that, I wonder if there are writers who can transmit ten
times as much information using one tenth of the words.

\- just now, I imagine magazines don't want superstar writers. That would
diminish the amount of ad space they could sell.

~~~
kstenerud
You can achieve faster reading rates with this sort of stuff by only reading
one sentence from the middle of each paragraph, or reading the second and last
sentence in the rare case that the middle sentence wasn't enough. The content
is of such low density that it takes little more than that to decode the
meaning and intent of the article.

~~~
fragsworth
This is unfortunately true for most web articles and blog posts.

I tend to do this somewhat subconsciously when I start to realize the content
is sparse.

------
Chris_Newton
It’s interesting that in the research from _Peopleware_ mentioned in the
article, the factor of 10 difference was mostly between different
organisations, while individuals within an organisation were typically quite
close in performance.

This suggests to me that the biggest influences on productivity for the
organisation as a whole are probably to do with collaboration, culture and
environment rather than extraordinary individual skill.

Maybe the very best programmers aren’t extraordinary just because they can
solve the most difficult problems, but also because they are better at
presenting their solutions in ways that are more accessible to other
developers. That would have the twin benefits of improving productivity in its
own right and of implicitly teaching by example so less experienced developers
in the organisation would tend to develop the same skills themselves over
time.

If you had a seed of programmers on that level and a culture that promoted
mentoring, pair programming, code reviews or similar collaborative exercises,
it’s not hard to imagine that such an organisation would develop significantly
higher collective performance over time than another organisation without
those benefits, even if most people joining each organisation were of a
similar level of skill and experience to start with.

------
Cacti
I find this is typically due to a difference between the level of abstraction
people are modeling in their head. A great coder can flip back and forth
between several different levels (the 50m lines of OS code, the 100,000 of app
code, the 1,000 of local code, etc) and have a reasonable idea of how those
parts fit together.

Not a complete understanding, just a basic idea.

This is why mediocre programmers are what they are---they lack this ability
and end up "flailing around", looking at somewhat random issues, bouncing back
and forth, unable to see the pattern, and so end up spending more time writing
code that eventually has to get rewritten.

A great programmer will systematically take a problem apart so that even if
they don't solve a problem in one minute, they've at least narrowed down the
window of options for the future.

This is also why great programmers are always great debuggers.

~~~
Bill_Dimm
Good points. Just to elaborate a bit, the mediocre programmers tend to end up
writing five functions that do almost the same thing because they don't have
the vision to see how it all fits together and come up with a single, elegant
solution. The code may very well work to accomplish the immediate task, but
the lack of clarity and good planning makes it rather fragile if
modification/extension is ever necessary. They tend to produce a lot of
unnecessary lines of code that become a maintenance liability as the project
grows.

------
smoyer
I think every previous study of this topic has determined that the best
programmers are those that can keep more layers of abstractions in their heads
(I'll add a citation when/if I find it).

For me, there are days of brilliance and days of complete distraction. I won't
call myself a 10xer but I think much of my success has come because I truly
love what I do.

 _EDIT_ \- I couldn't find a reference to the study I was remembering, but
Steve McConnell of "Code Complete" fame has written a blog post describing how
flawed the studies he's reviewed have been -
[http://forums.construx.com/blogs/stevemcc/archive/2011/01/09...](http://forums.construx.com/blogs/stevemcc/archive/2011/01/09/origins-
of-10x-how-valid-is-the-underlying-research.aspx). There are links to a lot of
interesting sources and he clearly isn't arguing against the idea of dramatic
differences in programmer ability ... just sayin'.

~~~
Chris_Newton
I find that programming well, as with much in life, is often a matter of
balancing different perspectives or competing priorities.

Can I pay attention to the details without losing sight of the big picture?

Can I do a good job technically, but keep within any other project constraints
like budgets and timescales?

Can I write code that is good enough to ship tomorrow, but maintainable enough
to work on again next year?

My best work tends to get done when I figure out the right balances. If I let
one aspect become too dominant and neglect something else as a result, that’s
usually when the problems start.

------
Shengster
It seems the general consensus is that a great programmer can write better
quality code in less time than others.

This requires a high level of aptitude and experience (which comes with
practice).

However, I feel the ability to write quality code quickly is just one facet of
a great programmer's skillset.

Often overlooked is the ability to communicate and collaborate with others
effectively--which is just as important.

With complex projects, I oftentimes find that the solution to my problems has
already been solved. Sometimes the best code is no code at all.

~~~
zenocon
Agree -- also one of the most under-rated skills is someone who keeps up to
date on all the latest frameworks / libraries, etc. More often than not,
you're building something that solves a unique problem and you do that by
stitching together pieces of other people's engineering.

I would argue that this presents several sub-skills:

Being able to do this quickly b/c you don't have to spend the time learning

Being able to do this effectively -- by not painting yourself into a corner
b/c you well versed in best practices and anti-patterns with using said 3rd
party technology

Being able to do this smartly -- because you are well-versed in a lot of the
different options, you can effectively way their pros/cons, and make smart
decisions on which 3rd party stuff to use, and when to build vs. buy

I think these skills are more effective (towards your end goal) than simply
being able to quickly code some brilliant labyrinth of an algorithm in less
SLOC than a 1 or 2-xer. I feel like the emphasis is always put on the latter,
and these skills are overlooked.

Combine these with effective communication, and then you are talking about
someone who can get things done.

~~~
enjo
I think you came close to the biggest differentiator: adaptability. Great
programmers can dive into a new technology and use their past experience to
quickly gain competency in it. If I hand node.js to a great programmer, I
expect that he/she will be able to start being productive with it in just a
day or two. Lesser programmers struggle to apply their past experience to that
new paradigm. It takes months for them to truly get comfortable.

That type of agility is hugely helpful in an organization.

------
presidentender
I can think of one real, actual, verifiable superstar: Steve Yegge. There are
more, but I don't know who they are.

Taking his blogs at face value, and assuming that my sample size of 1 is
enough, here's what I've got:

"Superstars" get things done because they get things done. They may be ADD in
their multitude of projects or in their personal lives, but while they're
producing, they produce. They don't fuck around on reddit while they're
coding. They might screw around interminably at other times - they might work
only a few hours a day - but while they work, they're working, and that's it.

They also get things done because they understand what the hell's going on, at
least one or two layers of abstraction below the one they're officially
working on. Stevey claims that his understanding stops at transistors -
transistors are black boxes, but he gets what has to happen at the layers of
abstraction above that, from the machine code to the guts of the interpreter.

Particularly delicious? Steve Yegge worked at Geoworks ([http://steve-
yegge.blogspot.com/2008/05/dynamic-languages-st...](http://steve-
yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html)), and he
attributes their defeat by the likes of Microsoft not to superior marketing,
but to the value of abstractions.

~~~
zohebv
Steve Yegge was also unable to successfully maintain a not-too-complex 2D game
and managed to blame Java for it

[http://steve-yegge.blogspot.com/2007/12/codes-worst-
enemy.ht...](http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html)

10Xer imples 10X some base level. Depending on what base you choose, Yegge can
easily fall short.

~~~
presidentender
Oh holy shit. You have no idea.

I "worked" on Wyvern in high school (in that I played a lot of Wyvern and made
a few terribly shitty game areas and ended up being an administrator, or
"Wizard" in classical MUD parlance).

You know how Dwarf Fortress, that ASCII game, simulates a whole lot of
ridiculous detail? Over-the-top, "the goblin's spear strikes the baby dwarf in
the back upper left tooth and it really hurts so he cries for mommy"? Wyvern
didn't quite have that, but the API implied most of the functionality for it.

You didn't have inventory slots, you had body parts, which brought with them
the ability to wear or wield certain other items.

You could've written Wyvern in a much simpler fashion. A bright high schooler
could make a game that had all of Wyvern's functionality at the end of its
life. It's the mountain of "do a lot of other shit later" that got in the way.

And that's what he's writing about in that blog post - not that he's perfect
and Java sucks, but that he was trying to employ industry best practices and
make everything perfect without compromises. It's not very hackerish, and
sure, it was stupid. But the guy wasn't doing this for his day job and didn't
have defined deadlines. He was a programmer, in other words, not a project
manager.

And that's where he fell down. Project management, not programming. And if you
read back through his massive wall-of-text blog archives, you can see him
mature as a programmer and project management.

(Please note that I am an avowed fanboi, if you didn't catch that already, and
as such everything I say must be taken with a grain of salt.)

------
jdlshore
I'm disappointed to see the 10x programmer meme hit a publication like the
Economist. There's no scientific evidence of 10x differences in programmer
productivity. To quote Laurent Bossavit [1], who's investigated the studies
people like McConnell use:

"How strong is the support conferred to the 10x claim by the best-reputed list
of references, for a reader persistent enough to follow the chain of citations
back to primary sources?

"Based on our close reading of the “10x files”, we can now answer: quite weak.

"Not a single one of the references is to a replication, in the scientific
sense of the term, of the original exploratory experiment.

"The empirical data is in general quite old, most if not all of it predating
widespread use of the Internet - which we can safely expect to have wrought
major changes in programming practice.

"None of the studies address the question of construct validity, that is, how
meaningful it is to speak of an individual programmer’s productivity, and if
it is meaningful, whether the experimental measurements line up adequately
with that meaning."

Don't get me wrong--I've certainly seen 10x (and greater) variations in
productivity. But they've been due to factors other than inherent individual
capability. They're things like

* technical debt

* familiarity with the codebase and problem domain

* interruptions, distractions, multi-tasking and other office environment issues

* choice of language - but this is a distant fourth compared to other the other three

On top of all this, the Economist article is a thinly-veiled press release for
tenXer, which is itself nothing more than an exercise in testerone-fueled
egotism. tenXer measures _activity_ , not productivity [2], and I expect the
primary result of increasing your tenXer metrics will be less time thinking,
more time hacking, and insufferable smugness.

[1] _The Leprechauns of Software Engineering_ explores what science is and how
we distinguish between _fact_ and _folklore_ in software engineering. It
specifically explores the 10x claim, and determines that it's folklore.
<http://leanpub.com/leprechauns>

[2] Productivity is defined as output over input, and the output of
programming is software capability. No one's come up with a good measure of
that yet. So any time someone claims they can prove increased productivity,
ask them how they measure it. Chances are good you'll get a bogus value that
measures _activity_ instead, such as "lines of code."
<http://martinfowler.com/bliki/CannotMeasureProductivity.html>

~~~
btilly
One of the better sources for these differences and their magnitude is
_Peopleware_. Instead of citing vague research "somewhere", they did their own
primary research. More specifically they set up coding wars where different
programmers at different companies assigned to the same task independently.

They found 10x differences in time spent on the average coding war (which was
typically a pretty small sample) with those finishing faster typically
producing programs that worked better. So by any reasonable measure, at least
10x productivity.

There is your 10x, right? Wrong. They found that the best predictor of
programmer performance was the performance of another programmer at the same
company. Furthermore they managed to correlate a lot of that performance
factor to specific factors, such as having a phone that turned off, a private
room, adequate desk space, and so on. There was still something like an
unexplained factor of 3 left over, but they didn't know whether it was
environment variables they had not looked at (eg training), individual ability
(which might be correlated across institutions), etc.

It is true that this research happened in the 80s, before the Internet was
widespread. I would love to see it replicated again.

(Note, I'm aware of the existence of many other poorly controlled studies, see
<http://www.flownet.com/gat/papers/lisp-java.pdf> for an example, but what is
critical in the Peopleware study is that they acquired information both about
productivity and about factors that might cause productivity differences.)

~~~
pradocchia
In _Peopleware_ , they also observed that some programmers did not themselves
_appear_ to produce much, but their presence on a team made others more
productive. They were not managers, they were not leads, they just helped the
team work better together, in some fashion, "managing" out or across rather
than up or down.

I will jump the shark and speculate that these gel-members tend to be female
more often than male, and the gelling-like effect comes from how their
presence and patterns of behavior influence the group dynamic. I will further
speculate that the dearth of women in development incurs a hidden cost to
productivity, since statistically, fewer teams will have women, and
consequently, the incidence of gel-members will be lower, and teams more
fragmented.

I think there is a business opportunity here somewhere, or maybe it has
already been realized in places, but the players have not been eager to
trumpet their results.

------
northbranch
I think the author glossed over an important point:

"Within individual firms, the difference in performance was only 20% or so."

Is this because good developers congregate together, as suggested, or because
having at least one good developer raises the productivity of those around him
or her? They can certainly influence an organization through their choice of
platforms and tools, aiding the productivity of everyone on the team.

------
ilaksh
Side issue with this article/tenXer press release: the thing about constantly
reworking code being a sign of a bad programmer was wrong -- it actually takes
more skill to be able to do routine refactoring. Not to say that that is
always practical.

Also, taking advantage of existing software makes a huge difference in
'productivity' at least as far as business people can measure. And someone who
does that without acknowledging that they are doing it may appear to be a
'superstar' to management.

For example, someone may just consider all of the source code they have ever
written, regardless of the circumstances they wrote it in, to be a code
library they can copy and paste in whatever company they currently work at.
And not even acknowledge that they are reusing code they wrote years ago.

So that sort of dishonesty irritates me, but generally I think taking
advantage of existing software is the right thing to do and is the number one
factor in what non-technical people would perceive as productivity. There is a
huge difference in the time required to build a system using an easily
configurable base like WordPress with plugins or components or by integrating
open source software or libraries versus building various parts or all of the
system from scratch.

That's where you will see orders of magnitude difference in productivity where
one person or group is reinventing a bunch of wheels that another group is
not. And again there are many different ways of avoiding reinventing wheels,
from using Google to basing software on existing open source programs to
selecting more practical application programming languages/tools (like ones
with things like garbage collection or more straightforward syntax or support
for interactively configurable graphical components/plugins), or for example
doing test driven development or in general having any type of automated QA
rather than relying on a manual QA process entirely.

------
twakefield
tl;dr - Quite a PR piece for <http://www.tenxer.com/>. Impressive that they
could get the Economist to do this, even in a blog property.

------
gruseom
_The big difference is that the best coders keep more of what they have
produced, while the worst constantly have to rework whole sections._

Whoa. Either I'm a worst programmer or this is clueless.

~~~
akkartik
I said the same thing and had an interesting conversation with the author of
the Thrust/Drag post cited in the article.

[http://plus.google.com/110440139189906861022/posts/84784VhCm...](http://plus.google.com/110440139189906861022/posts/84784VhCmzE)

------
tokenadult
From the interesting submitted article:

"An outfit in San Francisco called 'tenXer' has begun testing a service that
aims to help people boost their mental accomplishments by up to tenfold—hence
its name. . . . "

. . . .

"For those wishing to have a go, tenXer

<http://www.tenxer.com/>

in San Francisco is currently offering a beta version of its tracking software
to help people analyse their own performance, set goals for themselves and
improve their lot. At present, the tracking software works only for
programmers. But down the road, the same techniques could just as readily be
applied to other occupations. . . . "

The great thing about this is that many of us on Hacker News can put the claim
to the test. Commenting on the claims of tenXer, which is what the writer for
The Economist and several of the commenters here on Hacker News are doing, is
interesting, and trying this out and seeing whether or not it works might be
even more interesting. It's still unclear how much most individual human
beings can improve themselves if they apply effort to self-improvement. It
might be a good opportunity for career development for many HN participants to
try this out.

------
schrijver
The only example here given of the powers of these superprogrammers, is that
they have banded together to make an OS that’s technically impressive, but
gets no traction in the marketplace and ends up all but forgotten (PC/GEOS)?
Not very enticing…

~~~
pacaro
Having written both application and system code for PC/GEOS, it never appeared
to have been written by 10Xers.

For the record I've worked with EPOC-32, Windows, NextStep, Linux, VxWorks,
and Nucleus - none of them was as painful as PC/GEOS (although EPOC-32
sometimes came close...)

------
codgercoder
I see no comments yet on one of the biggest factors underlying highly
productive programming: choosing the part of a development at which you can
most easily excel. Sometimes there are legitimate areas where you have
expertise, but mostly it's the well-defined areas that have no external
roadblocks. And the rough parts get left for everyone else!

------
will_work4tears
Articles like this only depress me, making me realize that I'm a mere web
developer and not even a REAL programmer, and in the realm of web developers
probably not even remarkable. Which makes me probably LESS than mediocre as a
programmer.

So much for moving up in the world.

------
sunkencity
My gut feeling tells me there's a 10x difference in productivity in almost any
field of work.

~~~
pradocchia
if you replace "productivity" with "effectiveness", it feels even more true,
with the emphasis on doing the right work, rather volume of work. as
programmers, if we do the right work, our software "produces" more, so we
readily conflate the two, but in other fields where the product is less
animate, effectiveness means your unit of output is the right output, even if
near & local productivity doesn't vary much.

------
capkutay
I'd see the most value in a programmer who could combine simple
ideas/algorithms for some practical, yet useful application. Not necessarily a
10x l33t haxor genius.

------
evilbit
one aspect this "superstar"-worship drivel^Harticle seems to ignore is the
organizational contribution to success.

i'd argue that individual contribution to any given project of substance is
greatly overestimated, while contribution of the team
(organization/culture/whatever) is unfairly underestimated.

even in professional sports, superstar a winning team does not make.

~~~
Ygg2
True, I remember one study (I can't recall the link sadly) that measured
performance of several programming teams and found strong correlation between
women in workforce and team performance.

Another study in the book "Imagine" by Lehrer Jonah implies that creativity
depends on the Q factor, inside a group. Here is a quote: "Uzzi’s data clearly
demonstrates that the best Broadway shows were produced with intermediate
levels of social intimacy. A musical produced at the ideal level of Q (2.6)
was two and a half times more likely to be a commercial success than a musical
produced with a low Q (<1.4) or a high Q (>3.2). It was also three times more
likely to be lauded by the critics."

I can see how hiring only rockstars which probably knew each other would
increase the Q beyond the ideal level.

