
Alan Cooper on the “10x” Programmer - jamessun
https://twitter.com/MrAlanCooper/status/1150215587978596353
======
closeparen
All I can say is, it’s been my subjective experience that competence and
productivity are _really_ variable. Some people at my company can produce
beautiful, working, end to end solutions for complex problems in the time it
takes others to grind out trivial maintenance tickets. Everyone knows who they
are. Programmers are _not_ basically all the same, and it’s worth thinking
about the nature of the differences if you want to become one of those people,
hire them, retain them, grow your team to be more like them, etc. To write
them all off as myths, children, assholes, etc. is to reject the possibility
of substantially improving at our craft. That’s a dangerous thing to do.

~~~
alexandercrohde
Agreed. I was formulating it as this (at a previous job, obviously)

There are 4 "top engineers." All 4 of these top engineers would identify each
other as such.

There are 4 "D tier engineers." You'd rather have any ONE of the "top
engineers" than ALL the "D tier" engineers.

These D-Tier engineers usually end up "managing" a rote manual process (e.g.
calling a script sending emails in batches manually), when any "top tier"
engineer would have written an automatic scripted solution that runs
periodically, batches on an intelligent interval, logs its output, and
automatically alarms if its results are anomalous (and done so in a week and
moved on to a new project).

------
lawn
One interesting twist is that some problems are completely intractable for
most programmers. I mean that they cannot produce a working solution no matter
how much time or effort they use, or if they do it's so riddled with bugs it's
practically useless.

Thus it follows that for certain tasks there are "∞x" programmers. Therefore
there are absolutely "10x" programmers as well, which fits in with my
subjective experience.

Certainly domain knowledge can play a very big role, but there are also rare
individuals that seem to be much more productive no matter the task.

~~~
CountSessine
_I mean that they cannot produce a working solution no matter how much time or
effort they use_

Of course, but they don't represent the middle of the distribution. When
people speak of the myth of the "10x programmer", that claim is meaningless if
they can hold the reference productivity all the way to the far left of the
distribution.

Any meaningful claim of "10x programmers" needs to be measured against the
mean or median of the distribution - the so-called "average programmer". How
many non-dysfunctional "10x programmers" who don't create messes for others
genuinely exist?

~~~
opportune
>but they don't represent the middle of the distribution

Really? I don't think most middle-of-the-road engineers, given certain
requirements, could come up with a working solution in any reasonable amount
of time. For example if you just told an engineer "Implement a basic server
that can execute queries based on this language spec, where you upload tables
as immutable tab-separated text files" I'd guess only the top 5% of engineers
could get something working in less than a month.

I don't think that executing tasks like this is something that innately only
some small x% of engineers can do. For example, almost all engineers will lack
at least some of the skills needed to complete any sufficiently large task:
best practices for translating a query to a query plan, how to do efficient
Ser-De, what data structures to use to implement the data, etc.

But most engineers lack the meta-skills or traits needed to complete the task.
For example, would they first look at how basic SQL implementations and toy
projects work? Look up some of the theory of RDBMS? Would they know how to
write good tests, good class structures that don't require refactoring in 2
weeks as they understand more portions of the problem. Would they try to roll
their own query parser or use a standardized tool like antlr?

------
froh42
As an experienced programmer - if you really want to improve productivity 10
times, find the junior programmers in your team, empower them, give your
advice when asked, shut up when not being asked, tell them they can do that
hard task and help them out when they have problems. Be a decent human being.
Then watch with pride as they grow in amazingly quick time. Oh - and just work
for a company, that honors when you're doing that.

Nowadays programming is teamwork.

~~~
bovermyer
I'd argue that programming, like any other human endeavor, has _always_ been
teamwork.

~~~
EForEndeavour
In a sense, every programmer is a member of a global, mostly remote,
asynchronous team of every person who contributed to the hardware, software,
documentation, and theoretical foundations upon which the programmer depends.

------
netsectoday
Here are some indicators I've seen from 10x and 100x:

