
The programming talent myth - corbet
http://lwn.net/SubscriberLink/641779/474137b50693725a/
======
nilkn
My own experience just does not agree with this at all.

First, I think we have to distinguish between two ideas here:

* The first is the question of whether anyone can learn to program. I think that for the most part everybody can, just like for the most part everybody can learn high school calculus.

* The second is the question of whether programming ability is bimodal. This is not related to the first question, and confusing the two questions is a significant error. It is entirely possible that programming talent is strongly bimodal and that 99% of people can learn to program.

I've been programming since I was 11 and have interacted with other
programmers all through high school, college, and now working life, and at
every single point of my career -- both academic and professional -- I have
seen that some people are drastically faster and better at programming than
others (but the others are still capable of learning). In introductory
programming courses at college, I've done labs with _very_ smart people who
took 10x longer to figure out the lab than some others. They figured it out,
but they struggled a lot compared to others, despite being very distinguished
undergraduates (Goldwater fellow, etc.).

At work, we've brought on people with 10 years of experience who were 10x
slower than someone else with 2 years of experience.

At school, there were master's degree candidates who were significantly worse
than many undergraduates despite working just as hard and longer.

I could go on and on and on with examples. From my own life the evidence is
simply overwhelming that programming talent is bimodal.

~~~
jeremiep
From personal experience, speed has very little to do with productivity.
Productivity is a function of knowledge and experience.

The most productive programmers I've met almost always had enough experience
in what _not_ to use. They have a clear focus on the simplicity of their code
and their ability to reason about it. They understand the problem and the
hardware as well as the language in a very detailed manner. They are by nature
extraordinarily curious people.

In comparison, the worst programmers I've met were the exact opposite,
learning barely enough to get the job done and never digging into the details.
Sometimes they don't even understand the hardware they're using. They pick the
wrong data structures, think about code first and data is an afterthought.

Productive programmers don't really type faster or think faster. They just
make far less mistakes to begin with and such mistakes always inflate the
development time exponentially.

~~~
altcognito
> They pick the wrong data structures, think about code first and data is an
> afterthought.

It makes me so happy to read this.

Data in the grand scheme of things is vastly more important than code.
"picking" data structures is a luxury in many cases and thus data structure
often dictates the structure and expectations of your code. Data usually
outlives the code. Data is effectively the earth in your code farm. Take care
of it, and form it as best you can given a set of restrictions so that your
program runs smoothly.

~~~
base698
According to SICP data and code are the same! Interesting concept anyway.

