
The 10x developer is not a myth (2013) - mubaris
http://www.ybrikman.com/writing/2013/09/29/the-10x-developer-is-not-myth/
======
awkward
The reason for pushback on the idea 10x programmers isn't the real gradient of
skill, it's the labor aspect. Lots of companies want to hire 10x without
paying 10x dollars, and they've figured out that blowing smoke up the ass of
young people (though it works better on young men than women) is a way to
squeeze blood from that stone.

Especially if you're working in a small company, you're going to hit a point
when there is a massive wall of work to be done, bigger than you would ever be
able to handle alone, and your organization will fail if you don't do it. The
skills you need to actually handle that situation are going to be more in the
vein of basic professionalism than technical talent. Better programmers might
need a bigger wall before things get rough, but they will still hit it.

The reason for criticizing the 10x idea isn't that it doesn't exist, the
reason is because feeds into myths that might end up being harmful far beyond
the actionable decisions it lets you make.

~~~
Bartweiss
> you're going to hit a point when there is a massive wall of work to be done,
> bigger than you would ever be able to handle alone

This is my core complaint. All software development is (eventually) rate-
limited somewhere other than developer brilliance. Most business software hits
this limit fast.

A huge portion of business software is stuff you can't solve with brilliance -
tasks from integrating with other companies to building out simple new
features happen at the speed of spec development, email responses, or other
non-development limits.

If the 10x myth makes employers expect 10x _productivity_ from certain devs,
or even 5x, it's badly misleading them. Not always, there are compiler
companies and ML firms and whatever else that need brilliance, but I think
most companies that advertiser for 10x developers are usually limited by
forces 10x development can't help with.

~~~
crdoconnor
A lot of "developer brilliance" is simply avoiding the inevitable slowdown
that happens when projects mire themselves in technical debt.

I've worked on plenty of projects where two smart developers would have
massively outperformed the 10-12 mediocre and highly risk-averse developers
working on the shitty (gradually getting shittier) code base over a period of
6 months.

For greenfield I don't think 10x productivity is likely though. If you're
testing an idea you might throw away, cheap and cheerful will do.

~~~
tonyedgecombe
On many of the projects I worked on there were two smart developers doing all
the work and 10-12 mediocre developers doing almost nothing.

------
mark_l_watson
I had a boss 25 years ago (smart guy, did compiler work, etc. for new computer
architectures) who claimed that there was really a 100x factor difference from
the best to the worse. I believe this: would you rather have one day of work
from Daphne Koller, Peter Norvig, or Jeff Dean - or 100 days from an average
developer? Well, the answer is that "it depends." There is a ton of work that
can be effectively done by non-rock stars, and there is some work where a 100x
person can do things that other people can't, no matter how much time they
spend.

An example: I use TensorFlow, but looking at the concept and implementation, I
don't think I could conceive of and write TensorFlow in 10 years of work.

~~~
jacquesm
> I use TensorFlow, but looking at the concept and implementation, I don't
> think I could conceive of and write TensorFlow in 10 years of work.

And this is exactly why software is eating the world. Once written it stays
written and all those people that could not write something like TensorFlow if
their life depended on it are able to use it _as if they could_.

Abstraction is a super powerful thing, all this building on the knowledge and
capability of those that came before is what makes the whole thing possible in
the first place. Probably the people that wrote TensorFlow would not be able
to design (each of them individually) the computers that it runs on, or the
operating system that allows them to run TensorFlow in the first place.

~~~
manmal
I agree very much. Just came to say that this has always been the case with
the know-how of starting fires, metal molding, forging tools and weapons,
inventing microscopy, large scale industrial processes, computers... software
is the extension of the exponential acceleration of abstraction and reuse that
our society was built on.

~~~
infogulch
I feel like there's a difference with software though. Maybe not in degree,
but in the constant factor.

With e.g. metalworking, you can transfer the knowledge but training takes
time. And building a new implementation of that knowledge takes time too.

But in software the knowledge and implementation is transferred effectively
_instantly_. You can nab software off the internet (transfer knowledge) and
start running it locally _right now_ (implementation).

Software changes the complexity from O(2^N / T) to O(2^N).

~~~
manmal
Sure, but is this not the same as buying a hammer/fertilizer/metal press and
using it for your own means? That's a quasi-instantaneous acquisition of the
result of hundreds of thousands of years of innovation.

~~~
jacquesm
Electrons move a lot faster than molecules, you could invent X in the United
States and a person in China could be using it tomorrow without any cumbersome
shipping or cultural barriers to adaptation.

The hammer, fertilizer and the metal press are all part of our tool-making
culture, ways to adopt nature to do our bidding and in the case of the hammer
and the metal press to shape it by brute force. In contrast, something like
TensorFlow is a tool of the mind which means you can encode it as bits and
those will travel the world a lot faster than your average bulk goods or
container ship every will.

So they are comparable at some level and totally incomparable at others.

~~~
aspec
Even if software didn't have tremendously higher cultural barriers for usage
than manual equipment, the rapidity of exchange is a very small component of
the exchange value for the means of software production (which is primarily
hardware anyway). The value of both hardware and software is measurable by the
amount of labor needed to produce them, so it's not even comparable--it's
identical.

------
dahart
My own productivity fluctuates by more than an order of magnitude. But that
means it's not my intrinsic ability. Sometimes it's choices. Most of the time
it's who my manager is, what choices the team (or the team before) made, how
much I care, and whether I get along with the people I'm working with.

The article is strangely defensive of the number 10 specifically; having
discussed this topic here several times I get the feeling most people on HN
already agree that there are order of magnitude fluctuations in productivity
from person to person at any given time, but that 10 itself is a biblical
number -- symbolic and not even meant to be taken literally.

I'm sure 10x has been true somewhere for someone, but there's nothing special
-- _nor empirical_ \-- about the number 10. There are more people 2x better
than average than 10x. The distribution looks like what you'd expect -- peaks
at 1 and falls off in either direction.

> You become a 10x programmer not by doing an order of magnitude more work,
> but by making better decisions an order of magnitude more often.

I think this isn't necessary to be 10x more productive. You can make a single
decision and become more productive. You can also use a single philosophy. You
can also get yourself in the right company and on the right team surrounded by
people who are smart and cooperative instead of competitive, and watch
everyone's productivity soar.

The most 10x-famous programmers I know are ruthless about not implementing
things until they need them so badly it hurts. And they keep their code
really, really, _really_ simple. No cleverness, no tricky bullshit, just
super-simple super-readable easy to understand, and literally boring code.

------
crispyambulance
Of course there are some people that are vastly more productive than others.
In business they're called "rain-makers" in programming, "10x".

Whatever the case, these people are always outliers. Unfortunately that
doesn't prevent teams from claiming that they only hire 10x's.

No one starts out as a 10x. Perhaps instead of focusing on who is or is not
10x or how many 10x's are out there, it is more interesting to explore HOW
people BECOME 10x?

A more realistic view is that individuals are a moving target. Skill is
something that needs to be nurtured, practiced and modeled by mentors in order
for others to pick it up. Orgs that just stop at the fact that people are
going to have a wide distribution of skills are doing a disservice to
themselves and their employees.