The 10x person fits very well in their organization. They are admired by
upper-management for their ability to quickly comprehend, estimate, and
deliver solutions to problems. They mentor everyone that asks or needs help.
They provide 95% test coverage on all code. They show up for work well
dressed, clean-cut, and on-time every day. Their code isn't 'brilliant'
because they understand it must be maintained by the whole team. Their code
reads well across difference experience levels but also includes clever
tricks. They have an absolutely rock-solid understanding of the operating
environment, platform, and modules. They don't document their code. They are
the smartest person you know.

The 100x person seems to fit very well into the organization at first, and
appears to be a 10x. They take on several seemingly-impossible tasks up front
and eat it for breakfast. They automate large portions of the business and
their own processes. They provide 99% test coverage on all code. They create
production-quality docs after their public interface solidifies. They know
security and implement it correctly. They spend months to years on self-driven
projects to master different categories and build their tech-tree. They have
invented tech and patented it. They bump into the intentional barriers of the
organization. They break through and create a billion-dollar product, or they
are removed from the organization. They are the smartest person you know and
without explanation they appear to be insane.

It really seems 10x is a stigmatized term. It used to mean a developer that
could produce 10x lines of code, but at this point I've taken it to mean a
single developer that can leverage technology, their department, and
organization to manifest a 10x positive impact compared to someone just
cashing their check delivering story points. I don't think this term really
fits for someone on the spectrum wreaking havoc in their organization.

~~~
jmchuster
in my experience, 80% coverage is about the correct number, but then those
same lines of code are being covered over and over again for each major
business use case.

~~~
hinkley
I begin to relax around 85%.

It’s perfectly possible for a project to hit 85% without much untoward going
on. Running the code and testing the code are not the same, and as the numbers
go up I tend to find shenanigans.

I’d rather have an honest 85% than any dishonest number you could want. My
butt starts to pucker again above 95%, because it’s all lies.

There also comes a point where running certain tests by hand is faster or more
reliable than having a test for it. False positives (failing tests) are
expensive, and in a way that is often counted poorly.

For a start, a false positive doesn’t cost the time of the test, it costs the
time of the entire test suite times three - the one you wasted, the one you do
over, and time between getting a failure and noticing the failure.

It also costs trust in the tools. Red tests become untrusted, which really
hurts when you have a test that has false negatives. People become conditioned
to hit the run button again without understanding the error, which then blows
up farther down the line, possibly in production.

~~~
netsectoday
> My butt starts to pucker again above 95%, because it’s all lies.

With the way you are describing false-positives; it sounds like most of your
tests are written as integration or feature specs. Exercising the UI at 95%
coverage is insane (maybe that is why you said it's all lies). You will
definitely be pulling your hair out with false-positives and with a large
enough project you'll never get it 100% passing each day.

The answer here is to shift your tests from the UI or integration level down
to unit tests. You should test at the function or model level with unit tests
to pin all possible execution paths, then perform a sanity check test in the
UI. For example; exhaustively test your login module at the unit level, then
perform a sanity check at the UI level. Moving exhaustive tests down to the
function or unit level increases test speed because you don't have to load or
render the UI to perform the tests (which also eliminates most classes of
false-positive tests).

If you or your team have issues with false-positives at the unit level then
something isn't right with your test harness, OR you need to git-blame to
identify the person on your team that needs some mentoring.

~~~
hinkley
Testing is hard. Most of the people who tell you otherwise are full of...
bravado. Sometimes they have the worst tests.

When I started working with more dynamic languages I took comfort in the
promises from TDD folks that you can write tests to cover all of these things,
but I've seen how tests are written in practice and it's not good. I've met
maybe ten people in twenty years who are really competent at writing
bulletproof tests (as in, "You wrote tests for that? Enough said" versus Trust
but Verify) and I am not at the top of that list. Frequently enough, I find
eyerollers that have my name by them in the commit history.

I'm not saying I'm ready to go back to static languages because of this, but I
will say that I see evidence for hope on the static analysis side for once in
a very long time.

As you say, the problem is often discerning between unit tests and functional
tests. Some people clearly can't tell the difference, but a number of people
have confessed discomfort at writing unit tests (something about my frank
communication style seems to invite people to share their fears with me, and I
hear things that the "everything is great" people don't due to self-
censorship). That these unit tests seem juvenile, pedestrian. Remedial. But to
my mind that's the point. The cognitive load of determining why I just caused
a bunch of tests to go red should be near zero, since I'm still trying to keep
my head wrapped around the new code I'm in the midst of writing.

For about as long as I've been writing tests I've worked with people who think
writing their own mocks or helper functions in tests is a good use of time.
They take some work, so once you have them working they write five more tests
that use them. The poor SOB who gets a red test six months from now has no
idea what's going on.

Worse, adding more to these mocks may cause some of the tests to be evergreen,
and others to be required (deleting test 1 makes test 3 fail). Which is only
discovered when a customer complains about bugs and you say, "wait, don't we
have tests for this?" The tests are coupled which is bad juju. Every test
should be capable of being run in isolation (debugging your tests!)

Often the first thing I do is rip this mess out and winnow the mocks down to
the one, two, or three calls that actually need, so each test can be taken at
face value. I also replace a lot of ten line tests with more four line,
transitive tests (if A->B and B->C, then A->C.) Then I remove any coupling
between the input and output that wasn't fixed by doing that (once a month
almost, I find a test whose assertion boils down to expect(a).toEqual(a)). And
the utility functions get split up into matchers with much more diagnostic
data added in, and a bunch of incidentals taken out.