[http://stackoverflow.com/questions/355406/concepts-that-
surp...](http://stackoverflow.com/questions/355406/concepts-that-surprised-
you-when-you-read-sicp#answer-483339)

[http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-14.html...](http://mitpress.mit.edu/sicp/full-text/book/book-
Z-H-14.html#%_sec_2.1.3)

~~~
webnrrd2k
That's like saying all Turing-equivalent languages are the same. It may be
true in theory, but is hardly a useful point in most programming language
discussions.

As an example of code vs. data, and this is a general statement (so YMMV) I
try to structure my code such that, if there is a choice between making the
_code_ more complex, vs making the _data_ more complex, I generally choose to
make the data more complex. The code is usually harder to reason about, so
it's a win if I can use a simpler algorithm.

~~~
seabee
Unless I misunderstand your point, how do you create complex data without
complex code? I agree with the sentiment, but priority queues don't organise
themselves. It seems more like its about the abstractions you use.

~~~
webnrrd2k
It's more of a general rule, a rule of thumb, and the difference between data
and code can be very fluid, depending on the situation... But as a general
rule it's worth paying attention to.

Just a quick example -- I need to get going -- Say I have a bunch of data in a
database I need to do something to once or twice, like validating imported
data. It's easier to use a complex select to get it in an easy to process
form, then it is to use a simple select and have a complex algorithm to
process the data. Generally, given the choice, it's easier to have complicated
"static" data, since it's rather static and easier to reason about, rather
than complicated "dynamic" code since algorithms are generally harder to
reason about.

~~~
sokoloff
I agree with your choice in the example, but I think of your select as code,
not as data. So, you're moving the complex code closer to the data, but it's
still code IMO.

------
dusklight
If you started programming when you were 12 and you've been programming for
fun more than 4 hours a day every day since then, you are going to be
drastically better than someone who starts programming in their first year of
college and only does it to graduate. It feels like a bimodal distribution
because you then get both kinds of programmers interviewing for jobs at the
same age when they graduate from college and one of them is going to feel
drastically different than the other.

~~~
xkjkls
This seems like a form of elitism very specific to programming.

I graduated with a degree in Electrical Engineering, and barely did
programming until I began my first job out of college. In many people in the
programming space, I see contempt that coding was something I didn't start
until later in life. When I interviewed for Electrical Engineering positions,
no one ever scoffed at me, "you haven't been computing the impulse response of
a filter for 4 hours a day since you were 12? There's a massive difference
between engineers who have done that and those that haven't."

~~~
derekp7
I think it really comes down to how much enjoyment one gets out of
programming. If you thoroughly enjoy the process, you are more likely to put
in the time and effort (in fact it will feel effortless), and you will be
thinking about it all the time. Then there are those who don't mind
programming, or maybe even see it as a chore, but choose to do it anyway.

~~~
JoeAltmaier
Yes! Like musicians that have tunes running through their head constantly. Or
poets that turn every phrase over in their minds.

Did you ever dream of debugging your children? That if you could only find the
right breakpoint to set, you could adjust them and fix something? Then you are
truly a programmer.

~~~
srryaccntcrtn
_Did you ever dream of debugging your children? That if you could only find
the right breakpoint to set, you could adjust them and fix something?_

Or maybe it's a sign that you should take some time off coding and not take
your work home and give the other half of your brain some room to wander and
explore space and time.

~~~
leppr
Exploring isn't a passive activity, everyone has their own way of discovering
the world and I don't think anyone can claim theirs is superior.

Furthermore, being able to transfer concepts from one activity to another is a
clear sign of intelligence: applying an idea to 1-dimensional text and then
applying it to social relations isn't a passive activity either, it shows deep
understanding of the idea.

------
mcafeeryan92
I couldn't agree more. When I first started out studying CS I was constantly
afraid that I wouldn't be able to cut it because I didn't always immediately
see how to solve algorithmic problems or write code that would work. I got
bogged down in thinking about programming as a problem of learning syntax, and
missed 'obvious' things. I couldn't reverse a string or write FizzBuzz and in
fact part of the reason for that was that I was so sure that programming was a
magical ability that I didn't have because I compared myself to people who had
been writing code since their childhoods, and this created nerves which made
it hard to really think about solving these problems instead of feeling
helpless when I didn't immediately 'know' their solutions.

I powered through that and ended up doing very well in my CS program at
Northwestern, and now am a professional software developer that my peers
consider to be a 'rockstar' programmer, although I still contend that I am
mediocre and there is always SO much more to learn. At my job I frequently
mentor our college interns, and many of them when they come into the job would
be laughed out of the room by 'good' programmers, but after a little bit of
mentoring and consistent daily practice on the job, in 2 months they emerge
'rockstar' programmers themselves, and in reality they are still probably
about average.

Most of the 'bad' programmers many of us come into contact with are just
farther behind on their journey to being great software developers, and may
only be as bad as they are because of fear to ask questions and be judged by
those who think there are only 2 types of programmers.

~~~
pjc50
On magical ability: there's a joke image going around which tells you how you
can easily learn to draw an owl. [http://knowyourmeme.com/memes/how-to-draw-
an-owl](http://knowyourmeme.com/memes/how-to-draw-an-owl)

1\. Draw two circles.

2\. Draw the rest of the owl.

This is a common problem in art, music, sport and programming - you have an
expert trying to teach newbies, and they say " _just_ do this". The newbies
have no idea how to begin to do it and the expert knows it so intuitively they
cannot break it down further. Everyone ends up staring blankly at one another.

Getting people past that point seems to be a skill of its own. Certainly it's
not been easily packaged for programming. Learning involves a lot of guided
experimentation, and keeping the student's morale up is just as important as
the material itself.

~~~
mod
I find that it's commonly best to learn from someone not too far past your own
ability.

My father is a very talented pool player, but he was not the best teacher
until my own skill became pretty considerable.

He's so far removed from the things that are important to beginners. He says
"you have to hit that shot with a medium-power, really good draw stroke." They
have no real idea what medium power is, and no idea what a stroke really is,
and possibly can't draw the ball.

It's possible he's just a poor instructor--that's probably not very related to
his own playing ability. Some people can convey complex ideas in a very simple
manner, and I think they make the best teachers.

~~~
bps4484
I've called this concept in teaching "remembering the struggle". If a person
is so far removed or such an expert in a field, they may not even remember
what a person trips up on when they first get started. They may even have been
so talented they didn't even been tripped up at all. Lacking this ability to
empathize and relate can make teaching very difficult.

~~~
mod
Exactly!

I remember very well the painful process of my dad trying to teach me to drive
stick shift (on his new truck). He never mentioned that the clutch had a catch
point (that wasn't all the way at the floor), but gave instructions that
really hinged on that fact (give it gas, let it out slowly at first, etc).
After an hour of us being very frusrated, I went out alone and taught myself.

I later taught two friends, explaining the clutch's catch point, and they were
'getting it' within a couple of minutes. A few accidental stalls, sure, but
they understood why. 20 minutes or so and they were legitimately ready to
drive on the road (both had been driving automatics for years).

My dad had already been driving for 40 years, he totally forgot the catch
point even exists.

------
empressplay
That programming is a talent is not a myth, and while my life is currently
devoted to developing a platform to encourage more people to learn the basics
of computer science, I will certainly never say "anyone can learn how to code"
any more than I'd say "anyone can become a concert pianist" or "anyone can
become a master painter."

Good programming is an art, and requires talent on the part of the programmer.
There's nothing wrong in saying that. The issue is that there are thousands
and thousands of potentially great programmers who simply never try
programming, just as there are thousands and thousands of never-will-be
concert pianists. But many children take piano lessons just in case. Why can't
they also take coding lessons? Just to see?

~~~
lampe3
to be a great concert pianist it is 5% talent 95% hard hard work... If you
dont train your fingers every day and if you dont play for at least 1 hour
everyday since your 10 or younger you wont become a great concert pianist...

you can say the same for coding. it is 5% talent but the rest is coding coding
coding coding...

If you have talent the start will be easier but at some point talent wont help
anymore just studying and trying.

~~~
vinceguidry
It's not that simple.

So, one of the best illustrations of how talent works is in football
placekickers. To make it in the NFL, you have to be able to reliably kick a
field goal at X yards. X goes up every so often. Some athletes can do it, some
can't. I read a story once about a guy trying to level up his skills to NFL-
level. He spent weeks out on the field practicing his kick. He could hit the
goal, but not reliably. One yard closer, and every kick sailed right in.

One of his buddies, a minor league baseball pitcher, went out with him one
day, asked to give it a shot. On his very first try, he kicked it right in. A
pitcher.

To be great, it requires getting out on the frontier of human ability. That
frontier often looks very, very weird. One seemingly small additional
challenge turns you into a puddle of mush. Getting there requires hard hard
work.

But excelling over everyone else who also put in that hard work requires
talent, and it's generally a binary proposition. Until it isn't. Once Roger
Bannister broke the 4 minute mile, floods of athletes started doing it.

Then the frontier goes somewhere else, the talent required to get there is
increased. But one can only put so many hours of their day into an activity.
So when you're talking about greatness, talent ultimately matters more than
hard work. One should ideally find out as quickly as possible whether one has
the talent to make it out to the frontier of human ability. So they don't
waste lots of time doing something they can never find greatness doing. The
aforementioned aspiring placekicker? Gave it up. Now he's a successful author,
real estate investor and football coach.

------
markbnj
I've been at this twenty years, and I have no doubt that most people can learn
to do it, and some people are just radically better at it. I'm not sure why
those should be either mutually exclusive or controversial points of view.
Where the passion part comes in is that most people, the vast majority I would
think, just don't want to do this for a living and never will.

We're a little like medical doctors in that respect. A lot of people would
like to have an MD's paycheck but very few would actually enjoy doing what an
MD does for a living. Another analogy, and one of my favorites, is to
watchmaking. Watchmakers take great pride in the incredibly close work they
do, and again while it may be work many could learn to do, it is work that few
would want to do. I think this is very true of programming. Most people find
it horribly tedious and boring, and don't see the creative aspects of it at
all.

The last thing I'd note is that the focused act of programming is becoming a
smaller and smaller part of the gig. To be a full-stack developer these days
requires so much more than the ability to create a working program. The big
picture is very big, it takes many years to get a really sound grasp of it,
and you have to be motivated in the first place. Passion, again.

~~~
hasenj
> To be a full-stack developer these days requires so much more than the
> ability to create a working program. The big picture is very big, it takes
> many years to get a really sound grasp of it

This is a major point that tends to be overlooked by a lot of people.

There's a big difference between just "coding" something to make a little
feature work, and actually building an architecture that can support many
kinds of behaviors now and in the future.

Many people can't seem to make the jump to the "bigger picture" version of
programming

~~~
markbnj
> Many people can't seem to make the jump to the "bigger picture" version of
> programming

TBH I am not sure there is even a viable "smaller picture" version of
programming. Sure you can write some simple scripts and compile some C++ or
Java or run some python. But I have to think 99.99% of what you could actually
make a living doing would require knowing a stack at least from the database
up to the browser or desktop.

~~~
hasenj
You can know the stack but then write raw code with nested if statements and
for loops to just implement the current requirements to the letter. As soon as
a small change is introduced to the requirements, you're screwed.

------
belovedeagle
The problem with the argument that "Programming skill can't be bimodal because
that would be elitist and make me feel bad about myself being an elitist" is
that there's a lot of evidence that programming skill _is_ bimodal. Look at
fizzbuzz as an obvious, if not entirely complete, example.

Would it make us all feel better if programming skill weren't bimodal? Sure.
But a roomful of people clapping at that proposition doesn't make it true.

~~~
vonmoltke
> Look at fizzbuzz as an obvious, if not entirely complete, example.

I am not entirely convinced this is not partially a resume screening and
talent pipeline problem. Has anyone ever given Fizzbuzz problems to everyone
who applied to a position? If you haven't, have you ever considered that your
screening process may be broken in the sense that you are passing too many
liars who then bomb the Fizzbuzz portion, but who bump competent people off
the stack entirely so you never test them?

~~~
shubb
I find this idea that there are lots of fake programmers kind of nuts.

Presumably, when you do a resume sift, you look for people with either a
qualification or work experience. Either they somehow faked it through those,
or your test is bad. Fizzbuzz actually tests if you know what % does. Is that
critical knowledge for a webdev?

~~~
Kalium
> I find this idea that there are lots of fake programmers kind of nuts.

I don't know about "lots", but there are definitely people out there who claim
to be programmers but lack the basic competencies they claim. I've encountered
several.

A couple of years ago, I was part of a battery of interviews for a candidate
who claimed a Master's in CS. Their resume said they had done advanced work in
parallelization of video compression. I asked them about it - I wanted to know
how they had handled synchronization and locking.

The candidate looked at me blankly for a couple of seconds. Then they began,
haltingly, to talk about web sessions and logging.

We didn't hire the person, but there was definitely some bullshit along the
way...

~~~
crucini
To be fair, they are kind of separate problems. In Clojure, for instance, you
can write parallel code and the nuts and bolts are handled for you.

~~~
Kalium
With the tools this person claimed to have used, they very much would have
handled all the nuts and bolts.

------
marktangotango
>>Part of the problem there is the lack of a way to even measure coding
ability. "We are infants in figuring out how to measure our ability to produce
software", he said. What are our metrics? Lines of code—what does that
measure? Story points? "What even is a story point?", he wondered.

Indeed, what is programming talent? What is a 'good' programmer? What is a 10x
rock star? These notions are similarly ill defined. I can think of at least 3
formulations of 'talent':

1\. A developer who can craft an exquisite solution to a problem using the
patterns of the domain and/or the idioms of the language.

2\. A developer who puts in Heroic efforts to produce a lot of code in a short
amount of timing, to meet business objectives.

3\. A developer who is 'smart and gets things done'.

One can poke holes into any of these formulations; is the exquisite solution
delivered in a reasonable amount of time? Is the quickly delivered code
maintainable and extensible or a maintenance nightmare? Does the smart and get
things done guy leave a spaghetti trail in his wake?

In the end, I think we've all noticed that some people tend to simply
accomplish more, with less issues and drama than others. Is this real? Or
simply navel gazing? I tend to think it's real.

Edit: spelling

~~~
Zikes
I suspect it will always be a largely subjective measure mostly determined by
the respect or accolades of one's peers or the satisfaction of one's target
audience/customers.

I think StackExchange's "reputation" system is probably the most accurate
discrete measure available.

~~~
gaius
_I think StackExchange 's "reputation" system is probably the most accurate
discrete measure available_

I would be very hesitant to rely on any metrics coming out of SE. Consider
their great programming survey this year, they say the average age of a
programmer is 29. The US Department of Labor says it's 49.

There are a vast number of people out there, well over 90% of the programming
industry I'll wager, who come into work at 9am, do good, solid work all day,
on applications that run the real world, then go home at 5pm and get on with
their lives, who never interact with SE et al at all.

~~~
squeaky-clean
>I would be very hesitant to rely on any metrics coming out of SE. Consider
their great programming survey this year, they say the average age of a
programmer is 29. The US Department of Labor says it's 49.

That doesn't mean they're both wrong. The two are just comparing different
things. The SE programming survey included 157 countries, not just the US. It
also doesn't only include full-time professional developers. 13.6% of
respondents classified themselves as "Student". Only 66.3% of respondents
listed themselves as "Employed full-time"

------
Tloewald
Well let's start with fallacy #1 -- marathon times are normally distributed.

[http://m.runnersworld.com/sports-psychology/round-number-
tim...](http://m.runnersworld.com/sports-psychology/round-number-times-for-
marathons)

Aside from the significant asymmetry of the distribution (of course) there's
the spikes where people push themselves to hit a mark (i.e. 3:59 vs 4:00).

Programming is full of weird incentives that will distort themselves in any
measure -- e.g. if A gets his/her work done in 0:20 and B in 7:30 and A then
goofs off or helps other coders, the measured productivity difference might
not be huge. Since most people who code are having their behavior distorted by
measurement that's a big issue.

From experience -- the incentives against outperforming expectations are huge
-- demonstrate you're 3x as productive as the guy next to you and from now on
you have 3x the workload for 1.1x the pay. In practice what happens inisthe
better coders pad their estimates and get trusted with tough problems rather
than time-consuming problems.

------
StillBored
1.5 Million position job gap? Really? I hate when people throw the us labor
stats numbers around like that.

Uh, hu, I wish these statistics would be backed up in a more through manner.
Like maybe forcing companies to disclose how many applicants they get for a
position and why they were rejected.

I say this because, I recently interviewed for a position doing some pretty
low level work, where apparently there were a 100+ applicants (or so the
hiring manager said). But it was believable because the job was posted on
linked-in, and linked in reported that 34 people applied for the job.

So, a lot of people applied for the job, were they qualified? Well,
considering I know two people with skillsets that are compatible with the
position, and both are unemployed and live within 5 miles of the position, I
would really like to see this kind of data industry wide.

AKA, assign each candidate a number (only disclosed to the candidate), and
then publicly post the number, and the reason for disqualification. Maybe if
someone can figure out how, disclose the skills the candidate says they posses
without directly correlating them to the candidates public profiles.

That would give us an idea of where the skills gaps are, or even if they are
real. Rejecting a bunch of candidates because "they don't fit the culture", or
they don't have 5 years experience with CMVC, or perforce or some other tool
not directly related to the specific job requirements needs to be public
information. Or for that matter, that someone thinks they will ask for more
money than the position pays, without making them the offer.

------
cmenge
It's not that programming skill (whatever that is) is bimodal, it's the
effectiveness of the engineer in a typical development scenario. That stems at
least partly from the fact that programming is hardly ever a one-person
endeavor, contrary to running.

Since scaling a team increases friction and overhead, a small number of highly
skilled engineers can be absurdly more effective than a set of teams, which
also makes them more valuable, but not necessarily as extreme as in sports.
Add preferential attachment to the equation (good engineers try to work with
other good engineers / hire only top talent), and the U-curve starts to make
sense IMHO.

~~~
Lawtonfogle
It also doesn't count for how low skill (inherent, trained, etc.) can have a
negative impact on a project by incurring vast amounts of technical debt that
will have to be repaid that outweigh any positive contributions made.

~~~
agentultra
I haven't really seen any evidence that this is true.

The talent myth as Adrian describes it is one of stereotyping: there's no data
to accurately measure skill in programming so we simplify things in our heads
and believe you're either talented or not. This myth appears to directly
support your claim: untalented individuals are a cost burden on the
enterprise. If this were true there would be far fewer enterprises to match
the number of actually talented programmers: that is to say you and I are not
likely one of them.

The reality I've experienced suggests that deliberate process correlates
strongly to quality. In the absence of true talent we can still write great
software by leveraging processes and tools to wrangle complexity and manage
defects. We see this in plenty of engineering disciplines. Why is software so
special?

~~~
Lawtonfogle
>The reality I've experienced suggests that deliberate process correlates
strongly to quality. In the absence of true talent we can still write great
software by leveraging processes and tools to wrangle complexity and manage
defects. We see this in plenty of engineering disciplines. Why is software so
special?

Because of the entry level.

Think of this joke: What do you call the guy who graduates from medical school
as the bottom of his class? Doctor.

The point is that even though there is a worst, they still have to have gotten
so far. Even the worst engineer had to do good enough to become an engineer,
which is a far greater test of skill than what I've seen in some interviews,
especially when those hiring are not technically experienced.

I think many who call this a myth happen to have rarely come across these
people in technical roles. At worst they may have interviewed a few, but they
were quickly cast aside. They've never met a person who managed to get into a
senior position as a cargo cult programmer who can't explain even the basics
of the frameworks they are using.

~~~
agentultra
The point Adrian was trying to drive home is that for any quantifiable skill
we can measure we find that there is a bell-curve across candidates. The over-
whelming majority of people are average in every human endeavor that we can
accurately measure in this way. The theory goes that software development is
not different.

If we assume that the bell-curve is likely to exist then it's probable that
only a handful of people exist in this current generation who are at the far-
end of the curve. If the success or failure of an organization involved in
developing software is dependent on the talent of its people alone then I'd
rather speculate on futures.

If there is such a thing as the Mozart-of-programming you can't expect to hire
a whole team of Mozarts. Any policy to only hire the best available
programmers is upholding a culture of egotism and hubris. It's just not
probable.

I've only seen this belief propagated by people who are more concerned with
being better than everyone else. It's convenient that their finger only seems
to point outwards. I don't like working with people whose sole talent is the
ability to recognize the lack thereof in everyone else but themselves.

------
VLM
WRT mythology, one important takeaway about the "1.5 million programmer job
shortage" is the management declaring the shortage isn't looking for
programmers, or white male programmers, or "rockstar ninja real programmers"
but ivy league grads willing to sit thru 8 hour logic puzzle and coding
interviews about linear algebra to work for $7.25/hr for minimum 80 hours per
week in an open office packed in like sardines while people "work" by playing
foozball for 60 hours per week next to you in one of the most expensive cities
in the world for next to no stock options in a field rife with ageism where
their career will be shorter than a typical NFL quarterback. But other than
that, no problemo.

In reality there's no shortage, and isn't going to be one, outside a couple
industries in NYC and SV.

------
hikz

      That means we need to be doing something to get more people into our industry.
    

Why? What's in it for me?

    
    
      The EU has published similar numbers, 1.2 million in 2018—three years
    

I am a first-year CS student in Denmark and I hope you don't succeed in
getting more people into the industry to fill those jobs before I graduate.

The lack of (talented) programmers is going to put young CS/CE grads in an
advantageous position both in term of salary and job opportunities. I am happy
employers are having a hard time finding people to fill those jobs. That makes
life easier and safer for me.

The people screaming for more programmers here in Denmark are people in the
government and Dansk Industri (lobby group representing bigger Danish
corporations). The government cares about something they call "Denmark's
global competitiveness" and the lobbyists in Dansk Industri want to flood the
market so they can lower programmers' salaries. I don't care about the former
line of buzzwords and the later is a hostile action taken against me as a
programmer.

Don't get me wrong. I care about our industry. I will contribute to open
source in the summer leave and I am involved in organizing some monthly
meetups. But in the end of the day I also want a job.

~~~
sqeaky
This is such a backward view of how the programming job market works that I am
not really sure how to approach it.

You can't really have too many programmers. Every field needs some degree of
computer automation. As more gets automated innovations are made that will
show us how to automate something that hasn't been automated in other fields.
Until everything in every field is automated more programmers create more
opportunity for even more programmers.

I also think it is messed up to be selfish enough to hope your whole country
suffers until you can secure a job.

------
exstudent2
> If the only options are to be amazing or terrible, it leads people to
> believe they must be passionate about their career, that they must think
> about programming every waking moment of their life. If they take their eye
> off the ball even for a minute, they will slide right from amazing to
> terrible again. That leads people to be working crazy hours at work, to be
> constantly studying programming topics on their own time, and so on.

In my experience people really are either amazing or terrible and those that
are amazing are super passionate about programming, think about it and study
it all the time...

I don't really understand the argument as to why this isn't desirable. Just
like any difficult task, performing well is going to take a lot of practice
and dedication to keep your skills fresh.

~~~
gaius
99% of the software that actually matters - medical devices, air traffic
control, credit card processing, phone switches, you name it - is written by
people who work 9-5 and don't think about their jobs outside work. If all the
websites programmed by "rock stars" shutdown overnight, the next week everyone
would have forgotten they ever existed.

~~~
exstudent2
Having worked on several systems like that, I can say there are definitely
passionate developers behind any serious code. An "old guy" I know that has
lead development on several extremely high volume payment processing systems
has the most extensive personal CS library I've ever seen.

No one is writing high performance code without deep knowledge of what they're
doing.

~~~
gaius
That is true. But also noone is writing critical systems staying up all night
drinking Red Bull. Look at other engineering disciplines. Where are the bridge
and dam building rockstars? Where are the nuclear power ninjas?

I wonder what "rock stars" are going to do when they discover other uses for
their time, hobbies, families, sports, travel and so on. Resign?

~~~
exstudent2
I think you're talking about two different things:

1\. People that are dedicated to their craft, write A LOT of code and self-
study in their free time.

2\. Red bull drinking Valley stereotypes.

People from camp 1 don't live up to the stereotype of the "rock star" but
definitely work way more than 9-5. Where work is defined as studying
languages, domain specific knowledge, low-level code...

~~~
vonmoltke
People from camp 1 also do not generally curate a public profile, since they
generally come from traditional engineering cultures where judgements are made
based on past experience and ability to reason about complex systems during
interviews than on flashy portfolios and pop quizzes.

------
mkr-hn
The importance of talent is often overstated, but it's not a myth.

The years I spent trying to do software development were like beating my head
against the wall. Everyone seemed to be much better than me, and it led me to
give up after a few years of starting and stopping. If I couldn't even manage
to make a simple application, what was the point when so many people made one
every day?

So I gave up and focused on other interests, like writing and art. Writing has
served me well, but doesn't interest me enough to get much written. I'm just
bad at visual art, no matter how much I practice and study. Fractal art is
about all I can do[1].

Then I picked up a MIDI keyboard, a DAW (first LMMS, then Studio One) and had
fun making music immediately. Haven't been able to stop since. Now I'm
rediscovering my interest in A/V engineering. As you can imagine, knowing a
little programming helps a lot with both of these things, and that's how I
found an interest in writing code.

Most of the code I wrote even before finding a need is solid, efficient, and
secure. But that's because I'm so bad at it that I have to be careful. If I
don't write clean, efficient code, I won't be able to understand it well
enough to fix it when something goes wrong.

I think we would be better off encouraging people to try many different
hobbies rather than pushing them into something they have no affinity for.
Then, when something clicks, show them how programming can make it better.

[1]
[http://www.designbyhumans.com/shop/mkronline/](http://www.designbyhumans.com/shop/mkronline/)

~~~
georgemcbay
This is all anecdotal but learning to program is (IMO) somewhat like math in
that it is virtually impossible to learn it while not feeling confused and
lost because there's a lot you have to internalize (and often this includes
multiple concepts sort of all at once) before everything clicks and makes
sense.

Talent is a thing, surely, but IMO the primary "talent" when it comes to
learning to code is having the mindset where being lost isn't a problem for
you. Some people hate this feeling of not intuitively knowing what is going on
(possibly for an extended period of time!) while others embrace it, the latter
tend to be the ones who end up excelling at programming (and/or math).

"Most of the code I wrote even before finding a need is solid, efficient, and
secure. But that's because I'm so bad at it that I have to be careful. If I
don't write clean, efficient code, I won't be able to understand it well
enough to fix it when something goes wrong."

If your code is good it is because you are a good programmer. Full stop. Not
being able to understand and fix your own code if you aren't writing it
cleanly (and as simply as possible while doing the job) is universal.

"Everyone knows that debugging is twice as hard as writing a program in the
first place. So if you're as clever as you can be when you write it, how will
you ever debug it?" \- Brian Kernighan

------
mannykannot
I am well aware that there is a considerable range of ability among those who
program professionally, but it never occurred to me to think of the
distribution as being bimodal. I have also noticed a preference among
programmers (or rather, more likely, a vocal minority) for reducing all issues
to simplistic dichotomies (e.g. the methodology wars.) Perhaps this is just
another straw man, distracting from the real issues of how to raise levels of
performance incrementally and generally?

------
serve_yay
Well, I just disagree. I've been doing this professionally for over 10 years
and some people are bad to okay at it, and others are good to excellent. If
there isn't some deep-seated reason why people fall into one group or the
other, if it's just practice or whatever, fine. I don't know what the
explanation is. And I don't assume it's impossible to move from one group to
the other, far from it. But I would say the bi-modal thing seems roughly
correct.

~~~
hnnewguy
Huh? You say you disagree, but then state that programmers can range from bad
to okay to good to excellent? That isn't bimodal, and is precisely the authors
point?

------
robotcookies
The story mentioning the woman who did not consider herself a "real
programmer" is obviously disturbing. But that is not the consequence of
believing in a bi-modal distribution of programming talent. Rather, it is the
consequence of believing in a bi-modal distribution AND believing that gender
also fits that distribution.

The bi-modal distribution of talent is not a myth nor is it intrinsically
harmful. However, it can be extremely harmful when misinterpreted to mean
gender, race, etc. The author is subtly conflating the two and in the process
doing more harm than good. This does not help women, minorities or other under
represented groups.

------
ebbv
Anyone who has dealt with Django should believe his claim to being mediocre.
;)

Actually I think this is a good article which makes some good points, but I
think it misses another harmful myth; that people are one thing all the time.

It substitutes the idea that people are either good or bad programmers with
good, bad or mediocre.

But in reality, one person is not always good or bad or mediocre all the time.
Someone might write brilliant code today on this project the are passionate
about, but write shitty code next quarter on a project that doesn't have their
interest. Or while they are distracted because something came up outside of
work. Or because they are writing in a new, unfamiliar language and they don't
realize the code is bad. Or any number of other reasons.

Human beings are fluid things. Over time someone may develop an average
quality of output, but that's only going to be something that comes about over
time. And ultimately, I think it's somewhat meaningless. Since the average is
not what you care about in any given case, and may or may not be applicable to
whatever new thing comes down the line.

Plus, as the article points out; how do you really define good or bad? Number
of errors that get caught by unit testing on first submission or number of
errors which don't get caught until the code is already in production?

------
o_nate
It seems plausible to me that the distribution of innate programming ability
is a bell curve, but the distribution of programming effectiveness is bimodal.
The missing ingredient of course is experience and education. It's similar to
an athletic skill, such as the high jump. If you plotted the maximum height
that a random assortment of individuals could jump, the resulting graph would
be bimodal: the top clump would be those who can do the Fosbury flop and the
bottom clump would be everyone else. The innate ability to jump follows a bell
curve distribution, but unless you know that trick, you'll end up on the lower
clump.

~~~
weatherlight
That would be true if programming were just one thing.

~~~
o_nate
Sure, so multiply above example by the relevant number of sub-specializations
within programming. Same principle holds.

------
astrocyte
It's quite simple... There are people who have a knack/drive for understanding
the world/universe and its many functions. People who care to understand the
root mechanism as opposed to speculating about how the tree and leaves form.
This is the base talent behind good software engineers who become great
through experience and challenges. If you -truly- understand something, you
are good at communicating it in many ways and capable of expressing it in a
'language'. What came first? Language or understanding. What do a lot of
institutions teach? Programming. What don't companies want to invest in :
Understanding....Mind the gap.

You may be good at a language and still not have any good ideas to
express;Programmer

A lot of people fail to see this and go on with arbitrary measures of what
makes a good software engineer. Oh nos', you don't know how to craft the
perfect general expression for this. Oh nos', your Translation look-a-side
buffer calculation was off... And so on.

The typical interview centers on how well someone programs. People write long
articles which stirs people into a frenzy and much is lost in the discourse.
Mindless interview structures are administered which tests people on their
ability to work through leaf problems.

Tress of horrible construction are made and root analyzers are called in to
save the day. Since there aren't many who fully understand root construction,
such talent is hardly ever understood for its value : Modern software
engineering at your alphabet soup of companies.

And here we are. Much will never change because there are few actually looking
at the root issues. Few actually care to. It's all about the leaves and low
hanging fruit.

------
diminoten
There is a myth, but the myth propels reality. Take this line in the article
as a reason:

> That leads people to be working crazy hours at work, to be constantly
> studying programming topics on their own time, and so on.

This attitude will _create_ ninjas/rockstars/whatever, even if the original
notion isn't true. Folks who spend every waking hour thinking about and
learning about something are going to be better than the folks who don't do
that level of effort.

I agree that programming skill is going to shape itself into a bell curve, but
I would also argue that a bump exists in the 3rd or 4th standard deviation,
with all the folks who've been driven (for good or bad reasons) to
eat/drink/breathe programming.

The thrust of the article is that it's okay to be mediocre, and I agree, but I
don't think it's healthy to be satisfied with where you are in _any_ skill-
based craft. It's more healthy to be okay that you're not _already_ better
(I'm not a rockstar _yet_ ), but being okay with not _getting_ better is a
toxic thought.

~~~
gaius
_This attitude will create ninjas /rockstars/whatever, even if the original
notion isn't true. Folks who spend every waking hour thinking about and
learning about something are going to be better than the folks who don't do
that level of effort._

It will create people who believe themselves to be something special, sure,
but that's all you can say for certain. Where are the results that prove it is
deteministic? For every startup full of rockstars that succeeds, there are
1000 who worked just as hard and sunk without a trace.

~~~
diminoten2
One can say, with absolute and unwavering certainty based on what we know
about practice, that folks who spend every waking hour thinking about and
learning about some specific skill will tend to display a higher level of
competence than those who don't.

Obviously there will be folks who practice incorrectly, and there will be
folks who hit a skill ceiling, and there will be a myriad of folks who aren't
maximally benefitting from their practice for one reason or another, but if
you take a group of people who study and pit them against a group of people
who do not study, the group who studies will be more proficient at the given
task.

------
grandalf
There are different areas of skill.

Some people can refactor a messy chunk of code into something more organized.
Some can create a rough sketch of a large system that is well-organized and
loosely-coupled, others can optimize an algorithm for efficiency.

Some can write code that is easy to read and understand. And some can write
code that is extremely abstract and expressive.

It's rare to find all of these skills in one person. Depending on the project
goal, some of the above are crucial and some are nice to have.

All of the above can be learned, and for some experience is the best teacher,
while for others a CS background helps a lot.

------
kaitai
Last summer I went into a job interview and said "I'm not really a
programmer."

The next week I was hired to do Ruby on Rails work for a freelance contract.
(I'd been lured to the interview to talk about data analysis with R but they
needed a Rails person more.) Clearly the interviewers thought my level of
experience was fine.

I've got a PhD in mathematics and am no stranger to technical fields. I can't
believe I was "that woman" who said she wasn't a programmer. It really does
happen. My G-d, I'm a cliche.

------
kinduff
Very nice article. It reminds me to this quote from "Hackers and Painters" by
Paul Graham.

"In general, people outside some very demanding field don't realize the extent
to which success depends on constant (though often unconscious) effort. For
example, most people seem to consider the ability to draw as some kind of
innate quality, like being tall. In fact, most people who "can draw" like
drawing, and have spent many hours doing it; that's why they're good at it."

------
kazinator
Programming benefits from dogged perseverance. If you have lots this trait, it
can overcome other shortcomings.

It also benefits from being thorough and detailed: analyzing all the cases
that may occur, forming all the conceivable hypotheses and so on.

It doesn't matter if it takes you five hours of hacking on something to
finally see a solution that some brilliant programmer came to in 45 minutes of
hacking.

Maybe it was luck; his or her brain generated some spontaneous idea which
revealed some aspect on the problem resulting in a breakthrough, while you
were methodically working through various hypotheses (including the boring
ones).

Brilliance will lose in the long run to dogged perseverance and thoroughness.

Brilliance has an advantage in dealing with badly structured programs; the
brilliant mind has a great memory and can simultaneously hold a lot of the
program in consideration: for example, to visualize a complicated run-time
interaction between numerous scattered pieces of code. The more brilliant mind
can handle a larger instance of this sort of thing than a less brilliant mind.
But there is a limitation on it. It's kind of like being muscular. It's
_impressive_ that you can bench 300 pounds, but it's useless in the big
picture where we might need to lift 30,000 pounds. And where we therefore use
a machine to do it, and that machine can be easily operated by a "90 pound
weakling".

We can erase the advantage of the brilliant mind by not structuring the code
such that only the most brilliant minds can visualize how some scenario arises
in order to identify a problem. And we can also use tools: tool to help us
visualize, analyze, validate, and so on.

Where we ultimately need brilliance is in forming _ideas_. Someone who comes
up with great product ideas (and ones that sell, too) cannot be replaced by a
machine, or by someone who just has perseverance and thoroughness in the face
of details.

~~~
krylon
Thank you!

This is pretty much what I wanted to say, but I only realized this when
reading your comment.

------
bad_user
What I find fascinating is the ability of software developers to work against
their own interest.

> _The US Bureau of Labor Statistics estimates that by 2020 there will be a
> 1.5 million programming job gap, which means there will be that many jobs
> unfilled. That 's in five years. The EU has published similar numbers, 1.2
> million in 2018—three years. That means we need to be doing something to get
> more people into our industry._

There you have it. That's how many of us are thinking, while at the same time
we suffer from ageism, wage-fixing, working overtime and being seriously
underpaid in general for the value that we provide to our employers. How can
we be so stupid as to care about programming jobs being filled? Is it any
wonder that we end up being abused?

~~~
srryaccntcrtn
A typical useful idiot grade remark by the speaker. Actually we as software
devs have to ensure that the supply of talent in our field is somewhat
balanced to our interests to protect our financial positions and prospects
from degrading due to the influx of new devs on the job market.

Supply and demand baby!

------
retrogradeorbit
I think Jacob is engaging in sloppy thinking. Like everything relating to
biology (in particular, human beings) there are two components. One is nature.
One is nurture. Every single activity in life will require both components to
come together. Everyone will have different aspects and amounts of these
components.

It reminds me of Jane Elliot's teachings. It's not that 'there is no
difference'. There is definitely a difference. The truth is that difference is
good. It's good that we have both good and bad programmers. It's good that
some people are rockstars, and others have to struggle. Diversity is good.

The problem is not "the 10x myth". I don't think its a myth. I think there are
10x althletes, 10x doctors, 10x engineers. Pick any field and the spread
between the best and worst performers will be enormous.

The real problem is some people think that because they are a better
programmer (or a better pianist, or athlete, or engineer, or doctor) they are
better people. That their life somehow has greater meaning. This is the myth
that needs to be debunked. Being a 10x programmer does not make you a better
person. In ANY way, what-so-ever. It just makes you a better programmer.

What makes you a better person, in my opinion, is how compassionate you are,
how much you care for the less fortunate and how much you work to make this
world a better place for everyone.

~~~
NhanH
The problem about 10x myth seems to be the comparison point that each of us is
making: is it the best vs worst, best vs average, or a binary threshold
between the best vs everyone else? And then even defining the "worst" seems to
be very hard for a field like programming.

And a bit of a tangent, I don't disagree with your last statement in the
specific. But in principle, that's a very dangerous statement to make: if
you're living within the moral constraint of a society, there really should
NOT be any criteria that define a human to be a better or worse person.

~~~
retrogradeorbit
I think we probably agree more than disagree, but I do disagree with your last
sentence. This right and wrong is above the 'moral constraint of a society'. A
whole society can believe something is right, and another thing is wrong, but
that does not make them right and wrong. For example, a majority of a society
may believe that honour killings are right. But they are not.

It's not some moral relativism that depends on the context. Right and wrong
are absolutes, and can be objectively appraised. And here's the metric:
Suffering. Right actions are those actions that lead to a reduction in the
suffering of living things. Both in others and in ourselves. Wrong actions are
those actions that lead to an increase in suffering in ourselves or others.

This is how we can appraise our actions. This is totally off topic, and I'm
definitely showing my Buddhist beliefs, but I think the attitude shown by your
last sentence is held by a lot of people in society. And I think it is also
muddled thinking. This kind of 'moral relativity' is actually a slippery slope
and has been used to justify all manner of human atrocities through history.

------
current_call
_If we embrace this idea that "it's cool to be okay at these skills"—that
being average is fine—it will make programming less intimidating for
newcomers._

 _If we embrace this idea that "it's cool to be okay at these skills"—that
being average is fine—it will make art less intimidating for newcomers._

 _If we embrace this idea that "it's cool to be okay at these skills"—that
being average is fine—it will make music less intimidating for newcomers._

 _If we embrace this idea that "it's cool to be okay at these skills"—that
being average is fine—it will make writing less intimidating for newcomers._

 _If we embrace this idea that "it's cool to be okay at these skills"—that
being average is fine—it will make football less intimidating for newcomers._

 _If we embrace this idea that "it's cool to be okay at these skills"—that
being average is fine—it will make architecture less intimidating for
newcomers._

There's nothing wrong with a skill that takes time and effort to become good
at, and there's no reason to cater to people who aren't at least novices.
Well, not unless you're trying to artificially inflate the labor pool so you
can pay programmers less.

------
makeitsuckless
I know I'm not the only one old enough to remember that we already tried to
apply this argument in the late 90s?

That left us with countless completely incompetent programmers, most of whom
left the industry after Y2K and the burst of the bubble. Those who stuck
around now largely make up the bulk unemployed IT workers whining about how
there can not possibly be any shortage because nobody wants to hire them.

We've already put the talentless to work in massive numbers, and not only did
we as an industry pay the price, it didn't do the por sods much good either.

Also, all of these arguments about mediocre programmes, 10x programmers,
gender based discrimination etcetera only serves to distract and intimidate,
because they have nothing to do with the fundamental question. Nobody is
arguing that a having a talent for something is the only thing that matters
when it comes to how good a programmer you become, or that it has anything to
do with gender.

Bringing it up only serves to pre-emptively make anybody trying to make a
counterargument look like an arrogant, sexist douche. My instinct tells me
that people trying to make a point that way already know they're wrong.

------
dataker
One the main issues with such collectivist argument is that programming is
more than solely 'programming'.

A great developer innovates, organizes, leads and motivates other programmers
in a way others are not able to do. Kaplan-Moss is a perfect example of it.

For example, maybe, it's true that anyone is able to build a CRUD website.

However, maybe, not everyone is able to start and manage an open-source
project.

~~~
Kurtz79
Not really, programming is 'solely' programming, as in the ability to generate
code that is reliable, readable, well organized, efficient, etc... .

What you are talking about is programmers that in addition to their technical
skills have also leadership and management capabilities, which make them
absolutely invaluable in a company, but not necessarily more skilled or
"talented" at programming than others.

------
rayiner
In this topic: people demonstrate they don't know what "bimodal" means. A
normal distribution of programming talent doesn't preclude the existence of
"10x" programmers.

------
lessthunk
I think the article is a bit simplistic;

There are different types of skills -- and if you can combine them, you are
the 10 to 100x times person;

Understand the business problem, and then have enough tech skill to solve it
and you can move mountains. Most managers know neither the business domain,
nor the technology, which makes it even harder.

Like in everything in life, 90 to 95% is BS.

------
tmsh
I think it comes down to whether you have high standards. Or were taught with
high standards. Or were mentored with high standards. And whether as you grow
you have the luxury and the persistence to keep them up. If you do, you fold
in stronger and stronger building blocks that over time 'scale' and allow one
to move effectively and often more quickly. If you could measure it, it would
have to do with the density of the parent tree nodes within which you approach
problems. Some people are lucky to have grown under rigorous conditions while
yet still being exploratory and developing breadth.

If 'talent' is a function of tree node growth though, talent is not going to
be bimodal. It's going to be unimodal with some long-tail bias because of the
rewards theoretically of being really good at programming.

------
bhauer
Subscriber-only content. Does anyone feel a bit guilty for reading it without
a subscription?

~~~
corbet
Indeed, I hope you feel overwhelmed by the sort of guilt that only purchasing
a subscription can dispel. Inspiring such feelings was my motivation for
posting the link in the first place :)

(I'm the lead editor of LWN.net).

~~~
bshimmin
Is there anything that can be done to make LWN.net look a bit nicer? There's
often very good and interesting content on there - for which I'm grateful! -
but the presentation really is rather a throwback to the pre-CSS days.

~~~
corbet
There's a new site design in the works; subscribers can play with it now. It
improves the situation in a lot of ways, especially on small screens. But the
text-centric nature of the site is not going to change.

------
sz4kerto
What is programming talent? There are many different jobs where one writes
code, but they're very different. A very big part of a developer's success
depends on whether and how they can navigate the business domain they're in.

------
golemotron
> This belief that programming ability fits into a bi-modal distribution (i.e.
> U-shaped) is both "dangerous and a myth". This myth sets up a world where
> you can only program if you are a rock star or a ninja. It is actively
> harmful in that is keeping people from learning programming, driving people
> out of programming, and it is preventing "most of the growth and the
> improvement we'd like to see", he said to a big round of applause.

How does he know that bi-modality is not true? These are questions we should
ask and study rather than things we should just assume are myths. Ignorance is
not the answer.

~~~
leni536
Especially if one don't even define what is the exact quantity measured. IQ is
a normal distribution by definition, (IQ-100)^(1/3) is "bi-modal", it's just a
simple transformation and both quantity correlates (supposedly) with the vague
term "intelligence".

The question is not in bi-modality though, it's whether you can go from the
left side to the right or the middle over time or you should have been born as
a rock star.

------
forloop
The video:
[https://www.youtube.com/watch?v=hIJdFxYlEKE](https://www.youtube.com/watch?v=hIJdFxYlEKE)

YouTube doesn't have playback at 3x speed, unfortunately.

~~~
thoman23
Open dev tools console:

document.getElementsByTagName("video")[0].playbackRate = 3.0;

~~~
forloop
TY!

Turned it into a bookmarklet†.

† javascript:document.getElementsByTagName("video")[0].playbackRate = 3.0;

------
vpeters25
> The truth is that programming isn't a passion or a talent, it is just a
> bunch of skills that can be learned

I think people who makes these statements are usually misguided by their lack
of perspective: talented people have a hard time understanding how someone
else can't do it when "it's so easy"

One example of this is Bill Gates driving Microsoft to commoditize programming
("I can do it, it's easy, therefore anybody should be able to do it").

------
karmacondon
Programming talent isn't bimodal, in fact it isn't a question of traditional
talent at all.

There are only two levels of programming ability: "Bad" and "Good Enough". In
all but the rarest of edge cases, everything else is a matter of preference.
You think that someone's code is elegant, simple, clean, optimized, etc?
That's great, but only other programmers might care about those things. The
only question that the majority of people care about is, "Does it work?"

Obviously code can be written so poorly that it causes noticeable performance
problems, or doesn't work at a scale past the initial requirements. But that
falls under the "Does it work?" question. Basically if I'm using it and it
isn't annoyingly slow, whoever wrote it was "Good Enough". I don't care if
they were a l33t 10X rock star ninja or some guy who just finished a
"$language For Dummies" book.

It is genuinely cool to see code that is well designed and well written. And
doing that consistently does require the innate talent of a special mind. But
let's not confuse elegance with doing the job. Doing the day in day out work
of programming is like being a journalist: the most important thing is getting
the facts straight, not writing something pretty. The truly talented can do it
with the rhetorical flourish of a poet, which is awesome, but not required.

All that most people ask of code is that it's good enough to do whatever it's
supposed to do. If we want to turn it into a poetry contest then it's
definitely a bimodal distribution, and most of us will end up on the wrong end
of the curve.

~~~
makeitsuckless
Your argument falls apart completely when you take the long term lifecycle of
the code into account. Which is exactly why we keep having these discussions.

And by the time we pay the price _everybody_ cares. Of course, by then it's
way too late to start caring about such esoteric programmer obsessions as
elegant, simple, clean, and most of all: open to change.

Yes, all people ask is code that is good enough to do whatever it's supposed
to do. They just have no fucking clue of what it is that the code is supposed
to be able to do _besides_ satisfying their short term needs.

------
platz
"Formal logical proofs, and therefore programs – formal logical proofs that
particular computations are possible, expressed in a formal system called a
programming language – are utterly meaningless. To write a computer program
you have to come to terms with this, to accept that whatever you might want
the program to mean, the machine will blindly follow its meaningless rules and
come to some meaningless conclusion. In the test the consistent group showed a
pre-acceptance of this fact: they are capable of seeing mathematical
calculation problems in terms of rules, and can follow those rules wheresoever
they may lead. The inconsistent group, on the other hand, looks for meaning
where it is not. The blank group knows that it is looking at meaninglessness,
and refuses to deal with it"

[http://blog.codinghorror.com/separating-programming-sheep-
fr...](http://blog.codinghorror.com/separating-programming-sheep-from-non-
programming-goats/)

[http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf](http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf)

~~~
vectorpush
The findings of this study have been formally retracted by the author.

[http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hu...](http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hump_retraction.pdf)

~~~
platz
Well I won't be linking that anymore. Anyways, I was really more interested in
the little narrative observation above than the numerical results of the
study.

~~~
mannykannot
The quote reminded me of a study I read about a year ago, in which the
problem-solving skills of toddlers and chimps were compared. The toddlers
generally did better, except in one regard: when shown how to do something,
but with some pretty obviously irrelevant steps included, the chimps were
quicker and more likely to drop the pointless steps. At the time, I thought
that might be explained by a human predisposition to pay attention to
authority, but, in the light of that quote, perhaps it is (also) a
predisposition to formal / abstract thinking? Furthermore (to make a wild
speculative leap) perhaps it is this predisposition that is actually behind
the phenomena that Chomsky thinks are evidence for an innate universal
grammar?

------
logicallee
>But that would mean that programming skill is somehow distributed on a
U-shaped curve. Most people are at one end or the other, which doesn't make
much sense.

But this is exactly the case! It's why Fizz Buzz exists: to determine if
you're on the left leg or the right of the U-curve. (Or similar curve wherein
_people "suck at programming" or that they "rock at programming", without
leaving any room for those in between. Everyone is either an amazing
programmer or "a worthless use of a seat"_ [in a programming job]).

Why can't we accept that this is the nature of progrmaming?

Jobs wasn't a coder, and was on the left side of the U. Wozniak was and was on
the right side.

Brian Chesky (airbnb co-founder) can't code, is on the left side of the U.
Nathan Blecharczyk (another airbnb co-founder) can.

There is nothing exceptional about this distribution. You can have a ton of
vision and product input, design input (as Brian did) without being on the
right side of the U as a coder yourself.

On the other hand, perhaps all coders on the right side of the U are all
awesome, which is why they command six figure salaries sooner out of college
than other professions take to get a terminal degree in their field.

~~~
whyaduck
FizzBuzz is a test, not the results. If you can point to a study that has
administered it to a well selected group representative of professional
software engineers that displays a bi-modal distribution, then I'll accept
that as evidence. Until then, it's just anecdotal data about the quality of a
self-selected group attempting to get a well paid job.

~~~
logicallee
Fizz Buzz is a pass/fail test that wouldn't even exist if the pool being
tested weren't bimodal. Why would anyone administer the Fizz Buzz test to a
normal distribution of programming skills, for example? (I mean
[https://www.google.com/search?q=normal+distribution](https://www.google.com/search?q=normal+distribution))

It would make no sense - below what part of the normal curve of programmers
would you put someone who failed at FizzBuzz (cannot code it)?

In my interpretation it's because programming skill doesn't follow a normal
(bell-shaped) distribution, but is bimodal. Which is why Fizz Buzz exists, to
tell you quickly which pool (left or right) your candidate is from.

Either that or we have a completely different interpretation of why Fizz Buzz
exists or what it means. Why do you think it exists?

------
vbezhenar
IMO it's not a talent. It's a result of thousands of hours of work. I learned
programming at 12 years. I programmed a lot. I didn't have a computer and I
was programming in sheets of paper (computer was in school and I didn't always
had access to it). I wrote by own object-oriented GUI library in sheets of
paper and that library was never written in computer but it was in my head and
I learned a lot while thinking about it and its design. There was time when I
was spending 10-12 hours programming or reading programming books.

I wouldn't call myself talented programmer. I spent a lot of time to learn how
to write good enough code and be productive.

What I had is a passion to program. I never programmed because I had to force
myself. I enjoyed it. It's a beautiful art. That beauty forced by to program.
And I still find that beauty in programs.

Unfortunately I don't know how to learn others to enjoy programming. I saw a
lot of programmers and most of them didn't really like their job, they just
did it because they went to CS faculty after school and programming is paid
well enough.

------
random854
Based on what I've seen, anyone can write code, just as anyone can learn math
or write a story. Further, anyone who devotes time and effort to writing code
(or doing math or writing a story), who immerses themselves in it, who learns
and practices, can write code _well._ Thing is, most people aren't motivated
to do everything well. People find enjoyment in different ways; some through
working with their hands, some through solving puzzles, some through talking
to people. I wouldn't say this is purely natural (I didn't discover
programming until later in life thus I'm nowhere near how skilled I'd be if I
started at 10, although once I knew what it was I knew I would enjoy it), but
I wouldn't say it's purely up to environment either. Anecdote: I introduced a
friend of mine to programming recently. He can do it, and he's not bad at all,
but he'd much rather be face-to-face with someone than staring at a screen for
hours.

So, anyone can become a good programmer, but most won't want to be.

------
christianbryant
As Linus Torvalds said, "Talk is cheap. Show me the code." [0]

Not to belittle the truisms in the article, but this is ultimately what it
should come down to. Show me your code and your project working.

[0] [http://lkml.org/lkml/2000/8/25/132](http://lkml.org/lkml/2000/8/25/132)

------
mikecmpbll
Yet more programmer/tech industry denigration propped up by completely
unproven assertions.

Firstly most of this is based on the idea that as a programmer you are only
either great or shit, and that this is somehow a problem of the industry
rather than just being something entirely human and normal in ANY WALK OF LIFE
(the best and the rest).

Secondly, there's this awful assertion that this purported industry problem
has resulted in a less diverse industry. (What does that even mean, other
ethnicities & women can't handle pressure as well as white men?)

    
    
      But imagine how frustrating it must be to be a woman with a decade of experience
      and have someone assume that she doesn't know what she is talking about.
    

^ This just comes out of nowhere, someone assuming that a woman programmer
"doesn't know what she is talking about" is not related to any point he's made
previously.

~~~
sandyarmstrong
It's not out of nowhere. The context is very clear in the video, and in the
article it's just a few paragraphs earlier:

> When we see someone who does not look like one of those three men, we assume
> they are not a real programmer, he said. Almost all of the women he knows in
> the industry have a story about someone assuming they aren't a programmer.
> He talked to multiple women attending PyCon 2015 who were asked which guy
> they are there with—the only reason they would come is because their
> partner, the man, is the programmer. "If you're a dude, has anyone ever
> asked you that?"

------
army
The original version of the "10x" idea didn't require the productivity
distribution to be bimodal - it could be a bell curve or skewed bell curve
with high variance. I think it's contextual as well - if you're working on a
project that's just at the edge of your present abilities, your productivity
is going to be pretty marginal compared to someone who's done it before and
has strong aptitude at it.

I think it's silly to simply sort programmers into two buckets.

It does make a lot of sense though to try to attract and retain good
programmers though - having a programmer who's at the 75th percentile of
productivity instead of the 50th percentile is going to give you a big boost
in productivity if productivity is high variance. It also makes sense to try
to match programmers to projects that they have good aptitude and motivation
for.

------
vfrogger
I took one programming class my Freshman year in college, and dropped Computer
Science as my major because even though it was an Intro to Programming class,
I felt like I was the only person in the computer lab that was actually
programming for the first time.

It infuriated me working for half a day on an assignment and then watching
these other kids come into the lab, knock out the assignment in 20 minutes and
laugh about how easy the assignment was.

After college, I taught myself how to build websites, which led to javascript,
then PHP, then databases. Teaching myself on real world projects was enjoyable
because there was no comparison to anyone next to me, it was just me trying to
figure out how to get something to work. And when it worked, that felt great,
not horrible because it took me 10 times as long as someone else.

------
perlgeek
One thing missing from the whole bimodal vs. normal distribution debate is:
what is the population that you use as a base?

If you take all humans as the base, the vast majority for any skill that isn't
nearly universal is clustered at the zero. Of the 9 billion people on earth,
nearly nobody can write programs to any meaningful degree, or play the piano
to any meaningful degree, or build a telescope, or a wrist watch, or whatever.

So I'd assume that programming ability distribution looks a bit like a normal
distribution centered at zero, and cut off at zero (no values for skills less
than zero).

Which, ironically, makes basically everybody who can write a single line of
code "above average". Which doesn't make them rock star programmers at all.

------
kfk
I think in small organization you might need a lot of talent, but once
organizations (or projects) get bigger, you need process over talent and that,
well, also means good management. There are things you can do with a small
group and things you can only do with a bigger group. I guess Django is at a
point where it's big enough that it can take advantage also from the less
talented coders. Maybe, and I am wild guessing here, part of the issue comes
when startups grow and still look for the 0.1% talents, when at that size that
can easily live with the 40-50%.

------
notacoward
The illusion of a U-shaped talent curve is just that - an illusion.
Specifically, it's an illusion brought on by selection bias. We _see_ more of
the people beyond a particular point in the curve. Maybe we even see them
because they're exponentially more productive than people further back, but at
most that means the _work product_ distribution is bimodal. The _skill_ or
_talent_ distributions surely have a bump or two here and there, but remain
basically normal.

------
BurningFrog
After a few decades programming professionally I have yet to encounter the
idea of a U shaped talent curve where most people are either geniuses or
useless. Does anyone actually think that?

Nor have I been on any team since arriving to California that had a majority
of young white men. That actors portraying Mark Zuckerberg look like him is
hardly surprising or a good scientific sample. I didn't read past that
section.

------
KedarMhaswade
I think there is a question of progression through your career as well. For
talented programmers, (I believe) it is less likely to feel 'stuck' at some
point. Over the years, they can handle increasingly more complex challenges
with same relative ease. Others have to do significantly more efforts to
handle abstractions well enough to ensure 'cruising' along.

------
eranation
Saying that there is a programming skill is a little like saying that someone
has a "sports" skill. There are many different skills of programming that are
very different, and except some basic "can do fizzbuzz" level, there are miles
apart skillsets, where you can be great in one context but bad in another. a
few examples

\- fast hacking / programming contest / hackathon skills - write correct
solution fast, not caring about how the code looks or be read later. (great
for contests, bad if you do it also at work, code is read more than written
bla bla)

\- software engineering / organization skills - for 99% of enterprise software
development, and large chunk of CRUD based web development, you need to be
organized, and clean, there are no "algorithms" to implement, you just need to
have good concept of MVC, separation of concerns, write methods that do just
one thing, meaningful variable names. in these settings, most of the code you
write is simpler than even a fizzbuzz, you get data from a form, validate it,
save it, do some business logic, generate reports, that's it. This needs a
whole lot different skillset than what a "top talent X10 programmer" would
offer. This needs planning, design, patience, not trying to change the world,
being OK with writing Java annotations, being just a regular professional
software grunt.

\- Library and API designers - there is a great skillset of writing a library
that has self explanatory interface, good documentation, and is just a fun to
use. People who know how to build a DSL or an API that makes sense, is a whole
different skillset than the above 2, and a fizzbuzz test will not be the one
that will let that diamond shine in an interview.

Programming is not just one skillset just like "music" or "sports" or
"writing" is not a single skillset.

You can be a great comic actor but a lousy dramatic one, you can be a great
sports writer but never be able to get a novel published. you can be a great
golf player but never be able to win your 10 year old kid playing soccer no
matter what you try.

Perhaps FizzBuzz is the common denominator, e.g. you can say that if someone
can't play a C major chord on a piano, they are not going to be a pro
musician, but anything beyond that, anything that tries to test "programming
skill" beyond that level is not far from auditioning a violinist on a chelo
just because both have strings.

------
Geee
I'd say that the 'talent' of programming comes from the tenacity to handle all
kinds of bullshit and be able to adapt and survive in this environment. Just
setting up a Python environment on Windows is a nightmare, and most people
will just give up. Second part of the talent is the experience of how to
handle or avoid all the bullshit and get the work done.

------
SEJeff
A 10x programmer is one who teaches the rest of the team all of his skills,
not one who is necessarily better than everyone else.

------
gmrs
The creativity part of programming requires a good sense of usability, a good
sense of how to organize things nicely and those things require some sort
talent yes.

The same applies to language and grammatics. One thing is to write a phrase
well, other thing is to _transmit_ the right emotions with the phrase you
write.

------
trhway
by definition, most of us working in this crowded industry are mediocrity. And
even if somebody is a very talented programmer (say like me :) the system will
make sure that it doesn't matter in the end.

[http://en.wikipedia.org/wiki/Barge_Haulers_on_the_Volga](http://en.wikipedia.org/wiki/Barge_Haulers_on_the_Volga)
(depicts typical implementation of SCRUM process with 1-day long sprints)

(until of course, one is so "talented" that s/he made onto the barge as a
foreman or better - owns the barge, though it usually requires completely
different from programming talents)

------
parsnips
Poor analogy follows: Programming ability is like chess ability. The skill lay
on a regular distribution, but the game that 1900 players play (top 5%) is
much different than the mean (~1400).

------
laurentoget
the comments on this are a fascinating read. who knew programmers had such a
deep belief that their ability is rooted in almost magical notions of talent,
art, creativity and is not just another skill you can learn.

it is definitely a satisfying notion to think of your activity as a
consequence of a god given gift, rather than just a job, but as engineers i
think we should do better than relying on anecdotes and beliefs to understand
what it is we are doing it.

------
PaulHoule
I think one difference between this lady who built a complex system and "a
programmer" is that the typical professional programmer works on a legacy
system.

------
gyardley
The set of people who believe programming ability is bimodal and the set of
people who believe they're in the higher of the two modes is pretty much
identical.

------
aidenn0
I think the bimodal theory exists because we merely haven't learned to teach
people without exceptional talent programming.

------
platz
maybe she said she "was not really a programmer" because she didn't want to be
associated with one (consciously or not). I have heard that sometimes women
view programming as a low-status job i.e. akin to labor.

------
bhz
It's not bimodal, because there there are 10 different types of people.

~~~
mark-r
I've heard that joke before. You did _not_ do it justice.

------
bernardlunn
My experience totally contradicts this. I am a biz guy but I have been
privileged to work with a handful (literally, about 5) developers who are not
just 10x better than average but 50x or 100x better. Its like denying Black
Swans - rare is different from non-existant.

~~~
piva00
I won't argue against that but I have a problem with biz guys who try to
evaluate what kind of a developer someone is.

I'll not judge that you don't have knowledge about the field or about code, so
don't take this personally, but in my experience I've seen far too often some
biz guys praise developers who are sloppy, developers who code unmaintainable
stuff and which biz guys loves because they're always delivering, much of the
time ahead of the schedule.

But when you tried to bring a team around what they built it was almost always
code that was not able to be maintained by a team. When the original developer
was long gone you had a team of 5 pretty good developers trying to figure what
the hell is happening with that code, and biz guys demanding to change the
team because the 50x developer had done so much in less time.

As I said, I'm not saying this personally as I don't know your background but
if we are throwing anecdotes that's one I have from the top of my head, some
praised hyper-productive coders are that way because they take shortcuts and
some don't even know they've done it. I just think that the occurrence of
really good and smart and productive developers is so low that I've yet to
remember more than one that I've worked with in the last 10 years, I've worked
with great people but I can remember only one who I can put in the bucket with
a "great soft and hard skills, hyper productive and smart" label.

------
chetanahuja
My wife and I volunteer teaching "programming" to my son's second grade class
once a week. It's actually a mixed first/second grade room so half the kids in
the class are first graders. I've been teaching them writing simple algorithms
and games in scratch (scratch.mit.edu) and studio.code.org.

These kids are young enough that almost nobody had any exposure to "coding" or
algorithmic thinking before this. It's about 30 kids. Here's what I've
observed (Yes it's anecdata... but I'm reporting my own impressions here):

There are about 6 kids who're pretty quick on most of the assignments...
evenly divided between 3 girls and 3 boys... then there's about 15-20 kids who
are more or less similar in aptitude. The top 5-6 programming kids are also
the kids who I feel have the most advanced verbal skills (just from speaking
with them). I've been told by the class teacher that two of these kids are
advanced math learners but the others are good students but not advanced
beyond grade level.

The more surprising part is the bulge of 15-20 students in the middle. That's
a far bigger number than what I expected who regularly complete challenges
correctly and within the time given. Many of these kids are not particularly
top level math students. Most seem to have good verbal skills but nothing
exceptional. Most surprisingly, many of these kids are first graders. Once I
saw this in the first few classes, I significantly raised the level of
challenges I was giving them. And they kept working them out. It's fair to say
that I was pleasantly surprised.

Yes it's not a particularly strong scientific study but I'm here to say that
there's absolutely no way you can convince me that Programming ability is some
genetic trait with a bimodal distribution... at least not in the absence of
hard scientific data. The one study that has polluted our discourse for many
years (because Jeff Atwood trumpeted it on his blog) was retracted in dramatic
fashion by it's own lead author:

[http://retractionwatch.com/2014/07/18/the-camel-doesnt-
have-...](http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-two-
humps-programming-aptitude-test-canned-for-overzealous-conclusion/)

And to complete my story - Yes, there are 2 kids who don't particularly enjoy
this class at all. They do seem to be behind the rest of the class in general
scholastic aptitude though by no means "stupid"... my wife spent an extra hour
with them separately and they thrived under a higher level of direct
attention. There are a handful of others who end up doing their challenges
slower than others. One of the most amazing and heartening things I've seen is
that the kids who finish the challenges are spontaneously going to the kids
who haven't and have been helping them out. And in the end, each and every kid
has finished all the challenges we've given them

------
bitL
Tyranny of mediocrity commences...

------
jerf
There's a lot of scenarios that could produce what we witness, and eliminating
one doesn't prove which of the others it is.

It could be the case that programming talent is bi-modal or multimodal, but
each mode is itself a normal distribution. There would be a "talent" involved,
but it would still produce a normal distribution once you cut the bottom off.
This is suggested by such things as the bimodal distribution on the handful of
peer-reviewed papers that at least opened the question about whether incoming
freshman could be sorted into "those who could get it" and "those who can't"
buckets by a simple multiple choice question at the beginning of the test. (I
do not claim they have solved the problem, but it is an interesting data
point. This is that paper that was _extremely_ widely misunderstood by
professional programmers as being a test that required the students to guess
in advance how things like "equality" worked in programming languages, when in
fact it wasn't about being "right" about programming languages but about being
able to form a _consistent_ theory about how such things might work.)

It may be the case that talent is single-mode normally distributed, but
there's also a threshold necessary to function, which can be at any arbitrary
point along the curve; I'd suggest evidence would suggest it's certainly above
the average as with all due respect to my fellow humans it does not strike me
as the case that more than half of the human race can simply become
professional programmers. (This is less elitist than it sounds, because in
many cases supply & demand is such that only the best can become professionals
anyhow, and that's not just "NBA basketball players", it's even things like
music composers or painters. If you are a 50%-th percentile composer, do not
try to make a career out of it. I say this as one who has faced down this
choice personally.) The resulting truncated-normal distribution of talent in
the professional space would have a lot of people piled up on the bottom,
being just barely able to cross over the talent bar, and then a long-tail
effect where extremes would be more likely than you'd naively expect. Further,
courtesy of the Central Limit Theorum, as this initially non-normal
distribution of talent went through the usual random vagueries of life and
professional career, it would be the case that the curve overall would become
more normal, but would be quite likely to retain the longer tail and never be
quite normal. This is suggested by the fact that this rather does sound like
the programming world we live in.

Further if we're going to go all social-engineering on the question, I'm not
particularly interested in telling people pretty lies to make them feel good,
or worse, make _ourselves_ feel good about how good a person we are, while
sucking them in to a career that does not suit them. _If_ talent exists and
matters, then it behooves us to _say so_ and give people the ability to
examine themselves with eyes open and ask if this is the right thing for them,
or if they should pursue another career which they may find more satisfying.
There is, of course, a lot of room for "average programmers", almost by
definition, and "average programmer" already likely entails "above average
talent when the whole population is considered".

------
michaelochurch
The "10x" effect is real (not a "myth") but it has more to do with skills and
exposure than innate talent. (It's also context-specific. I'm a 10x when I get
to pick the tools, but a sub-1x on enterprise Java because I just can't bring
myself to give a fuck about some Spring/Hibernate/POJO legacy mess.) That's
what missed in this conversation. Yes, those mediocre Java programmers
(CommodityScrumDrones) really are a drag, but it's not low IQ that has made
them what they are, and they're not genetically destined to remain that way.
That aspect of a person can change, and quickly.

At any rate, I've met plenty of high-IQ people who are just awful programmers.
Smart as hell, but really bad at writing code. I think that attitude is a
major factor. If you think programming is important and genuinely want to
learn it (and not just "good enough to get a job") then I think it's quite
possible for a lot of people to learn how to do it well enough.

Innate talent might matter at the extreme upper end of competitive
programming. Just as most people can run a marathon with enough work, but very
few will ever get below 3:00, I'd believe that the percentage of people who
can reach the top in programming competitions is smaller than the percentage
who can program adequately. So there's probably a talent ceiling there, just
as there is in athletics. But real programming is more cooperative than
competitive and there are plenty of factors (especially design sense and
cross-domain knowledge) that matter in the real world more than innate talent.

Programming has a steep learning curve, but what's missed is that a steep
learning curve is _a good thing_. The 10x effect exists because it's possible
(especially in the early stages) to improve your own effectiveness by 20, 50,
or even 100+ percent per year... and one becomes a true 10x-er not based on
in-born talent but by having several 1.5x growth years in a row.