~~~
tcbawo
I have worked with many brilliant people that didn't have motivation. And if
they did, their energy wasn't directed towards the task at hand. Then, you
need an environment that doesn't get in their way.

------
mabbo
I wasn't sure I believed in 10x developers, then I thought "I've worked with
people 3.2 times more productive than me, and I've also worked with people 3.2
times less productive than me..."

~~~
fahadkhan
Wow, it's even better 10.24x developers exist!

~~~
mabbo
There may be some rounding errors involved in my assessment :)

~~~
fahadkhan
You can't be expected to exact as the square root of 10 is irrational. Perhaps
that says something about the 10x developers.

------
afarrell
Upon reflection, I just realised something: If the biggest difference in
productivity comes from the impact of decision-making, then perhaps that is
also a big part of the impact of pair programming. If you are a fresh-out-of-
uni developer working alone, then it is a lot easier to believe something like
"Even though this documentation is in Chinese, I can make do with Google
Translate. I don't need to push my manager to approve a budget for having it
professionally translated into English." When you have two people talking to
each other, the explicitness of your reasoning and verbal communication makes
it much more obvious when a decision leads to 3 weeks of wasted time.

(yes, this was my first project out of uni. A can-do impossible-is-nothing
attitude can be misinterpreted to lead you to relentlessly pushing against a
wall rather than resourcefully going around it.)

------
merraksh
_[...] They studied professional programmers with an average of 7 years '
experience and found that the ratio of initial coding time between the best
and worst programmers was about 20 to 1_

I thought the perceived idea about the 10x developer was that he/she is 10x
better than the _average_ programmer, not the worst.

So even this scientific study (from the 60s) says that there aren't 10x
developers according to this definition: the ratio goes down to sqrt(20),
using the geometric mean, if a good-enough sample was chosen. Program size and
program execution speed would put that ratio to sqrt(5) and sqrt(10),
respectively.

~~~
EliRivers
_I thought the perceived idea about the 10x developer was that he /she is 10x
better than the average programmer, not the worst_

That could well be what people perceive. It's not what the studies said. While
the article has some good references, I might as well quote Peopleware again
just for the fun of it. I churn this out every so often:

A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth,
but it's comparing the best to the worst; NOT best to median. It's also not
about programming specifically; it's simply a common distribution in many
metrics of performance.

The rule of thumb Peopleware states is that you can rely on the best
outperforming the worst by a factor of 10, and you can rely on the best
outperforming the median by a factor of 2.5. This of course indicates that a
median developer, middle of the pack, is a 4x developer. Obviously, this is a
statistical rule, and if you've got a tiny sample size or some kind of
singular outlier or other such; well, we're all adults and we understand how
statistics and distributions work.

Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence
(1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]

~~~
michaelmrose
10x the worst literally means nothing at all if you find a sufficiently bad
programmer you can have an infinity times programmer and the 10x developer as
it is normally expressed is 10x average.

Further author even punts at the end of article by claiming that its not
needed to measure difficult to measure things as we can instead reason our way
to the right answer which is practically nonsensical. Measuring is step one in
actually reasoning about things.

In short author may be a good developer but he is certainly not a 10x author.

------
didibus
I've never seen a 10x productivity, or even a 2x. I'd like to see one, show me
a scrum where one programmer takes 10 stories on the board, and the others
just did one, and he successfully finishes all 10, where the team estimated
all stories to be of a full scrum length. I doubt this exist.

Now, I've seen 10x quality, though sometimes they're a little slower, but
never 10x slower. So maybe 1.2x to 3x times slower for something on the order
of 5x to 20x quality.

That higher quality might pay off long term for the buisness in hard to
measure ways, such as faster future extenssion, better customer experience,
less work required on bug fixing, etc. If that's what people mean by 10x, I
agree, they definitly exist, in fact, compared to the worst there's probably
infinite x as people are saying, some programmers can't ever get certain
things to work at all.

P.S.: Actually, I've seen maybe 2x or 3x productivity on teams with uneven
standards, generally lacking code reviews. In those cases though, the 2x or 3x
productivity programmers always had similarly lower quality code.

~~~
poikniok
"scrum" I found your issue. I don't think 10x developers work in places that
do "scrum", as if they are some low skill assembly line worker. You think Jeff
Dean does "scrum"?

~~~
flukus
So 10x programmers don't work anywhere with a somewhat objective performance
metric? I don't think that's a coincidence.

~~~
TeMPOraL
No. Rather, they avoid places which employ procedures designed to get
consistent output out of mediocre workers. Such processes naturally exchange
flexibility for consistency of results, but lack of flexibility will cripple a
10x programmer.

------
jhh
Here's a question: Is Picasso a 10x artist?

The thing about the 10x claim is that it takes something complex and creative
and applies a scalar multiplier to it.

Talking about 10x programmers is _semantically_ problematic.

~~~
TheOtherHobbes
It's a self-serving mythology, because a few individuals can claim to be
10Xers to gain special privileges.

It's telling that there's no such thing as industry talent matrix. Instead of
general skills - creativity, accuracy, speed, debugging insight, ability to
learn new languages/frameworks, team leadership, good-to-have-around vs toxic
asshole, and so on - we have this myth of "the rockstar".

A certain kind of management loves because rockstars because having them
around reflects well on management (reason number one for hiring them) and
supposedly they are super-productive (reason number two, which often turns out
not to be true in practice, especially in a team setting.)

The hiring process tests for almost none of the qualities on the talent
matrix. There's a ridiculous notion that knowing algos makes you a developer
worth talking to, and a slightly less ridiculous notion that a bit of hazing
tells you something about how well someone works under pressure.

The bottom line: that after all these decades we have far too little research
defining the qualities that really matter in different work contexts, and
almost no research at all into how to select for them.

~~~
ja30278
There's also a certain kind of person who seems to really want 10x people
_not_ to exist.

I'm not a 10x person, but I have worked with some. I don't think they are
unique to programming..there are 10x folks in every field.

Sometimes you don't need a 10x person, and if you don't, it can seem like they
don't matter. In those cases, a few 1x people will do just as well. But I do
believe that sometimes you _do_ need a 10x person, and if you do, you can't do
the same things without them. In those cases, I'd absolutely take a 'toxic'
10x person over the nice-but-1x alternative.