Effectively what we are doing versus languages where writing the code up front
requires more thought, is that we are marking stories as done that aren't
properly done for weeks, months, or years. It's a bit of knowledge that makes
me uncomfortable. I have a lot easier time hiding that discomfort with people
whose position in the org chart implies that they are still learning, and
quite a time being constructive to the braggadocios. It's a lot of emotional
labor and it's taxing.

------
mikece
There will always be outliers but it really depends what thing the 10x
programmer is making ten times more of. If it's simply lines of code then it
can strongly be argued that he's creating 10x more technical debt as well, as
one of the stories suggests. I've read that many outlier programmers are on
the moderate-to-advanced portion of the autistic scale, at a place where it's
actually a superpower in terms of being able to concentrate and write massive
amounts of code and usually very good quality. The biggest problem with devs
like that is that their colleages/teammates have a hard time keeping up with
them and management usually tries to coerce others to try to catch up and not
treat them like the benevolent freak they are. Even if there's no conflict
with a high quality 10x performer there's also the future case problem of
trying to figure out how to fill the shoes of such a dev if/when they leave.
Management will never authorize hiring 10 people to replace that person, and
unless the person was writing perfect code your maintenance is usually a lot
more than your staff can handle as well. Are there other fields/jobs where
someone can consistently produce 10x more than others simply on their own
ability?

~~~
AlchemistCamp
> Are there other fields/jobs where someone can consistently produce 10x more
> than others simply on their own ability?

Sales. Some people can make it rain and generally nobody begrudges paying them
well to do so.

~~~
barry-cotter
Fiction or non-fiction writing. The difference between Terry Brooks and the
average wannabe fantasy author is enormous and the difference between him and
JRR Tolkien is greater again.

Mathematics. Terence Tao is as far ahead of the average Math professor as they
are of the average high school Math teacher.

Law. If you give the average lawyer twenty times as much time and all the
research resources of a partner at Skadden Arps the Skadden guy will still
come out on top.

Finance. Whether you’re talking VC, PE or Hedge Funds the people at the top
are a lot more than ten times as good as the average, never mind the marginal
member of their reference class.

All of academia as far as research is concerned. Research impact as measured
by citations is a power law. People at top departments routinely get hundreds
of times the citations of those at no name ones.

In any human endeavour that isn’t limited by severe bottlenecks in material
input you get people who can do much more with much less than others can, and
who are capable of doing things that those less skilled simply can’t do.

~~~
rightbyte
Add carpentry or vehicle technician to that list. All jobs where you have some
sort of choice on how and what to do and motoric aptitude leads to high
variance in skills.

The big difference is maybe that bad vehicle technicians are singled out by
the boss or customers and quit? While neither the boss or customer can
pinpoint a single programmer.

