
Qualities that I believe make the most difference in programmers’ productivity - sathis
http://antirez.com/news/112
======
simonw
In this thread: mostly people responding to the headline, not the actual
content of the article.

There's some fantastic stuff in here about how great design is the key to
increased productivity. For example:

"It is very important for a designer to recognize all the parts of a design
that are not easy wins, that is, there is no proportionality between the
effort and the advantages. A project that is executed in order to maximize the
output, is going to focus exactly on the aspects that matter and that can be
implemented in a reasonable amount of time. For example when designing Disque,
a message broker, at some point I realized that by providing just best-effort
ordering for the messages, all the other aspects of the project could be
substantially improved: availability, query language and clients interaction,
simplicity and performances."

redis itself is a masterpiece of pragmatic design - the feature set is
brilliantly selected to make the most of what you can do with shared data
structures exposed over a network. Let's talk about that.

~~~
colomon
Another great thing here: "Design sacrifice: killing 5% to get 90%."

I remember a very specific example of this from Perl 6 development circa 2009.
perlgeek (I think) and I had been struggling with coding up the sequence
operator for a couple of months. Every time we thought we had it, someone
would come up with a case that broke the system again.

pmichaud (not sure if it's the same pmichaud here on HN) comes up to us and
says something like, "Guys, you're not getting this, let me do it." And I was
kind of offended, because it wasn't like perlgeek and I were chopped liver;
why did he think he could easily solve a problem that had been plaguing us?

But here's what pmichaud did. He went up to TimToady (Larry Wall) and said,
"There's too much magic in the sequence operator. We need to simplify it." I
don't know which combination of the two of them came up with the details, but
less than 24 hours later the spec had been changed so that there was no magic
on the right hand side of the operator and they had a working implementation.
Any sequence possible before was still possible, but the user was required to
be more specific about what they wanted. After the change the median sequence
took maybe two more characters to specify ... but suddenly 90% of the hard
part of coding the operator was gone.

~~~
gav
Finding a better solution by changing the problem is great, especially as the
problem stated is often not the problem faced.

Not doing something, or doing something dramatically simpler, ends up with
less code being written. The cost of writing the code is usually a small
fraction of the cost of supporting it during over the life span of the system.

One problem I faced was a client that as part of an e-commerce re-
implementation brought a huge list of requirements for promotions and how they
should work. There was hundreds of use-cases, some being very complicated.

I came back to the client and said, "are you sure you need all of this?" After
working with them to investigate, it turned out that they had just documented
all the features of their existing system. In the previous ten years, they had
created exactly one coupon, and that was for a flat 10% off.

That was the functionality we initially went live with.

~~~
jakobegger
This is the difference between a real programmer and a coding monkey.

Coding monkeys consider the spec the problem and try to write code that solves
it.

Programmers consider the spec a part of the solution and evolve it as
necessary.

~~~
bigiain
Interestingly this is pretty much "valuing individuals, working software, and
customer interaction" \- the core of the agile manifesto, but the bits that
never seem to ever show up in "Agile" workplaces where way too often rigid
compliance with standups, scrum meetings, and evenly sloped burndown charts
(and foosball table, bean bags, and free energy drinks) are all "critical to
the process", and fixed price engagements and hard deadlines are "the business
reality"...

------
struppi
Everything from the original post sounds reasonable, you should absolutely
read it. Just some random thoughts to add to it:

* For most of my past clients, the skill / output of their programmers was _not_ the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else).

* Software is a team effort. Improving how the team works together / how work flows through the system probably has a bigger impact than raw programmer output (unless you are already _very good_ at that).

* Improving the quality of your software (minimizing defects and rework) will improve the output of everyone in the team, regardless of how good they are.

* I have heard of cases where removing the "top programmer" from a team made the whole team _more_ productive, even though an important person was missing. I don't have data to back that up, though.

Update: Thinking more about this... I have a talk called "Your Company Will
Never be Agile", where I talk about how most companies actively prevent their
people from doing a good job (by having policies, procedures and a company
structure that is not suitable for empowered teams). And then, those _same_
companies complain that they cannot get good people and how all the hip
companies can get the 10x programmers that "we cannot hire".

I don't have an English recording of the talk, but I started a series of blog
posts about it:
[http://devteams.at/your_company_will_never_be_agile_intro](http://devteams.at/your_company_will_never_be_agile_intro)
. I should maybe finish it some day ;)

~~~
sametmax
Come on, Antirez is a x10 programmer, he coded one of the most brillant
software of the last decade. It's so well done I use it as an example in my
trainings, making people compile it to stop being afraid of building from
source because I know it never fails and it's so damn simple.

And programmer reading anything on his blog, or anything on HN for that
matter, is not an average programmer anyway. The simple fact you are
interested in your work singles you out.

Guys, you need to come out of your super power bubble and come to work down
here. Where people uses PHP, SVN, and don't know what an environment variable
is. Where they work for money, not for passion. Where Vi is scary and they pay
the licence for Oracle even if their DB has one table.

This is the huge majority of the devs : plumbers.

I find it disrespectful when people don't realize this, because it means they
live a life ignoring a vast majority of dev tool users.

Not only those people are numerous, but they create a lot of wealth because
they are so many.

Don't assume:

\- devs know the command line

\- devs know how to setup a server

\- devs know how to use a package manager

\- devs know how to version control, unit tests...

And above all, if they don't know how to do that, don't assume they can't do
their job. Because according to their employer they do. And they are paid for
it.

They won't do a graceful reload, they won't compress their css and won't
escape the user input. But the website will be online, serving customers.

This is why on my blog I have articles explaining what's javascript, what's
RSS, how to setup the Windows PATH, etc. Because for important tutorials on
Python, I can reference those, not assuming people know what I'm talking
about.

~~~
fnord123
So you're saying that 10x developers definitely exist, it's just a
disappointing state of affairs.

Like how the Turing Test was rendered obsolete because online comments (e.g.
Youtube) became so bad, the bar to writing a bot that passed as one of them
was lowered dramatically.

~~~
sametmax
Lol, I didn't know about the Turing Test state. Hilarious perspective.

------
Scarblac
This bit articulates what I consider to be the main advantage of experience in
programmers:

> Often complexity is generated when there is no willingness to recognized
> that a non fundamental goal of a project is accounting for a very large
> amount of design complexity, or is making another more important goal very
> hard to reach, because there is a design tension among a fundamental feature
> and a non fundamental one.

It happens all the time that requirements are very complex. Junior programmers
will fail to implement them. Better programmers will manage to implement them,
but it'll take too much time to develop and especially to maintain their
solution.

Experienced programmers recognize what's happening and have the personality to
stand up the project leader and get a simplified version of the requirements
accepted.

It's also why very large software projects fail, especially the type that is
intended to save costs by replacing many different existing informal systems
by a unified one. The requirements will be ridiculously complicated (have to
do everything all the projects to be replaced do), and nobody in the software
development part has the power to change the organisation first.

~~~
jeremyjh
>The requirements will be ridiculously complicated (have to do everything all
the projects to be replaced do),

One of the biggest problems in this type of project is that many requirements
are unknown. Yes, the new system must do what the old system did, but no one
can write down exactly what that is.

~~~
teh_klev
I'm working on a project exactly like this. I'm merging two billing systems.
One of these is a legacy mudball of classic ASP and it's a veritable snake pit
of nested includes and globally defined variables that just magic themselves
into existence out of no-where.

It's been very hard to define tasks and timescales because there are little
dark corners and special edge cases in the legacy mudball that don't
immediately jump out at you when trying to review the code and work out what
the hell it does, and why. The original developer is long gone and there's not
much way of commentary in the code. A lot of the code is illegible because
somehow the original dev's indentation went mad at some point in the past.