Part of the issue is that there's more work for programmers than ever, and
most of that work is of the 1x variety.....if you're just banging out CSS for
some small-business website, it doesn't matter whether you have Jeff Dean do
it, or a new grad from Omaha Community college. If, however, you need to write
a new globally consistent database abstraction at scale, then the new grad
probably won't cut it. If you actually need that thing, then it wouldn't
matter if the new grad was the nicest person on earth, and Jeff Dean the most
'toxic' (though actually I understand that he's a very nice person).

------
QuantumGravy
> 10-fold difference between the best programmers and the worst.

He cites this as evidence and _still_ goes on to talk as if the observed
10x-ers were 10x average. Then he tries moving the goalpost, with talk of
high-level project decisions and code not written. Just come out and say, "A
_true_ 10x programmer does X, Y, and Z. A _true_ 10x programmer would never do
A, B, and C." Sounds more like a certain fallacy involving Scotsman when
phrased that way.

The only saving grace is that he backs off and recommends against a hiring
strategy targeted solely at ninja rock-star devs, but then he reinforces the
boogeyman of negative programmers

I get that some people are _good_. There's nothing outlandish about
Peopleware's cited figure of 2.5x average programmers, but that's not so
incredible that the 1x devs need be weeded out. There must also be a handful
of developers with IQs of 160 walking around, but there's too much demand for
talent to act as if such rarities are the baseline of who's employable. None
of this is worth continuing to blog about.

------
sbov
> Imagine traffic increases exponentially, and this average team setup an
> average website, with a data storage engine that’s hard to shard, hosting
> that doesn’t have enough redundancy, version control without proper backup,
> no CI environment, and no monitoring. How productive will those 10 coders be
> if they are spending all their time putting out fires?

The 10x developer may or may not be a myth, but the idea that you can design
your system for exponential traffic increase without any tradeoffs is not
engineering, it's fantasy. I guess "no silver bullet" is dead in the year
2017.

~~~
nostrademons
This was a weird example to me because anyone who's dealt with exponential
traffic increase knows that you will end up rewriting several times. Dean's
Law: "Plan for 10x growth, but expect to rewrite before 100x":

[https://static.googleusercontent.com/media/research.google.c...](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/WSDM09-keynote.pdf)
(page 11)

Additionally, one thing the best programmers I know have all drilled into me
is _don 't write code speculatively_. You should write code because it solves
the problem you have now, not the problem you think you're going to have in a
couple years. It's very much a novice mistake (one that I've made a dozen or
so times, sigh) to think that you can jump straight to your "ideal"
architecture without any of the steps or missteps along the way.

~~~
jaimebuelta
THIS:

 _It 's very much a novice mistake (one that I've made a dozen or so times,
sigh) to think that you can jump straight to your "ideal" architecture without
any of the steps or missteps along the way._

Code evolves as the problem evolves and NEEDS to be adapted. Is impossible to
foresee the future.

~~~
AstralStorm
This approach generates regular expensive rewrites that a typically slightly
more flexible and/ or modular solution would avoid.

The key words are slightly. The trap is to overgeneralise or apply a
technology or approach like a hammer without understanding its limitations.

Out is impossible to foresee the future, but trivially easy to see current
requirement and extrapolate a bit.

~~~
nostrademons
The problem is that you usually don't know in which direction that flexibility
will be required.

I can't count the number of times I've "trivially extrapolated a bit", showed
my boss or VP, and then gotten back "actually, we don't want to put any more
effort into X. I appreciate how you went above-and-beyond, but priorities have
changed, and it turns out we really want Y instead," followed by much
handwringing when I go back to the code and find out that the flexibility and
modularity that I built into the system expecting we'd do more of X next
actually impedes progress in making it do Y.

Lest you think this is just bad management - I work for myself now, on a
startup, and I have the same problem (or would had I not beaten this habit out
of myself). Very often, I'll think "Woah, there's a much more elegant approach
that will let me do Y and Z much better at relatively low engineering cost",
and then I'll finish X, and put it in front of potential users, and they'll
say "Actually, we don't care about Y and Z at all...why would we want them? We
want to do A and B instead", where A and B take the product in a completely
different direction from Y and Z.

There is a place for planning a little bit ahead, but that place is to plan to
reach the next milestone as quickly as possible. You should never try to guess
what the milestone beyond that is without checking in with users or
management.

------
struppi
There may or may not be 10x programmers - I, personally, find the reasoning in
the article convincing. And I think there may be programmers that _vastly_
outperform others in programming tasks. So I think there may be 10x
programmers.

But, I believe it does not really matter (at least most of the time, most
meaning something like 99%).

We are working in teams, inside a company that has a certain culture, rules
and processes. How we work together as a team and how the
company/culture/system we work in helps us in / prevents us from doing our
work has a much greater influence in overall results than individual
programmer performance.

This also includes how the system supports us in learning (not only formal
training, even though this might be beneficial) and teaching. Teaching each
other skills needed for the job, and learning how to work together so that we
amplify our collective skills and dampen our shortcomings.

~~~
lithos
It also doesn't matter if 10xer's exist for most companies.

Most just don't have the money, culture, management, fellow coworkers, or
whatever else to keep that 10xer (often times even get them in an interview).

Seriously most companies can't even keep a 10xer janitor if they tried.

------
nikanj
Hip firms only hire 10x programmers. They don't pay 10x though, the total
compensation is closer to 0.7x + free session beers. For some reason, results
have been mixed.

------
jfv
Like so many discussions that bring out the same old discussions year after
year, this one is marred by

1) Oversimplification

2) Arguing over semantics

The term 10x engineer is particularly bad because it implies something: that
some engineers are just generally 10 times more productive than others. I'm
pretty sure most engineers would be vehemently opposed to their performance or
value being _quantified_ , so why do we even bother arguing about it?

If I remember right, this term was inspired by some study that showed that
some students did their CS homework at a school (CMU?) 10x faster than other
students, and the implication that some engineers are just _that_ much better
than others as to deserve distinction.

Anyway, this is obviously true. There are some things that simply can't be
written or designed by the average coder (or teams of average coders, for that
matter), say important bits of the Linux kernel, key optimizations for your
latest AAA titles, hairy distributed protocols, etc. No amount of project
management will turn a team of average coders into one able to produce such
things. In these case, the exceptional coders are more like ∞x than 10x.

And in other cases, you might only see a marginal improvement in performance
if at all. If the task is particularly dull, a previously ∞x coder might turn
completely unproductive.

Can we just all agree the term is stupid, evokes a sort of reliance on metrics
we all hate, that hiring a team is more complicated than assigning value to
coders and maximizing, and just move on?

~~~
watwut
"say important bits of the Linux kernel, key optimizations for your latest AAA
titles, hairy distributed protocols, etc. "

THe thing most people lack in all those examples is body of knowledge, not
aptitude. All those areas are learnable by average developer.

------
no_gravity
I have no doubt that there are programmers who are 10x as productive as other
programmers. I witnessed it over and over.

But as I understand it, the "10x" means 10 times the productivity of an
average programmer. I wonder how productive the average programmer is. I find
this question super interesting.

For example, I see more and more programmers who use "Query Builders" and "ORM
layers" without understanding the underlying database mechanics.

Coding this way not only takes multiple times longer then - for example - just
writing plain SQL. It also often results in code that runs hundreds or
thousands of times slower. And complexity explodes as the project grows.

I have the feeling that - with the rise of frameworks - this might be the new
"average" of coding. If so, then there definitely are coders who are orders of
magnitude more productive then this average.

~~~
ajuc
This is not only about frameworks and ORMs, it's about refusing to
comprehensively understand stuff before you use it or change it. It can be any
abstractions, even (usually) the ones you created by yourself.

It's easier to add a special case check, than to read through the codebase to
see if it's even needed, or, God forbid, to refactor in 5 places so it's not
needed (it might break sth else!!! I would have to read and keep in memory the
whole control flow of the program!!).

Programmers have to do dozens such decisions every day, so after a few months
if they go the easy way too often it adds up and creates chaos.

I've done this myself, and seen this done by younger programmers. It's that
crucial skill of stepping a few steps back and looking at the code as a whole.