~~~
tuesdayrain
I think this boils down to literally any arbitrary skill based activity.
Unless the output is heavily dependent on RNG, there will always be someone
who is orders of magnitude better than the average person.

------
intellix
Definitely, but only because some developers are insanely incompetent.

Sometimes they'll spend days going around in circles, creating files and
writing hundreds of lines and introducing a couple of dependencies. When it
comes to review time it's like... Wtf are you doing? It's a 5 second one word
fix?

It's not 10x code, it's 10x faster to deliver value and solve problems

------
futureastronaut
Being a 10x programmer or whatever isn't all it's cracked up to be. It's not
like they let you work 1/10x, or even 1/2x. You're expected to deliver that
10x 50 weeks a year, it's impossible to not get burned out. The "velocity
tracking" craze is killer. A very strong developer and regular in #python on
IRC was working as a janitor for a while. I didn't get it then, now I totally
get it. It's hard to muster the motivation to continue working in software.

------
TheOperator
>The 10x programmer is essentially a libertarian concept: That is, they do it
all by themselves because they don’t recognize how much is done for them by
others.

I'm finding myself meeting a lot of "10x" descriptors. I'm not doing 10x the
work but I'm definitely doing the work of the next two highest performing
colleagues put together.

I also see myself putting burdens on my team. My communication, teamwork, and
managerial skills are poor and always will be. Yet I always seem to do things
technically that makes people look at me like I discovered fire. For me to say
I didn't outperform my colleagues would be effectively to say I had no value
as an employee since there would be nothing to compensate for my shortcomings.
There have been meetings about me where everybody except me was in the room
and I was talked about and the only reasons the team decided not to fire me
was my performance and work ethic.

It makes me feel really bad reading all the response to high performers that
aren't well rounded like they are inherently arrogant toxic drags on a team.
There's nothing wrong with having an employee with a lopsided skillset in a
team that can support somebody like that. I think seeing such employees as
inherently toxic, or seeing them as a holy grail. They're like artillery; only
effective with support.

~~~
deogeo
> My communication, teamwork, and managerial skills are poor and always will
> be.

Could you elaborate on how they're poor? And why you think it won't/can't
change? You seem to have expressed yourself very clearly in this post, so at
least when it comes to communication, I can't deduce any shortcomings (from
this post).

~~~
TheOperator
Autism. So text based communication isn't impaired. Also led me to spend a lot
of time on the computer so I naturally got better at using them. I send a lot
of emails at work and my co-workers will usually try and deal with walkups.
Writing is a strong point for me.

There's little problems with communication like having the emotional
intelligence to tell when your co-workers are having a hard time and when to
back off and treat them differently. I lack that which puts extra stress on
them. I tend to say too much and make my team lose face and cause us political
problems. So I try to compensate by doing such a good job my co-workers won't
be under as much pressure to work hard and my team will be doing such a good
job we won't get in shit.

~~~
yarg
Just know your limitations. I worked with a guy, somewhere on the spectrum.

He was very good at some things, but understanding other people's perspectives
wasn't one of them.

He was excellent from a broad architectural perspective, but failed to
acknowledge his limitations in regard to API development and user facing
content.

There will always be a difficulty in understanding why it is that certain
concepts are beyond our grasp, but it might not stop us from understanding
that they are.

------
Traster
I feel like we probably spend too much time playing around with the idea of
10x engineers. It's definitely true there are more effective engineers and
less effective engineers, but I really find it funny that there's always a
focus on the 10x engineer. Partly because it's impossible ot judge a 10x
engineer truly, and partly because it almost always is accompanied by a story
about how the 10x engineer only works on one specific type of problem, almost
never in a way that adds value to a customer. What you really often have is a
0.95x engineering team - where one engineer has the 10x reputation and the
team as a whole is performing 0.95x. Meanwhile the 3x team contains a number
of '10x' engineers operating at 4x and making sure everyone else is the team
is around the same level as them.

What I hope we can all agree on is that in every day life we're a long way
past the point where a single engineer is going to make or break your company
by being 10x. It's far more important to be making sure that a team of 10 is
working at 3x or a team of 100 is working at 1.2x.

~~~
segmondy
I think the focus is just pure jealousy just the same way people are jealous
of those who are 10x income earners.