Then there's the database....

------
whatever_dude
I started the week as an 1x programmer.

The lead on my current project micro manages every point of the code's
architecture. I have no freedom to make any calls, even on legacy parts of the
code that could be refactored to better fit new requirements. None of the
other developers "own" anything so no one can make any calls. Anything takes a
week or more to be discussed. Arbitrary non-obvious decisions have been made
in the code base and it's up to you to figure them out. I am left fixing
simple bugs and building things very slowly, treading very carefully rather
than making it right. I am now a 0.8x programmer.

I look at my week's schedule. I see that I have a lot of meetings and checkups
that, while important, are unrelated to my current project and will only take
a chunk of my time and energy. I am now a 0.6x programmer.

I work in an open space office where terrible music is played through its
sound system the whole day. I have a hard time focusing and staying focused. I
am now a 0.4x programmer.

\--

While I enjoyed the article, I think it overlooks the fact that a developer's
efficiency is also often a factor of their environment (not just physical, but
the project itself too). I've been 5x, I've been 0.1x, and the biggest
contributing factor from project to project has been my environment. My
experience and knowledge is also a factor, but this changed slowly, over time,
while environment changes can mean I'll go from being super productive to very
unproductive in a month. More managers and leads need to be aware of that.

~~~
amorphid
>> I have no freedom to make any calls

It took me a long time to realize I don't have to say yes to everything that
comes my way. What happens if you say some version of, "I'm not going to do
that"? It may or may not be tenable option in your situation.

It's like going to a party, the host keeps offering you food, you eat
everything offered to you, and then blaming the host when you gain weight.

~~~
whatever_dude
I actually agree with you. Over time, as I gained more experience as a
developer, one of the best things I've learned was to take charge and fix
things where I know they were not right, even if not officially requested. Or
to identify that a request for one specific fix actually meant something else
was broken and that's what should be addressed instead.

------
scandox
Taking myself as a 0.5x programmer, I have sadly encountered some 0.01x
programmers. In fact it might be better to characterize them as -0.01x
programmers, who I believe can work indefinitely without ever producing a
working piece of software. Usually the best indicator of this is when the
initial snaglist for a piece of work grows after the snags have been
"completed". Then each round of fixes becomes a kind of Hydra and finally we
have to give up cutting off heads and start over.

I resisted believing in this phenomenon for a long time, especially because
I'm no great shakes myself. But in the end it could no longer be rationally
denied.

~~~
sklivvz1971
I've also seen negative impact developers. If they did not code, we'd be
closer to the finish line than if they did not.

Works great if you pair them with a more senior developer who has the chutzpah
to make an impact by deleting egregiously bad code. E.g. one of the best I
know made a failing project succeed by literally deleting all unit tests
(which in that case were not providing value at all).

~~~
pawadu
> I've also seen negative impact developers. If they did not code, we'd be
> closer to the finish line than if they did not.

Code? I know people that have caused big projects to fail by just showing up
at the meetings. The amount of damage a -10x idiot can do to a project is just
mind boggling.

Here is my unsolicited advice to young players: if you end up in a project
with a -1x (or worse) guy who is also the darling of the PM or CEO: no matter
how hard you work you cannot save this project, don't wait for the shit to hit
the fan, give them your two week notice today!

~~~
dsacco
Care to share a war story about someone ruining a project by showing up to a
meeting? That's amazing.

~~~
pawadu
Here is one you might enjoy:

We had a guy coming into every meeting demanding we produced some low-level
internal document for him. We tried to explain to him that (A) our project was
not related to his project and (B) we were not comfortable giving anyone an
internal implementation document of something that was highly agile.

So this went on for a year and by then the managers were really pissed off
that we didn't have the "proper documentation" in place. We spent the next
year creating a stable internal API and writing the documents he wanted.

What I learned from all this was that the only way to fix a -10x guy is to
fire him. Because despite all this we spent the third year defending internal
design decisions from a guy who wasn't even part of the team. In the end he
was fired for failing to deliver in his own project - by which time our
productivity doubled.

------
latch
I don't understand how anyone can say 10x programmers don't exist. There are
programmers who DRAIN value from projects and companies. The most insidious
I've dealt with are people who assure everyone their part is going to be done
on time, but come the deadline, they have nothing.

I am today, a 10x better programmer than I was where I started. In terms of
quality, complexity, efficiency, readability, maintainability, everything. I
was paid too much when I started and/or not enough now!

Notch and Carmack are 1000x better game programmers than I am. Linus is a
1000x better file system and operating system programmer than me. Monty is a
1000x better database programmer than I am. DHH can build a website at least
10x faster than me and do it in a way that would contribute 100x more to the
community than I could.

If you discard people with decades of experience. If you discard people who
have specialized. If you discard the many geniuses in our field. And then if
you start to make excuses at the other end, and if you narrow it to a specific
set of tasks, with a specific set of complexity, then _maybe_ there isn't a
huge gap. But even then, I feel that if you apply yourself to that task for a
decade or two, you'll find that you're a 10x better programmer than you used
to be.

~~~
kasey_junk
I don't doubt that 10x programmers exist. What I doubt is that _anyone_ is a
10x programmer all the time. Whether or not someone is contributing 10x output
to a project is such a complex number of things both attributable to the
person, their environment, life factors, their coworkers etc.

I've seen programmers that were dead weight, moved to a different team and
begin to flourish. I've seen programmers that on paper were the least valuable
part of the team, do all the small things so well they were actually
invaluable. I've been the developer that was considered a 10x dev but due to
life stuff getting in the way I was probably a negative.

So sure, there are developers who are better than others, maybe even in non-
linear ways, but so what? I think we can put lots of 1x developers into
situations were they get 40% productivity improvements and that will go a lot
further than chasing the long tails of 1000x devs.

~~~
sheepmullet
> So sure, there are developers who are better than others, maybe even in non-
> linear ways, but so what?

The fastest way to kill high levels of productivity is to not value high
levels of productivity.

Edit: And I believe there is a strong correlation between people who value
high levels of productivity and people who can build highly productive work
environments.

~~~
kasey_junk
> The fastest way to kill high levels of productivity is to not value high
> levels of productivity.

I have not found that to be true. In my experience the fastest way to kill
productivity is to measure it incorrectly & incentivize bad behavior chasing
the wrong thing.

Everyone values productivity but virtually no one has a good way to measure
it, at least not in software.

~~~
logfromblammo
I want to point out that you and sheepmullet are not exactly in disagreement.

You _can 't_ value high productivity if you don't recognize it when you see
it, so any workplace that satisfies your first criterion will also satisfy
sheepmullet's.

I once worked at a place that used spreadsheet workbooks to track developer
activity down to the second and used SLoC as a management metric. It was the
least productive workplace I have ever seen. Paid for by ~= $7M per year of
the US federal budget, and returning a CRUD app that was probably still
outperformed by folders in a file cabinet. A year of work by 12 "developers"
_might_ replace _one_ paper form.

High productivity was interpreted as a threat to the gravy train. In
retrospect, I should not have suggested that everyone on the team read _Code
Complete_, because it just painted a target on my back.

------
kator
I have a friend who is an amazing musician, fairly successful and quite
inspiring. He's no Wolfgang Amadeus Mozart and he knows it. Everyone can
accept that fact.

Too many people approach "programming" like it is a simple execution of ideas.
It's more art than execution and I've been inspired by the creation of many
amazing programmers in my long career. And in 35 years of developing
technology to solve real-world problems I've managed to have a couple nice
ideas that inspired others.