I've seen a great compact example recently, one of the students I supervised
wrote sth like this:

    
    
        List<Person> findBySurname(String surname) {
            List<Person> persons = session.find(surname);
            if (persons.size() == 0)
                return null;
            return persons;
        }
    
        ...
    
        List<Person> persons = findBySurname(surname);
        for (p : persons) {
            p.doSth();
        }
    

The student wrote both methods, and got rejection from tests because of NPE.
He wanted to fix it by adding if (persons != null) { ... }

:) this example is easy, but in more complex situations it's easy to do the
same, and it adds up. This is one of the reasons I dislike OO programming
(especially the kind where you hide everything behind a few layers of
interconnected objects). Because it makes it harder to understand what REALLY
happens on the data level.

~~~
UK-AL
I think types should not be nullable unless explicitly specified.

~~~
AstralStorm
That, much like a null check, solves only a special case.

------
retrogradeorbit
Those who complain most loudly about the 10x being a myth are those whose self
opinion of their skill (placing themselves as a 10x), and their actual level
of skill (placing them a 1x) are too far apart. Often they don't realise what
their actual skill level is until then meet and work with a real 10x in the
flesh. This makes sense because why would you care if people believe there are
10x programmers or not? Why would you be upset if people are going around
tweeting that unicorns are real? It makes no difference to anyone. It's only a
problem if it rubs up badly against your self-esteem.

------
memracom
It is not the developer that is 10X. It is the environment they work in that
is an enabler of 10X productivity. If that environment is also relatively
stable, a smart developer can learn all the levers that the
environment/company provides to them, and start achieving hyper productivity.
But move that developer to a different company and they could be a dud. Even
just an increase in the instability of the environment can thwart hyper
productivity.

The focus here is on entirely the wrong thing. It is the development
environment provided by the company that enables above average developers to
surge into hyper productivity. Good programming practices. Competently
prepared requirements. A collegial atmosphere that encourages frank and open
communication between departments.

Searching for 10X developers is like looking for a silver bullet. Silver
bullets do exist in the real world but ask a shooter whether they provide
results any better than the common kind of ammo. Mythical stories can be fun
but in the real world we have real work to to, real problems to solve, and
while you can find shortcuts generally you don't find them by looking from
them. But dive into the messy chaos of creating order out of nothing, and from
time to time you will come across real honest to goodness shortcut
opportunities that may provide up to a 10X increase in productivity. Use them
if you can, but don't waste a lot of energy in chasing them.

Also, the idea of a 10X rocket scientist is rather glamourous. But the fact is
that there are real opportunities for productivity improvements that are in
the boring details, slogging through improvements in processes, making small
incremental improvements continuously and consistently. There is more to learn
from refactoring than from chasing clouds.

~~~
Nomentatus
Some people have read far more than ten times as many math and programming
books than others, and spent far more than ten times as much time making sure
they thoroughly understand what they've read; and then gone on to tackle ten
times as many hairy projects on the edge than others because it was fun for
them.

True, an environment can encourage the laggards to catch up or fire 'em if
they have no interest in improving their skills and knowledge; but it can't
wave a wand and create the skills. I would also note that there are tenX
(plus) refactorers who can freely cut large amounts of code from large
projects without risk, too.

If you started tackling mathematical puzzles when you were eight, and
programming a couple years later you're a different species than someone who
switched majors to computing in third year for financial reasons; the early
starter's brain is actually physically different (for instance some of your
visual cortex and memory will now likely be devoted to math and logic instead
of geography, this has been measured in chess players.) Same with a concert
pianist vs someone who started playing the piano at age 20. Sure, the
environment of the concert hall or practice hall matters - just not nearly
that much.

I agree we do need to spend more time paying off boring technical debt, too;
though that's not getting much more popular.

I don't want to leave the wrong impression. There's absolutely nothing wrong
with doing a very conscientious job of coding and recoding that a whole lot of
others could also do, just with a better ethic and constant attention to
detail - we need many more such coders too, and I honor them very much.

------
tome
Something I saw on Twitter once:

How to be a 10x programmer: make 10 other 1x programmers into 2x programmers.

~~~
mathgenius
This only works when the programming task is highly parallelizable.

~~~
dom0
That's called project management fwiw.

~~~
lucisferre
Turning 1x performance into 2x performance is people management.

~~~
sbov
Tools writing.

~~~
clavalle
Tools writers really are the unsung heroes of the development world.

------
winston1984
I find the arguments in the "Programming is about choices" section a bit
contrieved.

Yes, if you have a small team of say 10 people, a very competent lead engineer
can make all the difference by setting up proper testing, SCM, CI, etc. i.e.,
by choosing the right tools and people for the job.

However, as soon as you have a slightly larger team, these decisions will
usually not be made by one single person. If you have a large project with
dozens or hundreds of engineers, you'll have dedicated teams for some of these
tasks, making their own desicions.