There are 10x engineers out there who not only product great work, but solid
work that doesn't need support, they test, they document. They might not be a
pleasure to work with for most because their thinking level is completely
different and they don't subscribe to modern software rituals. They focus on
what it takes to get it done.

I can't agree that we are way past the point where a single engineer can't
make or break the company being a 10x. Sure for most enterprises, but startups
and small companies those are still valuable if they can get one.

------
drdeadringer
I remember once being asked during a phone-screen how many lines of code I had
written. Ever. Some of those things were on classified systems years ago,
there is no way I'm going to remember that or even be able to look that up any
more. Why would I ever log "wrote a net-worth of xyz lines of code today" for
a personal record? I've never worked for anybody who had that as a metric but
apparently I had a chance to now; I gave them an estimate and moved on.

The kicker was that the question had absolutely nothing to do with the job.
Nothing.

~~~
esmi
It was probably just a question testing your ability to estimate. Of the “how
many manholes are in Seattle” ilk.

~~~
cruano
[https://www.youtube.com/watch?v=sxhKMuDJ_E8](https://www.youtube.com/watch?v=sxhKMuDJ_E8)

------
fastbeef
10x discussion aside, I found this quote to be eye opening, and not just about
programmers:

“The 10x programmer is essentially a libertarian concept: That is, they do it
all by themselves because they don’t recognize how much is done for them by
others.”

------
thecleaner
I think the people looking hard for 10x engineers are poor team builders. The
thing is a team of two good engineers can be a much more potent combination
than one 10x arrogant prick who cant communicate or work in a team. Good
engineers are still rare but they more frequently found than 10x engineers.

------
cafard
Did Gerald Weinberg speak of 10x programmers? I don't think I have a copy of
_The Psychology of Computer Programming_ , but that doesn't really sound like
his later work.

------
foobar_
After working with ~ 30 odd programmers, I would probably classify myself as a
10x. I think a good chunk of HN'ers are 10x, with imposter syndrome of course.

1\. Patience - I have the patience to sit through and fix a bug. Googling it,
reading the source ... this is fun for me. 1x programmers give up very often
and very soon. They either blame others, feel pity for themselves for not
figuring it out or hate the computer for giving the wrong answer.

2\. Fuck OOP - I stick to the separation between data and code. If I am forced
to use OOP, I abuse the command pattern. My code is procedural for the most
part. Procedural code is easier to debug .. usually, when I see a bug, I know
the exact function. 1x go "wow" at this, whereas I feel like an Imposter.

3\. Tools - This would probably be my biggest sin and probably where I could
be a bit of a hipster. I stick to tools and libraries that make me productive.

4\. News - I try to keep up with the latest news. This often helps me leverage
the next best thing for increased productivity.

5\. Egoless - I don't care about rewriting, throwing away and deleting code
... trying a new library. 1x programmers get attached to their babies.

6\. My code is not a mess, your ideology is a mess - I've found it easier to
work with absolute beginners, 0x, than "experienced" programmers who like to
throw jargon around. Beginners tend to find my code easy to follow, easy to
fix, easy to debug. The first instinct of the "experienced" is to rewrite it
because it's not "clean" enough for them. I'd rather you look at the forest
than the tree. The whole thing delivers 80% of what business users want! I've
had three projects where I did in two weeks what a group 10 programmers took
months and that's sad.

Things where I can imporve

1\. Testing - I usually do a lot of integration testing for the critical
paths.

2\. Security - I always tell people to hire pen-testers but no one ever
listens!

3\. Documentation - My biggest weak point of all. In my defense, I choose
functions names reasonably stupidly. I think it's good move to hire great
documentation writers.

4\. Complex Algorithms and Maths - Always good to know more! This is where I
have to rely on 100x programmers to come up with a good library. I aspire to
be 100x.

~~~
nickkell
I'm definitely a 10x programmer, but unfortunately 90% of my time is spent on
hackernews, so nothing is gained.

~~~
faissaloo
That means you're not a 10x programmer.

~~~
mhh__
Poe's law strikes again?

~~~
faissaloo
Guess so