To me coding is a creative process, often I will code for many hours straight
without a break, I will "wake up" afterwards like I was in some sort of
trance. My wife laughing at me as I realize it's dark outside, not because
it's still morning, but because the day disappeared and its night time again.
For me coding is a form of meditation, it's pure thought and comes from
somewhere outside of my body out my fingertips like lighting into the
keyboard. It's a gentle dance with a computer to dialog with it about a
problem I'm trying to solve and ways it can help me or many of its friends can
help me.

If you don't feel this way about coding, maybe something else is in your
future, but for me coding saved my life and without it my soul would be
trapped in a metal box without any way to express itself.

Am I a 10x coder, I don't know, I don't care. What I know is I am inspired by
amazing coders and sometimes when I'm really lucky I inspire someone.

EDIT: PS: Antirez has inspired me every time I've looked at his creations. I
wish some day others could feel that way about my work.

------
skywhopper
Speaking from my own experience, the truly amazing ultra-productive
programmers often come with the caveat that they don't spend much if any time
mentoring, explaining, or sharing how they work and why. They can produce a
patch in two minutes, or interactively fix up some corrupted data in a few
seconds. But spending the time to demonstrate to everyone else how they did it
so that the other members of the team could learn their own product better
would take a lot more of their time. They're always the ones to fix the
unexpected problems, because they can figure it out and fix it before anyone
else can even get a handle on what's wrong. That's great in the moment of
crisis, but in the long run it can be devestatingly counterproductive.

So whether intentionally, tempermentally, just due to the constant demand for
their services, or just because it's tautological, the 10x programmers don't
actually contribute back to their team's knowledge, which means the rest of
the team stays at 1x, and whent he 10x programmer moves on to another project
or company, the rest of the team flounders around while they have to figure
out all the things the 10x programmer never bothered to share.

~~~
TimJYoung
I would agree with you on this if you were to state that someone looked at the
code created by one of these ultra-productive developers, asked questions, and
was told "f __* off ".

But, did any of the other developers even look at what the other ultra-
productive developer did ? Did it get studied in detail, and were questions
asked of the ultra-productive developer ?

I've been the ultra-productive developer in such a situation before. After a
couple of runs of "hey, here's some cool things that I did that I thought you
might be interested in" followed by a lot of glazed-over looks and shifting in
seats, I got the message and stopped doing them. There simply was not any
interest, and I learned a valuable lesson: most developers don't have any
where near the same level of interest in the craft as those that have done it
for 25-30 years and are passionate about it. It's just the way it is, and no
amount of persuasion or pleading is going to change it.

Either that, or I'm mind-numbingly boring and that was the reason... ;-)

------
omnimike
While I completely agree that some programmers can be 10x more productive than
other ones, I think it's far more common to see programmers who LOOK 10x more
productive than others. It's very hard to compare people who have different
problems to solve. Solving 90% of the problem is not the same as solving 100%
of the problem, and sometimes that 10% really is worth the effort.

I've seen cases where one ostensibly 10x developer comes in and solves 90%
(the easy parts) of a problem. Management love him. Then he moves on to other
projects and leaves a team of "1x developers" to deal with the 10% (which
management still insist on having). This team now have to re-write everything
this superstar did from the ground up without taking shortcuts this time. The
time it takes makes them all look like 0.1x developers.

~~~
dlwj
"I came, things got better, I left, things got worse. What do you think that
says about me?"

Whether it's an engineer, or a manager, or C-level executive, this is very
easy to achieve by borrowing from the future. Very difficult to solve I think.

~~~
solipsism
You forgot _politician_

------
tinco
I think the phenomenon of the 10x programmer does have analogues in physical
work. I feel a big part of this is having the ambition to absorb the entire
problem domain. A 10x programmer does not work on just one part of a problem,
they work on the entire product, each subproblem having a solution that simply
flows from the constraints of the entire system. It's this full comprehension
that allows the programmer to work without costly analyzing pauses, which I
bet is the root cause of the delays associated with the 'regular' programmer.

I think I experience this in my hobby projects, when I fully own the project
even when it is fairly complex, every time I spend an hour or two on an
evening I pump out a few features that on a big team project would feel like
they could've cost weeks.

The physical analogue I offer which might be a little far fetched is the
construction worker. I have been renovating a house, doing demolition, basic
construction, electrical, plumbing, and hopefully in the future finishing of
the house. I'm a total novice, so obviously it's going slow, but eventually I
will have constructed (most of) an entire house. Because I do everything,
there is little to no overhead (besides me having to learn everything) when
switching between tasks, I own all of the project. I bet that someone who
solo-renovates houses as a full time job is ridiculously productive, much more
so than a general contractor managing a team of subcontractors.

Anyway, obviously this is all just hypothesizing based on anecdotes.

------
jasode
_> The programming community is extremely polarized about the existence or not
of such a beast_

If we go meta and _generalize_ the disagreement, the skepticism about "10X" is
the same as the rejection of other labels such as "ninja" and "rockstar".[1]
For some, the idea of categorizing a subset of programmers with a grandiose
label is psychologically distasteful. It doesn't matter what the label is;
_any label_ that attempts to stratify programmers is a "myth".

As for "10x" specifically, I'll repeat what I've written before...

To make peace with the "10x" label, I suggest people just think of it as a
_rhetorical figure-of-speech_ instead of a rigorous mathematical term. We
don't get hung up when people say _" Star Wars IV was 10 times better than
Phantom Menace"_ or _" I'm not even 1/2 the football player I used to be."_

Even if people were to use a new term such as _" 3-Sigma Programmer"_[2]
instead of _" 10X Programmer"_, the ensuing debates would still be the same.

E.g. _" Some people say 3-σ programmers write string parsing loops that are
better in speed and quality than 99.7% of the other loops but that 3-standard-
deviations-above-the-mean is a myth... etc"_

The argument pattern would be the same: take a label, _any label_ , hyperfocus
on some literal meaning to the exclusion of all other colloquial usage, and
debate why that mathematical interpretation fails in the real world.

tldr: "10x" in discussions is more of an informal _ranking_ of programmer
ability and not a rigorous mathematical measurement of output.