In my opinion, the most important thing then is to spot anything that will
make things go haywire, communicate them and convince the right people that
this has to be fixed. If you force a new porgramming language onto the whole
team because it makes you, the 10x engineer, more productive, you might face
endless discussions, additional training costs and a big backlash ("why do we
need this now?") from the team.

~~~
caseysoftware
Why do you assume it's all about code?

When I look at _great_ developers, they can not only build things without
taking as many dead ends but they can explain why and share their reasoning
with the rest of the team effectively.

The very best can not only complete their own tasks well but their "prowess"
(for lack of a better term) is witnessed and people seek out their advice..
therefore making others more effective too.

------
kgu
Arguing that 10x developers _don 't_ exist strikes me as the extraordinary
position requiring extraordinary evidence, rather than the inverse. People
vary; why wouldn't they here?

Some people argue, essentially, "programming is complicated," but even if you
want to claim that programming consists of multiple dimensions along which
programmers can be measured, how about when one person outperforms another on
every dimension by a factor of ten? What should we call that other than _one
person being ten times better than another?_

Other people argue that while 10x developers may exist, teamwork matters far
more. Well, what do you suppose would happen then if you managed to assemble a
team of _only_ 10x developers?

~~~
jononor
People vary yes, but do we have 10x variation in performance? Actually for 10x
to be a meaningful size, would need significantly more variation. Can one find
support for such level of variation in other, more well studied fields? Say
students, managers, factory workers?

~~~
kgu
Sorry for the downvotes; I upvoted you to correct. I think it's an interesting
question. There are probably fields where it's possible and fields where it's
not.

Some students certainly outperform others by a factor of ten. I'd hesitate to
score managers numerically, but it seems plausible that working for one could
feel ten times more smooth or whatever than working for another, whatever that
means. Intuitively, probably not factory workers, but prove me wrong.

10x is not actually that much. I could play basketball with Michael Jordan or
chess with Magnus Carlsen, and they'd win essentially an infinite number of
games against me without losing once. That doesn't mean they're infinitely
better, because theoretically I could through practice become as good as them,
but the factor is way more than 10.

~~~
jononor
Re 'factory worker'. When I studied, I worked part-time in a shop selling
bicycles. One of my main tasks was assembling & tuning the bicycles (they come
flatpacked). I recall that on my first day (as a 14 year old with no prior
experience), I could only complete one bike, with another one in progress. The
teaching was mostly 'here are the tools, tell us when done/stuck'. A couple
years, maybe 1000 hours of experience later, I would average around 3 bikes
per hour. So, a factor 12-15 speedup. This was basically as fast as the guys
who had been doing it 20-30 years full-time. I stayed basically at that level
until I stopped at 6 years. Note, this was no sweatshop, just a pretty active
and successful self-owned store.

It is possible that those that assemble Ikea furniture for a living have 10x
over a typical Ikea-buyer.

~~~
jononor
I can also do programming things in 1x which friends who fiddle with Arduinos
can't do in 10x the time. But they are non-professionals, and may even stuggle
with fizzbuzz.

But in a professional setting I've yet to meet a single developer I would
claim to 10x. Probably not even 5x. Unless one would look isolated at tasks
that requires specialized or domain knowledge which the other person doesn't
happen to have. And I'm pretty sure there would be tasks where same person
would nX me.

------
_pmf_
This completely misses the point. Nobody is denying that they exist; it's that
they are completely irrelevant to software engineering because software
engineering is delivering consistent (not necessarily "outstanding" or "very
good") results with the fat part of the bell curve.

Yes, you can deliver a project with the right person with 100th of the effort,
but this is not repeatable (the person will move on or very likely work as
singleton contractor). If you get a 10x developer at the rate of the 1x
developer and can convince him to stay at this pay grade, then we would be
having an actual topic to discuss.

~~~
Nomentatus
Look at the number of massive outright software project failures (no delivery,
ever.) I think there are many times when you'll cheerfully pay at least ten
times for the one guy who could actually get you to the finish line.

------
trevyn
Yeah, the first argument backs the notion that there are developers who are
10x better than than the worst developers -- I take "10x" developer more to
mean 10x the average/typical developer.

Also I love, love this line: "10 engineers writing the wrong code could
definitely be out performed by a single engineer writing the right code."

Especially as it extends up the chain -- 10 employees building the right
product can outperform 100 employees building the wrong product. Etc.

------
reducesuffering
"They found no relationship between a programmer's amount of experience and
code quality or productivity."

and

"From years of experience, a great programmer will know that errors are much
more costly to fix later."

So which is it?

~~~
franciscop
Contrary to @iaweihli, I think the error is in the first one and that they
originally meant: "They found no relationship between a _0.1x_ programmer's
amount of experience and code quality or productivity."

------
freyir
I've certainly known some 1/10x programmers. I'm a 10x programmer by
comparison.

~~~
tobyhinloopen
How about negative-times programmers: Programmers that decrease productivity
by introducing bugs and broken features that costs more time to manage & fix
than the sum of the value added.

Programmers writing features that add points of failures to previously working
systems

~~~
eecc
Oh yeah, those abound... and they tend to believe of themselves they're the
10x material that no-one understands. That's case study Dunning-Kruger

~~~
flukus
I think management believes this too. They're checking off their tasks list
like crazy, so they must be productive...

------
eecc
Obligatory reference to a book that spends quite some time on - debunking it -
this 10x myth:

[https://leanpub.com/leprechauns](https://leanpub.com/leprechauns)

I liked it

------
nabla9
Many personal attributes are normally distributed. Normal distribution is
formed as a sum of several independent random variables with mean and
variance.

There are reasons to think that productivity is multiplicative and not
additive property, leading to log-normal distribution. Person who is hard-
working × experience × motivation × single-mindedness × self-management skills
× 2sigma IQ can get ahead of person who just has the smarts.

Prime example of '10x' programmer is Richard Stallman.

Extreme Pair Programming - Guy Steele and Richard Stallman [http://cycle-
gap.blogspot.se/2007/09/extreme-pair-programmin...](http://cycle-
gap.blogspot.se/2007/09/extreme-pair-programming-guy-steele-and.html)

------
jaimex2
It's really not that difficult to explain, Programmers are like musicians. You
have the ones that have over 100,000 hours of dedicated professional practice
and are grandmasters, those that play in a band, and those that do it
casually.

------
uranian
10x is a metaphor. I believe we also have 2x, 3x, 8x dev's, it's a very
relative factor. But it sure is an illusion to think that 10 average
guitarists together will produce better results than hiring Paco de Lucia or
Jimi Hendrix if you like.

It all depends on the job to be done and being the right fit. But some people
have this talent and skill to make the right decisions split second, over and
over again.

I definitely prefer one 6x dev over 6 average developers that are creating a
horrible spaghetti of bad ideas and poor decisions, not talking about all the
meetings they need to align and try to fix the mess they continuously create
themselves.

------
snovv_crash
The difference between an average programmer and a "10x average" programmer is
in the architecture and design phase, not the "fill in the methods for the
API" stage. If you put people who don't have domain knowledge (or experience)
in charge of API design the resulting codebase will easily take 10x longer to
complete (if it is ever finished), and maintenance will probably require 10x
the manpower.

Doing good design and tooling upfront is at least a 10x opportunity. Too often
I've seen it get brushed off by people who want to see quick results, to the
detriment of the long-term design goals.

------
Ologn
After doing an extraordinary number of technical interviews of people, I began
to think of it as a Gaussian curve with a normal distribution. Despite
headhunter filtering, resume filtering, and short phone interviews, one out of
six people slips through those filters without knowing much. On the other
hand, one out of six can answer pretty much every question, clearly and in
some depth. These are the people, the unprepared and the very prepared, who
are one standard deviation below and above the mean. Insofar as the other four
of the six, they all are more-or-less average. They are working at the job,
and are competent, but minimally. They can give basic answers, but can't go
into much depth on most topics. They are kind of an amorphous blob that blend
into each other.

For example, I used to ask sysadmin/devops people what syslog was. One of six
would not know, four of six would give a basic answer, one of six would give a
more in-depth answer. Then I would ask what syslog's various facilities were
and what the severity levels were. Only one of the six would give a good
answer.

Actually, I program Android now, but knowing the order of severity is still
useful as it is in the same order in the Log class (althouh they add one
beyond DEBUG - VERBOSE).

Once I read an article about the top people at Google, and they claimed these
people are three standard devíations above the mean. I noted that the author
saw this in the same pattern I did.

~~~
nradov
And yet there is no real scientific evidence that performance on technical
interviews actually correlates with job performance.

------
mehh
Its not about programming skill, its about focusing on the right thing. Many
very technically good developers can be very productive at engineering stuff
no one needs.

------
afarrell
The natural follow-on questions are:

What are the decision-making habits that make someone significantly more
productive on a software engineering team?

What are ways to imbue a team with these habits?

~~~
Nomentatus
Good questions. You should post an AskHN for this.

Someday we'll have "problem-solving" classes in elementary schools to help
teach those basics; and better unambiguous communication, etc. One habit
that's been well-documented for a long while is that the best problem-solvers
take more time being sure they've understood the problem correctly and
settling on an optimal approach before charging in doing the work.

The best habits that often spring from good character - I agree with Bourne on
that - those with neurotic motivations or insecurities may choose "solutions"
that show off their ability with some extra arabesques, rather than taking a
more straightforward path that's best for the company, for example. Not to
mention being willing to possibly embarrass yourself by asking what may or may
not be "dumb questions." That's huge.

------
maxxxxx
I think we should talk more about 10x organizations. A lot of people can
perform well if they work in a good environment. Most 10x people I have seen
had the ability to do what they needed to do to get the job done. Give them a
process where they need approval for everything and have to report every day I
think the 10x is gone soon.

------
danschumann
"There are only a handful of people who can tell the difference between you
and me, but I'm one of them" \- Professor from Good Will Hunting

The main difference (besides using vim) of a 10x programmer, is being able to
immediately envision 5 ways to solve the problem, mentally following that path
and seeing the pros and cons of each.

The 10x programmer probably does really hard stuff on weekends for fun.

The 10x programmer doesn't give a shit about your paradigms if they don't make
the code more maintainable.

The 10x programmer's code is fun to read.

The 10x programmer's code could be read by a non-programmer and they could
understand the jist of it.

The 10x programmer can't tell you the 'most interesting bug' they've ever
found. The solve bugs all the time. They solve them and move on, and remember
the lesson, but not the bug.

The 10x programmer doesn't fit in well at the office and usually has to start
his own business.

He also types fast.

~~~
pavel_lishin
> _The 10x programmer doesn 't fit in well at the office and usually has to
> start his own business._

Is a 10x programmer also a 10x businessman?

~~~
Spooky23
Perhaps there are many roads to 10x!

What if 'x' is transitive? Is the 10x programmer, 10x businessman 100x?

That might explain things. I've seen plenty of 0.5x programmers who are 20x
bullshit artists.

------
kharak
I wonder what you should do if you are one of these 0x programmers. Throw away
your degree and change career? Or try to close the gap? But what if you really
aren't able to become one of the 10x?

I wonder because I feel that this is my situation. The people I started
working with are so much above my skill level, it's ridiculous.

~~~
billyjobob
If you really are 0x then yes you're in the wrong job. But first read up on
[https://en.wikipedia.org/wiki/Dunning–Kruger_effect](https://en.wikipedia.org/wiki/Dunning–Kruger_effect)
and
[https://en.wikipedia.org/wiki/Impostor_syndrome](https://en.wikipedia.org/wiki/Impostor_syndrome)
because those are much more likely than a 0x realising they are a 0x.

~~~
Nomentatus
I like this. Plus, related to the Imposter Syndrome - you might be
conscientious, and they might not be.

------
andrewstuart
I'd suggest there is no quantifiable way to measure what "a good programmer"
is.

Nor is there a way to quantify "good code" in any scientific manner. It IS
possible to identify obviously bad code, BUT "good code" comes in a variety of
forms and looks different depending on the experience level of the developer.

In the end, many of the measures that people apply to assess programmers are
simply a matter of personal opinion.

edit: downvoters - if you think I'm wrong then please explain your counter
opinion, don't just downvote. A downvote without a counter opinion simply
confirms my assertion that there is no science to this because you won't
identify what that science is, you have only a vague opinion that I am wrong.

~~~
Nomentatus
I disagree - wish you hadn't used the word science when you probably meant
verifiable or respectable, too - but I upvoted 'cause you used a great
transcendental argument vs your downvoters. My comments on measuring are
elsewhere here. I think it's difficult, and something Muggles in management
get way wrong most of the time, but that's another matter from whether it can
be done or is done, all the time.

------
psyc
Strongly agree. I've worked with several.

Now have a blast whatabouting, caveating, and arguing definitions!

------
pklausler
My problem with the concept of a "10x" programmer is that its baseline is not
well-defined. Who's the 1x programmer? Figure that out and then we can have a
fun discussion about the existence of 10x (and maybe -10x) programmers.

~~~
Nomentatus
It's a baseline that's changing rapidly (mostly for the better) and that will
be so for a while. So it can't be an absolute value or static variable.

------
bsaul
Another way to think about it : have you, from the time you started working in
comp science, to now, become 10x better ?

I don't think a lot of people with 10+ years of experience would say no ( if
you do, it may be time to change company).

~~~
tobyhinloopen
You could extend that logic: Since I couldn't code at some point in time and I
can now, I've become infinitely better at it.

Compared to someone that can't code I'm infinitely faster in theory. Do note
that in reality, if someone that can't code needs to write code, he'll likely
learn to code first. However, once he learns to write code, he is no longer
someone that can't write code.

The 10x programmer isn't 10 times nothing, of course. The 10 times rule is, I
think, 10 times better than average. So we have to know the average first.

The amount of programmers rises very fast: IIRC, the amount of programmers
doubles every 6 years or so. The average programmer therefore has 6 years
experience.

The 10 times programmer has to be 10 times better than that. How is he 10
times better? He has to be able to beat a 10-person team of people with 6
years experience on average. That is a team of 4 juniors with 4 years
experience, 3 "medium" programmers with 8 years experience and 2 senior
programmers with 10 years of experience.

Imagine a contest where you have to develop a huge SAAS management-like
system. One team has the 7 developers described above. The other team is the
solo mythical 10 times developer.

Well, I think the 10 times developer is going to have a head start, but he's
going to burn out within 2 months, releasing nothing and starting a new
project somewhat later. The project manager now has to find a new 10 times
developer, but he finds out that no-one can replace him and they need to start
over.

Meanwhile, the 7 developers are playing table-tennis and having boring
meetings and finish the product much later than planned, but it is done and it
sells fine.

~~~
bsaul
You're right, my thought experienced only proved that it is possible for a
developper to be 10x better than another one, with the same brain, only more
experience.

About your project, i had the experience of building the exact same project (
an product demo ios app with a web backend and its content management
interface). First project had to be done using "enterprise" practices, and the
other was free. First one i did with a senior developer helping me on the web
interface side, the other with an intern i had to explain what MVC was.

First project took 6 months, plus 2 more because of some guidelines i didn't
respect first, plus a whole team of admins to handle the production side. It
probably costed more than 100k to the company ( not counting the internal days
spent in meetings). The internal team that was supposed to maintain the code
wasn't able to do so.

The other took less than 3 months and costed something like 10k, including
server cost (i used app engine). The intern made the project evolve for more
than a year.

A 10x developper is not just able to produce more, it can prevent you from
falling into traps that can simply lead your product to a complete failure,
and your company to simply cease to exist.

------
sebringj
Demis Hassabis, John Carmack and Elon Musk ARE 100X developers. Why stop at
10X?

~~~
uranian
10x developer is just a metaphore, not based on some mathematical model. For
me it relates to the difference between an average singer in an average band
and Prince or Whitney Houston for example.

~~~
sebringj
Yah its hard to give it a direct number but to say its a myth is just
obviously wrong given the evidence of these brilliant minds we know exist.

------
whazor
Comparing developers is like comparing apples to pears. The vagueness comes
from the fact that software development is such a broad profession. It is a
combination of many different factors, for example handling with databases is
totally different than graphics. Of-course there are big differences between
beginners and experienced software developers, but it becomes harder when you
compare specializations.

Furthermore, I do want to note that understanding user needs can greatly
improve your effectiveness. Because not building something can save you
multiple weeks or months of programming.

------
_jezell_
If the problems we solve are NP hard problems, it stands to reason that 10x
quicker solutions are actually not that impressive and certainly would be very
likely to exist. Suggesting that certain people aren't able to arrive at
solutions that are an order of magnitude better or develop workable solutions
an order of magnitude more quickly is clearly ignoring reality.

~~~
Nomentatus
I had a hard time sorting out your meaning, but adding NP to the mix is
delicious so I can't resist replying, and I hope I get it right.

I take it you mean something like this: In the real world, NP hard problems
are "solved" by approximations; and the range in the accuracy (and speed) of
various possible approximation algorithms is immense in many or most cases.
Which means you want your best woman doing the job, 'cause she's easily ten
times better than the next man up, in fact her final algorithm might be
thousands of times better and faster than her previous try last week and yet
still leave a crazy amount of room for improvement, one day.

------
coldcode
The problem with this 10X myth is that no one ever defines X. Lines of code?
Inverse of defects found? Delivering in 1/10 of estimates? There is no
definitive way to measure the end result of what people develop and any of
these values can be gamed. Clearly there are major differences between
programmers but turning it into math is not really possible.

------
wolco
I think everyone can have a 10 times day or week or project but outputting at
that rate over a long period of time is the issue.

------
wielebny
Referenced study: Exploratory experimental studies comparing online and
offline programming performance (Sackman, Erikson, and Grant) -
[http://dl.acm.org/citation.cfm?id=362858](http://dl.acm.org/citation.cfm?id=362858)

------
hobls
The area that I see this really come into play is with problems that the
developer initially doesn't know how to solve. Some developers learn and adapt
10x faster than the average developer, and it seems like they're never
blocked.

~~~
yoklov
IME a more common case is overengineering. Not only does this slow someone
down initially, but the extra complexity often continues to slow them (and
anybody else in the same codebase) into the future.

~~~
hobls
Yeah, that's part of what I meant. If the path is totally clear; "add API to
existing codebase, write tests, do CR, commit" then I don't think you see as
much 10x behavior. If it's a new technology that the team isn't familiar with,
or a tricky API for some reason, then solutions can start getting totally
overengineered, and it can spiral out of control.

------
moron4hire
I think the point of "10x" programmer is largely missed because we're looking
in the wrong place: at the 10x programmer. It's better to look at what
comprises the implied 1x programmer. If it's the mean, then there is a really,
really long tail of programmers out there that are really bad at their jobs.
It's quite easy to be 10x, 100x, or even infinitely-x better than them.

Infinitely times better? There are just some problems that bad programmers, no
matter how much effort they expend, will never solve. Even if I take 10 years
to solve a problem that a bad programmer will never solve, that makes me
infinitely more productive on that sort of task over the bad programmer.

"But how many problems like that will you ever encounter in your career?" If
you're content being nothing more than a CRUD website developer, then not very
many. If you want to do more with your career than collect a paycheck, then
you can structure a career around doing nothing _but_ solving new, hard
problems.

I'm a very productive programmer over most people because not only do I know
how to do lots of things, I can employ them very quickly. I know it's popular
to say we don't have to memorize things in the era of Google and
StackOverflow, but there is a real, significant, large productivity
improvement for not having to context-switch. I use Google and StackOverflow,
sure, but let's be honest, most of the time is spent just trying to figure out
what half the questions are even asking, say nothing about whether or not the
"accepted" answer is correct and relevant to our tasks.

No, I don't have everything memorized. It's impossible to memorize everything.
But that doesn't mean not memorizing things out of some sort of perverse spite
is a winning strategy. No one strategy is the best strategy; a myth we
consistently perpetuate in this field despite the constant evidence to the
contrary. You have to employ _all_ strategies. But all most programmers have
is googling. I have googling _and_ a larger corpus of memorized knowledge.

------
VikingCoder
It's all about domain knowledge. Duh.

The value of a software development team is their ability to create new
intellectual property similar to things they've made before. (Or maintain an
existing system, of course.)

~~~
Nomentatus
It's a big part of it, but careful about what you mean by "domain knowledge."
Look at Richard Feynman's stint as an analyst for Kurzwiel as parallel-
programming got underway; in theory Feynman had no significant domain
knowledge but in fact the immense range of mathematical knowledge he brought
with him turned out to be extremely valuable, perhaps irreplaceable for that
particular project (given how creative he was.) He really was a (more than)
ten times guy, there.

------
billions
Using an analogy of biological evolution, the "engineer" that nails the right
"mutation" on a project can impact its scale of success by orders of
magnitude.

------
smithsmith
Not just 10x, just infinite. I am fairly a decent programmer but still i think
i will be not able to write a kernel from scratch in a decade.

------
InclinedPlane
The problem here is that the concept got off on the wrong foot and has stayed
on the wrong foot since then. The conceptualization of software developers as
some sort of industrial worker who churns out widgets all day long is simply
ludicrous. In the days back when a lot of software development involved just
doing the same thing repeatedly for hire the measurement of "productivity"
based on "output" at least had some basis in reality. But that era didn't last
long, modern software development is an incredibly automated endeavor. We use
automation (compilers, linkers, IDEs, unit test frameworks, and so on and so
on) to take out a lot of the drudgery that previous generations had to grapple
with more directly. Today productivity in software development is not about
churning out lines of code (even assuming it ever was) it's about building
stuff that has a high value (to users/customers et al) and low cost
(operationally, tech debt. wise, and so forth). And there, of course, the
range in productivity spans not just one but _many_ orders of magnitude
between the highest and lowest tier of coders.

There is a small group of folks (charitably tiny, uncharitably maybe like 1/4
of all devs) who on average contribute negligible or even net _negative_
overall value vs. cost to the code base as they work. And there are some folks
whose individual work has a value of upwards of several billion dollars. In
between there are perhaps bunches but it would be a stretch to imagine that
there were only one bunch where the vast majority of other devs were collected
within a single order of magnitude in terms of the value of their work.

And, make no mistake, I'm not just talking about moving up the "hierarchy" or
the management chain in terms of value. Even if you restrict your dev. sample
to just individual contributors with more or less identical work
responsibilities (instead of say, junior intern vs. principal architect or
somesuch) you will still find _many_ orders of magnitude difference in value
and quality of work.

The reason why this isn't objectively obvious is that so much of software is
invisible. Yes, you can in principle read all the source code but in practice
that's not tenable. And we still do not have all of the tools, models, or even
terminology to concretely break down the structure of complex software systems
into representations that aren't _extraordinarily_ handwavy and overly
simplistic basically almost immediately (compare, for example, an electronics
wiring diagram versus a UML diagram or a layer representation). That coupled
with the fact that software development is a creative and even artistic
endeavor where the value of some piece of work can vary greatly between
otherwise very similar examples (which is much less true of, say, bridges or
diesel generators) means that estimating the value of a given developer's work
a priori is enormously difficult. Indeed, that also explains why hiring is
such a constant struggle.

~~~
Nomentatus
Back in the day, the concept started out very well as a way of trying to
convince Muggle bosses (etc) that coding wasn't pretty much the same as
bricklaying, with most bricklayers being about the same in precision and
productivity.

------
kelvin0
Would John Carmack be considered a 10x developer? If so, I think we cannot
dispell the Myth.

------
tuananh
antirez on "the mythical 10x programmer"
[http://antirez.com/news/112](http://antirez.com/news/112)

------
vt100
Surely the 10x CEO is a myth, though?

------
kashkhan
just like the 10x CEO. They just make the right decisions and hence are
compensated accordingly.

Companies like MS and google have sufficient data to tell us whether the 10x
programmer is a meaningful term.

~~~
IIIIIIIIIIII
> _just like the 10x CEO. They just make the right decisions and hence are
> compensated accordingly._

A lot of being a successful CEO is being at the right place at the right time
(of course: _in addition_ to actual qualities).

Anecdote time:

I once was a franchisee of a major (services) franchise that some time ago
decided to expand to Germany (I sold my franchise years ago). I'll only talk
about one person, but this happened throughout the network, it wasn't nearly
as successful as hoped in this country.

So anyway, I personally know one of the guys who lead one of the best
franchises in a major German city. He expanded, became responsible for the
entire wider area (which allowed him a cut from all franchises in it in
exchange for recruiting new franchisees and for advising them).

He had this exact opinion (and he was a former business consultant too, I
think he even has an MBA), when a franchisee didn't do well that he just
wasn't good enough. He himself was proof, after all, just do your customer
acquisitions and all the necessary stuff,and success will eventually come! It
worked for him!

When a franchisee failed he acquired their shop, it was in the same city and
they seemed to be in very good areas, lots of businesses that fit the
description of the target market. Not a big risk one would think given that
his own shop was doing exceedingly well with the exact same demographics, just
a few miles away.

Long story short, he ended up giving up the franchise for the area as well as
the two additional shops he had acquired. Today he has just that one original
location. Turned out that the exact same extremely successful guy only managed
to be successful in _one spot_. Not even in very promising areas just a few
miles away did it work out!

There were more stories like this, some of them I knew personally (through
franchisee training at the beginning where I met many of them), all people who
were formerly employed and "important people" in their jobs, and who all
thought that it's all about _you_ and the effort and skills you put in. Some
of them managed to indeed build a successful business, but they all became
much more humble over time, because they all found the large amount of
randomness in their success when they tried to expand (area franchise or
another shop).

So, tell me again about those successful CEOs, I'd like to learn more... the
books are full of such people, successful in one place and time and failing in
another place and/or time. Because they themselves are only _one ingredient_
into what is needed for success, and not even the major one ("necessary but
not [even nearly] sufficient").

~~~
Nomentatus
Right. Survivorship bias. Totally a thing.

------
deathanatos
These things make my blood boil. I'm going to allow the assumption that 10x
programmers even exist.

First, it's elitist. This isn't a professional athletics team, this is the
workplace focused on engineering. _Most_ places are not chock-full of the
10x'ers; I need to depend on other people to do things for me, and them on me;
not all of us are 10x'ers, and it behooves all of us to work as a _team_. The
10x discussion distracts from that: a functioning _team_. Further, people seem
to want to worship these "10x" programmers and forget about training anyone;
we'll just hire 10x-ers only.

Second,

> _Imagine traffic increases exponentially, and this average team setup an
> average website, with a data storage engine that’s hard to shard, hosting
> that doesn’t have enough redundancy, version control without proper backup,
> no CI environment, and no monitoring._

This is exactly the output I imagine coming from a "10x" programmer: that
person has been able to output at such a constant clip by writing code with
enormous technical debt. I've had to work on these systems, and they're a
PITA: how productive could _I_ be if I didn't have to deal with the decisions
of the guy who, judging by the codebase, was shoveling code out the door as
quickly as possible?

(i.e., what if a study held the programmer constant, and varied the
environment? I bet I could be _much_ more productive if I worked on a codebase
that didn't fight me at every turn.)

Last, the assumption; the article claims there are numerous studies on the
matter … and cites none. What we _get_ is a SE answer that contains a dead
link to an article containing citations, which thankfully was quoted in the SE
answer (but screw hyperlinking to anything). The first I can't find, the
second's abstract doesn't seem to support the notion of 10x's ("Understanding
and Controlling Software Costs"; the abstract indicates that it's about
understanding software cost estimation[1]), the third is a _book_ , not a
study, the forth is a study wherein the participants are told to use different
methods of implementing the solution (the research appears paywalled, so I can
only see the abstract; and thus, doesn't apply), the next is too vague to tell
as it "summarizes the results of […] investigations in the areas of design
practices, coding techniques, test/verification methods, and computer
utilization" and is paywalled, the next seems relevant but is paywalled,
paywalled, paywalled, this is also a book ("Peopleware"), this is also a book
("Software Productivity"), this one is relevant and available[2], but it
doesn't look like a very big sample?, and the last two I've lost motivation to
find.

[1]:
[https://ai2-s2-pdfs.s3.amazonaws.com/2147/c6218db2e35d40f4a7...](https://ai2-s2-pdfs.s3.amazonaws.com/2147/c6218db2e35d40f4a7bdb87ed47e3814ef4b.pdf)

[2]:
[http://www.dtic.mil/dtic/tr/fulltext/u2/645438.pdf](http://www.dtic.mil/dtic/tr/fulltext/u2/645438.pdf)

~~~
Nomentatus
Controlled experiments are in order. The article cites "Curtis 1981, Mills
1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and
Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000" I'm sorry the links
don't work, but that still sounds like a traceable bibliography to me. I just
tested Google on one study, and found it (paywalled I assume) - "A summary of
software measurement experiences in the Software Engineering Laboratory
Article in Journal of Systems and Software 9(2):137-148 · February 1989 with
19 Reads DOI: 10.1016/0164-1212(89)90016-2 · Source: DBLP"

~~~
jdlshore
Lauren Bossavit has taken the trouble to trace those citations. His book about
his search for the truth behind those claims (and several other common
software engineering beliefs) is well worth reading:

[https://leanpub.com/leprechauns](https://leanpub.com/leprechauns)

~~~
Nomentatus
This is a general point, probably should be directed to the article itself,
not a discussion on whether the bibliography given there exists or can be
found; your URL risks being overlooked at this depth on a different point.
Thanks for it, though.

------
throwit2mewillU
There are two kinds of developers:

1\. Those who are good developers 2\. Those who can't write any real code
(cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the
years because they were not able to FizzBuzz)(25%-50% of the market)

The 10x comes from comparing (1) and (2) - although dividing anything by 0 is
larger than 10x.

~~~
nbevans
+1 however I think there is a 3rd kind of developer as well. The 3rd being
those who CAN do fizzbuzz/codekata style tests but when faced with a real
programming problem in real code base they falter.

~~~
Danihan
There are a thousand gradients of skill level, dividing it into 2 or 3
stereotypes is facile and pointless.

~~~
zeofig
There are actually just millions or billions of discrete points, one for each
programmer. Implying that they can be approximated by some kind of continuous
gradient is quite frankly insane and unfounded.

~~~
kgu
The gradient covers all the hypothetical programmers that could exist but
happen not to.

------
jlebrech
10x only works if you're a team player or if the company is organised in a way
that encourages team work.

the 10x is just the guy that's already overcome this blocker that a more
junior coder could spend a day on, and if the company doesn't encourage
teamwork the junior is still taking a day and the senior is appearing 10x when
he should be assisting other coders.

there's more value in a team being 3x than one person being 10x.

------
Pica_soO
Everyone can point at some poor maniac whose whole self-worth is derived from
work and exclaim - he is the 10x. But the fact remains, if you choose the
insane as a example, you have a insane standard.

------
replete
Lol

------
wlmeldmanfloch
This clearly bothers you so much you had to write an article about it.