[1][https://www.hanselman.com/blog/TheMythOfTheRockstarProgramme...](https://www.hanselman.com/blog/TheMythOfTheRockstarProgrammer.aspx)

[2][https://en.wikipedia.org/wiki/Standard_deviation](https://en.wikipedia.org/wiki/Standard_deviation)

~~~
speleding
Not many people would take issue with the statement that Shakespeare was 10x
better / more effective than the average playwright. If you consider that both
are creative processes there seems no reason to reject the idea that a
programmer could be 10x more effective than his peers.

The comparison between writing a play or a program starts to break down if the
problem space is narrow, as the article also mentions, so a lot of what people
end up arguing about is what programming actually is.

~~~
QuantumGravy
If publishers decided they were only going to publish Shakespeares, I imagine
a multitude of authors would squander a great deal of ink over it, and we'd
all be worse off for the cumulative waste of talent.

------
DoubleGlazing
I've worked with people who could be classed as almost a 10x programmer.

Their code worked, but it was also incomprehensible to everyone else on the
team.

I have found that high-speed programmers tend to develop a very personalised
workflow style. They do things their way, they code their way and forget that
other people may have to maintain that code.

~~~
simonw
The argument in the above post would not classify those as 10x programmers.
antirez is claiming that high quality design and a commitment to simplicity is
a big part of what makes some programmers do much more productive.

~~~
DoubleGlazing
Oh I agree with the article. Whenever I lead a project I argue that the team
should aspire to follow "lowest common denominator" principles. By that I mean
they should work in a way that appreciates the abilities of the least skilled
on the team or in a manner that would allow someone coming in off the street
to get up and running with the project without needing any help from existing
developers. That doesn't mean over simplistic code, it just means good simple
design, lots of comments and docs and asking around for permission before
implementing an obscure or exotic design pattern.

What slows down my productivity more than anything is looking at someones code
and thinking "Why did they do that?" Simplicity pay off in the long term.

However in reality, and what my comment was referring to, is that every
sizable team has that one dev who rattles off code quicker than anyone else.
Yes it works, but it will have a lack of comments, or they don't check in
often enough resulting in merge issue or worst of all they implement a design
pattern no one else has heard of.

------
sklivvz1971
I absolutely loved this article. Don't get hung up on the "10x", read it as
"good". All the characteristics Salvatore describes are the characteristics of
every good developer I know, and that every developer should strive for. They
make you a better artisan, but also increase your productivity. Who cares if
it's 10x, 100x or 2.5x? The important bit is growing to your personal full
potential.

One thing that it's missing from the post is a bit of focus on how good
developers (and indeed good leaders) concentrate on _maximizing their impact_.
Not only you want to be fast and reasonably accurate, but also make what you
do matter. Sometimes shaving down compilation time by a couple of minutes will
save each developer in the team two minutes multiple times a day for years,
for example. Not all productivity wins are obvious.

------
pjc50
10x what, though? No 10x engineer would accept a unitless quantity from
uncalibrated measurements of terrible accuracy.

Yes, it's obvious that some people are getting a lot more done, but it's very
hard to quantify and vulnerable to social engineering. It can be hard to spot
quieter people working effectively, and it's _really_ hard to quantify those
who spend their time helping others or improving team effectiveness or
business communication.

~~~
realharo
It's even harder when you factor in people who seem to get a lot done quickly,
but at the cost of huge technical debt that will slow the project down to a
crawl in the long run.

Or the other extreme, people who overengineer everything in anticipation of a
future that will never come.

~~~
zzzcpan
> but at the cost of huge technical debt

Which is also unquantifiable and is a very similar myth.

------
thehardsphere
I thought the research that produced the legend of the 10x programmer showed
that he was 10x better than the worst programmers who were still good enough
to be employed, and only ~2.5x better than the "average" programmer.

~~~
dsr_
Correct.

In Peopleware, DeMarco and Lister write:

    
    
        Count on the best people outperforming the worst by about 10:1.
    
        Count on the best performer being about 2.5 times better than the median performer.
    
        Count on the half that are better-than-median performers outdoing the other half by more than 2:1.
    

What nearly everyone who has read that remembers is the following:

    
    
        The best people outperform the average by 10x.

~~~
logfromblammo
Here it is in visual form. Median defined as 1.

    
    
      |                    |                 | Probably          
      |    Unemployable    |    ___          | Over-     
      |                    |  ,' : '.        | qualified 
      |                    | /   :   \       |           
      |                    |/    :    \      |           
      |                   .'     :     '.    |           
      |                 -" |     :       "-_ |           
      |          __--""    |     :          ""--__       
      |____---"""       0| |     :           |    ""--___
      +------------------+-+-----+-----------+-----------
                           |     |           |           
                          0.25   1          2.5 (10x)    
    

People with skill below 0.25 cannot meet the minimum requirements for the job,
or cannot be productive enough to cover their labor costs. People with skill
above 2.5 have likely been promoted beyond the parameters of that job.

Whenever someone exceeds base expectations to such an extent that they hit the
ceiling for the position they are in, they either get recognized and promoted,
they job-hop to the next rung up the ladder, or they throttle back their own
performance to be proportional to their compensation.

There are a few jobs that are at the top of their respective career ladders,
where there is no choice but to offer profit-sharing as a means of encouraging
best performance. So you can get a 20x CEO, or a 50x celebrity performer,
because they get paid a percentage, and there is nothing else to be promoted
to, except young passive-investor retiree.

------
codr4life
"When the task at hand is much more rigid, with specific guidelines about what
tools to use and how to implement things, the ability of a 10x programmer to
perform a lot of work in less time is weakened: it can still exploit “local”
design possibilities to do a much better work, but cannot change in more
profound ways the path used to reach the goal, that may include, possibly,
even eliminating part of the specification completely from the project, so
that the goal to be reached looks almost the same but the efforts to reach it
are reduced by a big factor."

This is one of the reason working in software sucks so badly these days.
You'll inevitably be forced to work with lesser tools in more ceremonial ways,
which takes away most of the leverage from experience and skill; effectively
dragging everyone down to the lowest common denominator where everything is
done according to some stupid, over engineered specification.

And one of the beefs people seem to have when I share my code publicly.
Cutting corners and side-stepping complexity is where coding turns to art for
me, where the fun begins; which means that many of my programs look like toys
in comparison to "serious" software. Yet they still manage to get the job done
for less effort, and a closer look reveals that the simplicity is carefully
engineered. I just don't have much time or patience for ceremonies these days.

~~~
xyzzy4
Reminds me of when I used to work at Cisco. All the software there for routers
_must_ be written in C. As a result everything takes much longer than it
should.

~~~
codr4life
It always seemed weird to me to hire expensive specialists only to slap them
around and override their experience by insisting on sub-optimal tools,
methods and work environments. It took me 30 years of diligent, daily practice
to get here. That experience better be put to good use or I'm out, I have no
patience for business bullshit.

------
chadcmulligan
I'd argue that it's greater than that these days, many programmers really just
can't do what a lot of good programmers can do. Even if they're given all the
time in the world they'll just never get a result. So whats that make them
infinityX programmers?

~~~
pg314
Exactly. At my last job, a colleague of mine was tasked with creating a tool
to generate a monthly summary report based on 100s of millions of records. It
took him weeks of trying to get something working in Python (naively read in
all the data into Python objects and then trying to iterate over them), coming
up with convoluted algorithms trying to speed things up. His final solution
took multiple days to run (too slow for the requirements). An equivalent
solution using PostgreSQL (using the built-in COPY to parse the CSV records)
and couple hundred lines of SQL (a day's work) could do the job in less than
10 minutes.

At the beginning of my career I've done comparable things. I once spent
multiple weeks implementing a solution to a problem that would have been
trivial if I had known about unification [1]. Thousands of lines of
complicated C++ code, countless bugs,... If you don't even recognise the
problem, how can you expect to find a reasonable solution in a time that is
only 10x as long as it would take someone who recognises the problem and knows
how to solve it?

[1]
[https://en.wikipedia.org/wiki/Unification_(computer_science)](https://en.wikipedia.org/wiki/Unification_\(computer_science\))

~~~
dsacco
I don't understand this. I'm not saying I don't believe you, but it seems
ridiculous to me. I actually feel vicariously annoyed just reading that story.

In my experience, most competent programmers encounter problems they can't
solve off the cuff frequently. Then they think about it, research a bit,
formulate the problem, etc. They come back to solving it after stepping back
because they realize they're in the weeds and just treading water.

At a certain point, your colleague must have realized this task was simply
beyond his "off the cuff" abilities and gone looking for a more efficient way.
Surely he had the presence of mind to realize he was beginning to be
unproductive? How did he spend _weeks_ on a problem that can be summarized as
"retrieve a lot of records from a database"?

Furthermore, what was your organization like that someone that grossly
incompetent wasn't checked in on about progress? There was no "mercy rule"? No
referee to call it when it was clear it was taking weeks instead of hours or
days?

I guess I'm just confused because I don't consider myself a particularly
spectacular programmer, but I'm self-aware enough to search for a solution and
RTFM for the tools at hand. I just don't understand how weeks were spent here.
I've never encountered a team where it seemed like one person was that far off
from the median (to be fair the companies I work with likely wouldn't use them
as a point of contact though).

~~~
pg314
> I don't understand this. I'm not saying I don't believe you, but it seems
> ridiculous to me. I actually feel vicariously annoyed just reading that
> story.

It was ridiculous, and I was annoyed at the time too. Especially because I had
basically laid out how to solve it just before I left that company. Somehow
that didn't get communicated to him. When I went back for one day 5 months
later, I learned that he was basically still nowhere (he had been doing other
things too). I spent an hour with him laying out the solution in detail. From
what I last heard, he listened, and that is the solution they are currently
using.

> At a certain point, your colleague must have realized this task was simply
> beyond his "off the cuff" abilities and gone looking for a more efficient
> way. Surely he had the presence of mind to realize he was beginning to be
> unproductive? How did he spend weeks on a problem that can be summarized as
> "retrieve a lot of records from a database"?

If you only have Python experience and no intuition about how much time/memory
certain problems should take, you don't necessarily know when you're out of
your depth. It was a Django shop. The only exposure most of the people in that
company had to the RDBM was through the Django ORM. Multiple times I have seen
them do things through the ORM which would be trivial and multiple orders of
magnitude faster with a couple of lines of SQL.

That data also didn't come in a database, but in a series of CSV like files.
If you don't have RDBM experience, you don't necessarily see how you would use
a database for this problem. And Python conveniently has a csv module that
will happily parse your files into objects... If you buy into the marketing
that Python is 'fast enough', and 'you can always use Pypy if it needs to be
faster', you might not realise when you get stuck.

> Furthermore, what was your organization like that someone that grossly
> incompetent wasn't checked in on about progress? There was no "mercy rule"?
> No referee to call it when it was clear it was taking weeks instead of hours
> or days?

Management didn't know how long that task was supposed to take. The technical
competence in that company was very limited, and they were used to deadlines
slipping all the time.

> I'm self-aware enough to search for a solution and RTFM for the tools at
> hand.

That puts you ahead of the pack, in my experience. I had almost no experience
with RDBMs before I joined that company, but reading the first 100 pages of
the PostgreSQL manual the first week put me ahead of people who had been using
PostgreSQL as their principal tool for more than a year (a different team, the
metrics team which used PostgreSQL directly, not through the Django ORM). They
had never heard of simple things like VIEWs and WITH queries.

> I've never encountered a team where it seemed like one person was that far
> off from the median

I don't think he was that far off from the median in that company, maybe just
a bit below. To be fair, it was technically the worst company I've ever worked
at. I was only with them for 6 months (and I never would have started there
except for personal circumstances).

Consider yourself lucky never having worked at such a company. They are more
common than you think.

------
kelvin0
It seems to me a few people fit their jobs/environment others don't. The few
who fit are productive, those who aren't where they are supposed to be are
not. We should be discussing how to help people learn what environment/job
works for them and empowering them, instead of trying to focus on the mythical
10x programmer. Don't get me wrong some programmers are very talented (and
thus more productive), but I think this is due in great part to their ability
to add value in a particular setting.

A 10x games programmer in a small studio could easily become a 0.1x web dev in
a big web dev team.

------
dzink
There are so many factors at play in team and client environments, so the best
benchmark to use is your own productivity as a programmer.

1\. Solving problems for the Nth time instead of the first leads to
substantial gains in productivity, easily 10X gains on your first attempt.

2\. Architectural decisions add another multiplier on the above: picking the
wrong database type, structuring and reorganising your models, spending time
to design ahead vs coding right away, all can /10 or 10X your project easily
from fixes and re-dos alone - combine both 1 and 2, and you have potential
100X gains.

3\. Risk-distributing the project work: eliminating the worst 5% as the author
says, and/or writing the most complex parts first to reduce risk of massive
rewrites in case something doesn't meet expectations in its most critical
functionality.

4\. Having competent business requirements providers who won't move the ground
beneath your feet. You can be 10X or 100X more productive when writing new
code, and that much slower when rewriting someone else's bad decisions. It's
no different than trying to build a skyscraper on foundations built for a
garage.

Stack the above as A x B x C x D and you can see why you might be able to beat
your past self 10X or 100X and more between projects. Having teammates who can
beat you is even better if you can learn from them and accelerate your own
progress by skipping time consuming mistakes.

------
partycoder
Some productivity killers:

\- Distractions

\- Feature creep

\- Poor code organization: coupling, action at a distance, cyclomatic
complexity

\- Noise: comments that do not get to the point. A tool to mitigate this is
[https://foxtype.com](https://foxtype.com)

\- Hacks and lack of consistency

\- Lack of automation: tests, builds, deployments

Regarding hacks, imagine what would physics equations would look like if a
fundamental constant was wrong. All equations would need to compensate for it
by including some arbitrary constant making everything more complicated. That
is what messy code bases look like, layers of lies to compensate for lies.
Clean code is more straightforward, easier to work with.

Regarding iterations... does the army run an exercise with soldiers and trucks
and live ammo each time a general wants to test an idea? No. They use
simulations, and only the ones that look promising are turned into exercises.
So rather than asking engineers to prototype some throwaway idea, get your
hands dirty and use Powerpoint and your imagination, stress the idea, then
build it. And if it's built, keep it in a feature branch until you've actually
decided to keep it for good.

When a car is built, engineers tell designers to modify their concepts in
order to make the production more cost efficient. Same in software... be
prepared to negotiate requirements if that is in the best interest of the
project.

------
erikbye
All programmers have different output. How is it even a debate? Some people
are more productive than others. Just like one novelist takes 10 years to
finish his novel another writes 2 every year.

~~~
Insanity
Also not unimportant, the quality of said novels. 2 shitty novels a year
versus one praised novel every 10 years.

~~~
bryanlarsen
Actually, I think it's the inverse. Most 2/year novelists are professionals,
and it shows. Stephen King consistently wrote at about that rate. 6 months
_full-time_ is a good amount of time for a professional writer: 1-2 months for
writing, and then another year or so of polishing and editing that happens in
parallel with other efforts.

10 year novelists are often amateurs. That novel your next door neighbour
asked you to read? He's probably been working on it for years.

Even notoriously slow George R. R. Martin takes less than 10 years to write a
novel.

~~~
Nimitz14
Two novels off the top of my head with far greater significance that anything
GRRM or SK have or ever will write that took ~10 years to write: Dispatches
(1968-1977) and Infinite Jest (1986-1996).

Feel free to think that a novel is something one cranks out as if it's just an
object that carries no meaning, requiring no sacrifice from the author. But
that's an opinion, and not fact.

------
SimonPStevens
The whole 10x programmer thing is just interpreted wrong. The original
statement was that the best are 10 times better than the worst.

I've certainly worked alongside programmers who's output is so bad that I
would consider myself both 10 times better and 10 times faster. And I wouldn't
even consider myself a top teir programmer. They are often people who's
contributions to the project are net negative in that they actually require
additional work from someone else to go clean up their mess afterwards.

Stop imaging a mythical coder who is 10 times better than everyone else, and
instead think of the worst coder you've ever worked with who is 10x worse than
everyone else. There is your 10x'er. We are nearly all 10x'ers when compared
to the bottom few percent.

------
jonpress
The programmer is only as good as his manager. If a 10x programmer is working
under the leadership of a 1x programmer, he will probaby turn into a 0.5x (due
to lost motivation). A 10x programmer in a decision-making position will
actually bring up the output of all other programmers. In reality, a 10x
programmer doesn't have to be fast at programming themselves, they just have
to be able to foster good habits which make everyone else faster. That's why
it's dangerous to promote 'fast programmers' to leadership positions. Fast
doesn't mean good - In fact, most of the time, 'fast' is bad/suboptimal
(especially when it comes to design decisions).

~~~
Helmet
I disagree - some of my best managers weren't exactly the best programmers.
They did, however, have a mind for smart architectural decisions and knew when
to "back off".

------
edblarney
Maybe one things missing: 'specific domain knowledge'.

At least 1/2 of programming is learning. You can make a basic Android App, but
have you learned how to do 'deep linking'. Well, it can take a full day the
first time because it's awkward, and you have to understand a few things, and
set a few things up server side.

Second time - it'll take 1 hour.

There's a lot of that.

If you're really comfortable with XMLHttpRequest, and know the ins and outs of
post/form structures - well then you can do something quickly in it. If you
don't well, it could take a bit to learn for a new dev.

Those things add up a lot. It takes several years to get comfortable with the
variety of tools and tech necessary to be good.

------
gator-io
From what I've seen from working on two projects with more than 100 engineers
is that they break down into these categories:

20% - Not productive. They can't get their tasks done, and after awhile, no
one even expects them to. They get routed around. 65% - Neutral. The quality
problems and technical debt they incur matches their productive work. 12% -
Net negative. They introduce hard to fix bugs and technical debt beyond their
productivity. 3% - Gods. They do almost all the productive work. Without these
types of people, no large project would ever get done.

------
beat
You forgot one... sacrificing the efficiency of others to gain multipliers. By
undermining team communication, future maintainability, etc, the 10x can
appear much faster. This speed is gained not by truly being more efficient,
but rather by the coding equivalent of maxing out your credit cards and
mooching off your friends.

It looks good at the present, but the team pays for it in the long run - long
after Mr 10x (it's always a guy, right?) gets fed up with the process bloat
and criticism and whining and leaves for greener pastures.

I've cleaned up after 10x programmers.

~~~
oxryly1
As have I.

Interestingly, sometimes that cleanup was an intentional part of the process
and looked more like maintenance and extension of rapid prototypes. It still
felt like I was compensating for all those bad habits of Mr 10x.

------
GedByrne
I think the significantly better performer is something we see in all areas
like sport, music and craft.

I think Anders Ericsson does a good job of explaining the phenomenon in his
book Peak: [http://uk.businessinsider.com/anders-ericsson-how-to-
become-...](http://uk.businessinsider.com/anders-ericsson-how-to-become-an-
expert-at-anything-2016-6)

What we should be doing is looking to create companies that can allow workers
to reach and sustain peak performance in all areas, not just coding.

------
tluyben2
Antirez is a 10+x programmer in most peoples' definitions. Writing nice to
read code fast. So it is good to read this from him but then again he always
appears quite humble.

------
dlwj
Somewhat related, there's a very good post here:
[http://lesswrong.com/lw/l8/conjuring_an_evolution_to_serve_y...](http://lesswrong.com/lw/l8/conjuring_an_evolution_to_serve_you/)

It's about the unintended side effects of trying to be a 'Natural Selector'.
One example is selecting individual hens on egg output to create a breed of
high-egg producers. The result was mean chickens which had gains b/c they were
very aggressive. The breed needed to have their beaks clipped otherwise they
would kill each other. When productive groups rather than productive
individuals were selected though, they got the desired effect. (Though in
another example I can imagine selecting for mean group behavior)

Another example was trying to selectively evolve animals that would self-limit
reproduction. (to avoid overpopulation and resource over-consumption) The end
result was selecting for cannibalism.

In organizations, the equivalent of propagating a feature are the hiring stage
and the promotion stage. Whatever you hire for, or promote for, will be the
trait that's optimized. Whatever the side effects may be... (e.g. Enron)

------
hacknat
The main difference I have noticed between programmers isn't how fast they get
their projects done, it's the amount of technical debt they leave behind.

------
paulus_magnus2
From experience, it comes down to luck, but in a sense luck = good preparation
/ pre-built components toolbox.

I can be 10x, even 100x when working on something I've already solved & have
"big" set of components ready to plug in (with a little bit of tweaking). The
more stuff you have, the "luckier" you are. It's also ability to spot patterns
& good memory & being in a flow.

------
apeace
Off-topic, but I know that Antirez has mentioned in the past he is always
working on his English grammar.

> Surprisingly the ability to use basic imperative programming constructs very
> efficiently in order to implement something is, in my experience, not as
> widespread as one may think.

Those words are spun better than I could do, and I'm a native English speaker.
Bravo!

Maybe something missing from the list is hard work and long-term dedication ;)

------
lojack
I think this myth stems from a lack of understanding of what we consider to be
"work". For example, one developer could crank out 10x as many features as
their peers, but never consider deploying or maintaining. The reality is that
they are making everyone else slightly less productive. Similarly, they could
work on 1/10th of the features, but help their 10 peers become twice as
effective. Taking this even further, there's developers who can complete
1/100th of the features as their peers, but help thousands of other developers
become 5% more effective.

In my mind, the mythical 10x programmer is the person that can complete
business objectives while helping make those around them more effective. This
isn't actually a myth, and "10x" is a completely arbitrary number that doesn't
mean anything. It might as well be 2x or 1.1x -- they all mean the same thing
to me. They can do their work at 1x speed, a baseline set by the developer in
question and not their peers, but they can simultaneously help others around
them be more productive.

------
spenrose
Two classics on design to flesh out Antirez' thoughts:

Parnas’ ”On the Criteria To Be Used in Decomposing Systems into Modules”
[https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/crit...](https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf)
[PDF]

Christopher Alexander’s Notes on the Synthesis of Form
[http://www.hup.harvard.edu/catalog.php?isbn=9780674627512](http://www.hup.harvard.edu/catalog.php?isbn=9780674627512)

Both get deep into how a design emerges from the _relationships among_ what
Antirez is calling "sub-tasks". Antirez refers briefly to these relationships
in the "Design sacrifice section." Parnas and Alexander put them, correctly I
believe, at the heart of the craft.

Parnas was a software engineering authority. Alexander went on to write A
Pattern Language, from which the software community derived "design patterns"
as a foundational idea.

------
merb
I like the article in general, however sometimes i think that an ideal
solution in terms of design sometimes can't exist, I mean a program mostly
grows after usage and gets many changes over time. sometimes something which
was quite good, is now rusty and bad.

I mean at the moment I'm actually changing my code that was simple at first,
but over time more and more things were added and it started to complex. The
thing I'm doing right now is getting rid of the complexity to add another
future. Well mostly I think a big problem is that many people actually think
about the design too much, since the design of a program will eventuelly be
changed anyway. What worked for me was design something that works in most
cases and grow that path or throw it away if it sucks.

btw. I love what antirez did and does for the community of programmers.

I always use a redis client to teach people more about network programming in
java. It's a extremly simple, but still powerful command set/protocol. I hope
he can keep up his work.

~~~
doubleplusgood
One of things that come with experience is the ability to foresee the
potential changes and ensure that, when possible (preferably during the
initial spec phase) the solution is extensible/flexible enough to accommodate
the most likely changes.

For a simple example, if you're asked to implement something like a blog, you
would naturally be prepared to be asked for authentication, authorization,
contact us forms, commenting, etc. If you're aware that there's a high
probability of such a change request in the early phases (but not NOW), then
that anticipation will usually result in better code.

~~~
merb
That's exactly what I think does not work. You can't see the future. Of course
a simple project want to have that, but a big project is unpredictable. You
should make it flexible by having a great test infrastructure to move forward
fast, but you should try to create something that doesn't exist yet. Maybe it
is needed, maybe not, it's just too unpredictable to write code for something
that doesn't exist in the customers head.

~~~
doubleplusgood
I didn't mean "implement features before they're requested". What I meant was
that designing flexibly will allow you to iterate better, and given some
experience, you will probably be able to "predict" the next feature req or 2.

------
jacquesm
Productivity is all about the choices that you make.

It's the essentially the same as optimizing a computer program: you can't make
it do more work faster, you can only make it do less work.

And if 'less work' means the problem is solved anyway then you are a 'faster'
programmer, even if you produce fewer lines of code than your 'slower'
counterpart.

------
random3
When the overall quality / delivery metric of an individual / team tends to 0,
then the ratio between a good (normal) programmer over that will tend to
infinity.

Probably the biggest aspect not dealt with in these writings along with the
discussion around it (is there or is there not such a beast) is bias.

For example, selection bias: e.g. my view over what was the best / worst
programmer was much different when working in different teams. I found out
there could be much worse than what I thought is the worse. Then I learned
that there could be much worse... It's like a fractal :) As you notice these
differences a 10x difference doesn't seem that crazy. It's really things that
should take a few weeks, which in turn take months or years or never get done.

Also like any other optimization problem, optimizing software development is
about hitting a moving target. When the team is balanced, it may be the
process that will become a bottleneck, etc.

------
didymospl
Even though I agree with all the points made by the author, the notion of 10x
programmer reminds me of one-man army movies like Rambo and it's equally
ridiculous. Software development is a collaborative effort, not a contest
where whoever commits more LOC or finishes more tasks wins. It's not that hard
to be 10 times more productive than anyone else if you built something from
the scratch, possibly reinventing the wheel instead of using common
libraries/frameworks, wrote no documentation and you're not really willing to
share your knowledge with other developers. Sadly, this happens - see e.g.
[http://thedailywtf.com/articles/the-inner-json-
effect](http://thedailywtf.com/articles/the-inner-json-effect) [edit: added
link]

~~~
TimJYoung
I don't think the 10x moniker is an _internal_ label given by the developer
themselves, rather a label applied to them based upon actual productivity.
Your example developer would be commonly judged as the opposite of a
productive developer.

------
Sir_Cmpwn
I think the real key is simply experience. From what I've seen a 10x
programmer is simply one who has worked on 10x as many projects as the
baseline. The things the article points out are common traits of such people.
A 10x programmer has worked on several teams and has lots of side projects.

------
stiff
Kent Beck has an article that is a nice complement to this one:

[https://www.facebook.com/notes/kent-beck/mastering-
programmi...](https://www.facebook.com/notes/kent-beck/mastering-
programming/1184427814923414/)

------
lordnacho
Perhaps it's worth stressing organisational factors in productivity.

Often when you find someone who's really good at what they do, they're the
type of person who loves their work, and they've managed to find employment in
an environment that suits them. The two are of course mutually helpful.

Also keep in mind it can be very hard to find more than one space for such a
person. It's like how certain soccer teams are built around a particular star
player; everyone else plays to suit that guy, and it would be hard to fit a
clone if you had one. Others may well be suited to a star role, but happen not
to have landed the role. Watch the Tour de France to see what happens when the
lieutenant steps up to the captaincy. I can often be dramatic.

------
ggoerlich
It's like in driving - most people think they are above average, see
[https://en.wikipedia.org/wiki/Illusory_superiority](https://en.wikipedia.org/wiki/Illusory_superiority)

------
guelo
The few times I've had the luck of working with 10x developer (or Nx for some
unknown value of N) what I noticed was raw intelligence, insatiable thirst for
learning and curiosity, and an intense focus bordering on obsessive.

------
pacoverdi
This was a great read.

BTW I have always known that the 10x programmer exists.

A sufficient proof is that on good days (with proper motivation,
concentration, no interruptions, enough coffee etc.) I'm 10x the programmer I
am on bad days :)

------
contingencies
When considering the implementation of a new system, sometimes considering the
relative value of the path is a better and more profound action than than
taking it. Similarly, implementation of a system does not necessarily imply
deep comprehension, correct or intuitive forward-looking design,
composability, repurposability, security, or any other property.

In short, as the saying goes: _Decisiveness is overrated_.[0]

[0]
[https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

------
dang
Since people have been objecting to the title and objecting to objecting to
the title, we replaced the title with a representative phrase from the
article. Let's focus on the body now.

------
codr4life
The part on perfectionism is also well worth repeating; pretending to be
perfect, and/or bullying others into the same madness is a waste of energy and
oxygen that could be better used to move forward.

"Perfectionism and fear of external judice insert a designing bias that will
result in poor choices in order to refine a design only according to
psychological or trivially measurable parameters, where things like
robustness, simplicity, ability to deliver in time, are often never accounted
for."

------
pweissbrod
Provided your business will never need more than one and only one expert
programmer who may not work in a team and this expert programmer will never
leave your business and will always be trustworthy to do the right thing and
they can support/maintain their own work in your production environment then a
10x programmer is a great idea.

Otherwise consider other human qualities such as communication skills,
adaptability and critical thinking as more valuable than raw coding skill.

~~~
nissimk
I think the point is that the 10x programmer has those other skills. That is
the differentiating factor. It's not about typing 10x faster or generating 10x
the lines of code. It's about creating 10x the value.

That requires identifying areas where you can deliver value. Frequent cost
benefit analysis of potential features vs their estimated cost. And as antirez
said in the article, designing these things so that less code gets you those
features.

The difference is kind of like book smart vs street smart. If you are just
book smart and you understand algorithms and data structures really well it
can only get you so far. You need to be able to interpret the user's requests
and design what will really help them. You need to understand what they are
asking for and what they really mean. And you need to generate solutions and
sell them.

------
Chris2048
There is no such thing as a "10x programmer", only "1/8 environments" i.e.
teams/environments where the normal programmer is 1/8th as productive as
industry norms, such that a mere 1.25x programmer is 10x productive.

..and an environment that fosters such low productivity norms, probably also
gets it's developer productivity _measure /metrics_ wrong as well, so you
don't even need a 1.25x for the perception of a 10x...

------
thecourier
"The number of hours spent writing code is irrelevant without looking at the
quality of the time. Lack of focus can be generated by internal and external
factors. Internal factors are procrastination, lack of interest in the project
at hand (you can’t be good doing things you do not love), lack of exercise /
well-being, poor or little sleeping."

Get your ass up from the chair and go outside to exercise if you wanna reach
Antirez levels of mastery

------
macca321
The 10x/-10x decisions are made by the architects, and the decisions tend to
involve where network/codebase/layer/service boundaries are drawn.

------
alexee
I'm not sure if it's only me, but I started to see a lot of 1/10x programmers
in startups. They can know all newest "cool" technologies, go to various
conferences, have a lot of followers on twitter and reputation on
stackoverflow, but when it comes to the real work, their value for the company
is around zero, usually can't even solve simplest tickets (probably busy
tweeting stuff?).

------
patsplat
On a yearly task with little code reuse my productivity went from 3 weeks to 3
days the second time.

In another migration measured the time to cut and paste and concluded a day of
grind was better than a week of scripting.

Many tasks have a thin path to completion surrounded by cliffs on either side.
Experience teaches when to focus on the critical path only vs when to take a
wider view.

There's easily a 10x productivity boost there.

------
pg_bot
I would add "reading the manual" to the list of things that people don't do
enough of. I'm often shocked by people just diving into coding instead of
doing the research to see if something has already been provided for you. You
will go very far if you understand what the technologies you use are capable
of doing.

------
hellofunk
10X? Steve Jobs said more than once in interviews that he saw a 200X
difference among professional programmers.

Which I think is bull, of course. You can't quantify things like that. Some
people are better than others, but any claim of 10X or 200X is missing a much
bigger picture of how humans contribute to each other's work.

------
mighty_warrior
Honestly the section about debugging skills needs to be much higher in the
article. Debugging skills are essential to learning legacy applications you
are thrown into and understanding how your code works in general. It amazes me
when I see an engineer with 5+ years experience who cannot hook up a remote
debugger to their application.

My number one observation about productivity usually revolves around how an
engineer attacks a problem and handles scope creep. There are some programmers
who can get a set of requirements, and like a trained surgeon get in, fix the
big bleed and get out. While they are in there they might fix a couple close
issues but they are not re-architecting the whole application. Then there are
others who see all the problems, they notice this problem there, and that
problem here and keep asking what does this all mean and it eventually
cripples them. They spend some much time seeing all the problems, that they
never get around to solving the one they were tasked to fix.

Once you realize you won't understand it all from the beginning and you can't
fix every issue you see. You become a much more effective engineer.

------
z3t4
Being able to see edge cases and bugs before they happen will kill your
productivity. I think the hardest part is to ignore those and deliver. If no
one uses the software, then no harm done, and if the software get popular you
will hopefully get funds to pay back the tech debt.

~~~
laythea
Depends what kind of software you write. Wouldn't want to get into an aircraft
that has software written to those standards.

~~~
z3t4
It would be great if programmers got more responsibility with increased skill
and experience. But that is often not the case. There are very few jobs for
highly skilled and experienced programmers and hackers.

~~~
laythea
Agreed, as I said - depends on what you write. It's a shame that so much of
the industry actually devalues the very thing that got us into this in the
first place (presumably not just money, but some love of engineering quality
software), degrading the job to be nothing more than "hacking" together
something, just to deliver.

It's not just delivering that is important (it is off course), but _what_ is
delivered, and if a company's non-techs don't realize and appreciate this,
it's a slippery road.

------
laythea
"Sometimes in order to gain focus, extreme measures are needed. For instance I
only read emails from time to time and do not reply to most of them."

This is far too extreme and turns you into a counterproductive team member.
Like everything in life, a balance demands to be struck.

------
neilzo
A good read but I doubt one of his assumptions:

    
    
      "you can’t be good doing things you do not love"
    

I believe you can be very competent at doing things you tolerate. It's time to
dispel the notion passion == quality of work.

------
perseusprime11
In my experience, there are 10x engineers but I often noticed they are 10x
only because they tend to work alone. As soon as you start pairing them with
another 10x engineer, they become 0x because they tend to fight about every
decision.

------
CSMastermind
This topic is addressed by Greg Wilson in his exceptional talk: What We
Actually Know About Software Development, and Why We Believe It’s True

[https://vimeo.com/9270320](https://vimeo.com/9270320)

------
nsfyn55
OP says 10X programmer is a myth. Then describes the exact characteristics
that make some programmers 10 times more productive than others. Maybe not so
much a myth.

------
iamgopal
10x programmer is like Linus, who programs and set structure of the working
code. rest of the feature addition and bug solving can be done with 2x
programmer.

------
cafard
I would mention also
[http://yosefk.com/blog/?s=10x](http://yosefk.com/blog/?s=10x)

------
xigency
Since this article relies on the premise that a "10 X" programmer makes any
sense, I'm going to spend time refuting that central point.

If programmer productivity, or software developer/software engineer
productivity, is measured as a linear function, then it really does no service
to the field. Beyond looking at network effects from the impact developers
have on each other, there is no universal measure of productivity. It would be
more believable to say that certain developers have twice as many or five
times the number of lines of code produced that are defect free, than to say
that they achieve a certain level of productivity.

The two reasons that this should be immediately seen as nonsense to anyone in
the field is that first of all, computer problems deal with asymptotic
complexity. In the asymptotic world, linear functions are outshined by
constant, logarithmic, polynomial, and exponential functions. Furthermore, the
prevailing wisdom among programmers is that 'less is more'. That's why we talk
about minimizing lines of code and trying to avoid the most bugs by leaving
the least surface area for them to exist to begin with. Introducing a measure
where 'more is better' is sort of at odds with this philosophy and should be
viewed skeptically.

Finally, if you look at the great successful innovative products in software,
and technology in general, you'll see that they often make use of new
inventions. There's no way to compare an inventor in terms of productivity by
saying one has 10 times as many patents as the other, or to compare a
mathematician by the number of papers or pages published. The important
difference is the quality of the invention or discovery. The engineers at
AltaVista and Yahoo could have been extremely productive, but without a
revelation like Page Rank, they never could have competed with Google back in
the early days of search engines. Here, two college students writing a small
amount of code outperformed larger companies. This has nothing to do with
productivity and everything to do with talent.

This leads me to believe that the "10 X" slogan is a product of marketers,
head hunters, and pop psychologists. It has no bearing on the field of
computer science and it is a harmful concept because it perpetuates the idea
that software developers are replaceable parts rather than unique
contributors.

~~~
zzzcpan
Simple reality check is that you can't hire a 10x programmer.

------
cdevs
To me programmer that knows devops is the 10x programmer in the right company.

~~~
TurboHaskal
As now you need 10 times more developers to maintain the over-engineered
Docker, Consul, ELK [...] stack while the 10x developer finds another victim
to play resume-SEO?

------
nloa
The article is unreadable on a mobile device.

------
baltimore
The quantity and quality of grammatical errors in the piece were finely
calibrated to keep me reading it to the end. A curious effect.

~~~
antirez
Haha :-) Please point me to the worst ones and I'll fix. Re-reading again btw.

~~~
spydum
Nah, just remind them you made a design decision to focus on the meaning, and
not the grammar, which let you write the post 10x faster ;)

~~~
antirez
That's a valid point! A quality of my poor english is that I write it at the
same speed I write Italian. This blog post took me 10-20 minutes at max to
write, even if the concepts I elaborated for much longer time when
thinking/talking about these issues with people.

------
WildUtah
Fixed width font on a blog? Is it still 1983 out there somewhere?

Maybe you'd be 10x more productive if it didn't hurt everyone's eyes to read
your writing.

~~~
dsacco
Hey, that's a fun game. When the creator of a widely used piece of software
makes an insightful contribution to a long-standing controversy, let's talk
about fixed-width formatting.

------
sametmax
Lol, HN, the place where people try to answer to an expression, a saying or an
image by being technically correct.

Your comment could be a line from Sheldon in the Big Bang Theory :)

~~~
crazypyro
Responding with civility to the pedantry is just a part of HN. I've found that
being humble to comments like these, even if you disagree, is the simplest way
to defuse the situation.

~~~
Chris2048
Responding with civility to non-pedantry is also a part of HN; which is more
relevant in this case, lest anyone mistake my post as pedantic.

------
d--b
10x programmer = very good programmer. End of discussion.

~~~
titraprutr
You are wrong. End of discussion.

------
HugoDaniel
I am the mythical 1/10x programmer. Sadly currently not available for hire. :)

------
throwaway_374
The 10x programmer is a myth perpetuated by senior management to get compliant
submission from naive young code monkeys. End of discussion.

~~~
pawadu
I don't think you can fool junior devs so easily, from inside of the team it
is very easy to see if a person is a 10x or not.

In fact, the management are often the last people to notice if someone in
their company is a 10x guy.

------
dkarapetyan
Sigh. Why do we keep perpetuating this myth? From the words of the greatest
genius of the 20th century

“Right. I don’t believe in the idea that there are a few peculiar people
capable of understanding math, and the rest of the world is normal. Math is a
human discovery, and it’s no more complicated than humans can understand. I
had a calculus book once that said, ‘What one fool can do, another can.’ What
we’ve been able to work out about nature may look abstract and threatening to
someone who hasn’t studied it, but it was fools who did it, and in the next
generation, all the fools will understand it. There’s a tendency to pomposity
in all this, to make it deep and profound.” – Richard Feynman, Omni 1979

Stop the pomposity. Please.

