
The Programming Talent Myth (2015) - vanni
https://lwn.net/Articles/641779/
======
EpicEng
> > The truth is that programming isn't a passion or a talent, it is just a
> bunch of skills that can be learned.

This may be true if your definition of programming is the literal act of
writing code / recalling syntax, and learning new tools. Of course, that's not
really what programming is. That's the easy part.

Programming is about problem solving, code is simply the tool. Critical
thinking/problem solving ability, the ability to think in abstractions, the
ability to hold a large amount of information in your head all at once, etc.
are all skills, and not skills that the majority of people are particularly
good at.

We wouldn't judge a carpenter on e.g. his/her ability to use a saw, or a EE on
their ability to use a scope. I never understood why so many put so much
emphasis on the tools a software dev knows.

~~~
Pigo
I do believe these skills can be learned, but it's the enjoyment I derive from
these things that I believe is the difference between some people and I. When
I was in junior high I would do various logic problems for fun. I asked for
nothing but a TI-85 for my birthday one year. There probably are people who
are better than me at coding who hate the work. But I've hated every job I had
until someone started paying me to sit, put on headphones, and solve problems
with code. I go home with a sense of satisfaction, whether it's a skill,
talent, passion is interesting but doesn't matter to me really.

~~~
aidenn0
After (as an adult) watching kids develop, there is a huge positive feedback
loop for various abilities.

When you are slightly better or faster or just find doing it (whatever "it"
is) more rewarding compared to your peers, then it takes lower effort to get
the same reward. This means you are more likely to spend more time doing it.
This means that after a while you have more practice than your peers, so the
difference in ability is amplified. Now various grownups around you notice and
complement you on it, get you lessons to do it better, provide you with
supplies, &c. and the difference grows.

By the time you are looking at teenagers, it's hard to tell how much of the
difference stems from natural ability, and how much of it is this snowball
effect.

------
thoughtsimple
I used to be a "rock star" programmer. I could run rings around my coworkers.
I wrote an embedded OS for running machine tools (I had help.) Back then, you
read books and memorized everything. I knew x86 assembly and could use a logic
analyzer to debug my code. This was in the 80's.

Now the amount of knowledge required to do even mundane tasks is an order of
magnitude more. No one can memorize all the APIs and frameworks needed to do
their jobs programming. I couldn't work without search. I don't memorize
anything anymore. I work on dozens of different technologies.

Basically, I've become a mediocre programmer at a large number of different
programming tasks where once I was expert at a very few. I'm the same person
but the meaning of what is a programmer has changed over time. I'm OK with
that.

~~~
buvanshak
>you read books and memorized everything.

Why did you have to memorize everything? I have also done x86 assembly. You
remember what you can. You look up the rest. Same today.

~~~
thoughtsimple
If you didn't develop in that timeframe you might not get the difference
between then and today. It takes forever to look things up so you end up
memorizing instead. And it isn't a big deal because the number of things
needed to be a successful software developer wasn't that great. To be
successful and finish projects more or less on time, memorization was needed.

Edit: For example, for a different project I knew the hex codes for every 8051
instruction. This was necessary to be successful debugging using a logic
analyzer. Looking up each op-code would be prohibitively slow.

~~~
AnIdiotOnTheNet
It's a caching problem. If memory access is slow you want to cache more, if
not then you don't bother. Things you use a lot will spend more time in the
cache, things you don't you'll have to keep retrieving from memory.

We really aren't as different from computers as we sometimes like to believe.

------
jasode
The 2 sides debating "talent" are always talking about 2 different things.

(#1) "talent" doesn't exist: knowledge and skills can be _learned_. No infant
comes out of the womb knowing 5 languages or physics equations or the syntax
of "printf("hello world")". Every single human who knows how to do something
well at one point in their life _did not know_ how to do it well. If one can
_improve_ by learning, it means talent doesn't exist. This aligns with Carol
Dweck's "growth mindset", the 10000 hours meme, self-improvement, etc. This
_internal_ perspective compares oneself at time_before vs time_after.

(#2) "talent" is a subjective _ranking_ of people's abilities: there are
people who are noticeably better at expressing their skills. E.g. NBA
basketball player Shaq O'Neal has spent more than 10,000 hours practicing free
throws with a dozen different coaches to achieve 52% success, but there's a
high school kid that can sink them at 80%. We can say the kid is "more
talented" at free throws. To say that "free throws" is a "learnable skill"
doesn't change anything about noticing the obvious difference in abilities. If
Person A _learns faster_ than Person B, that in itself is a talent. This
_external_ perspective compares people against other people.

People who hold meaning #1 vs people thinking of meaning #2 are having 2
different conversations. E.g. when companies say _" they are looking to hire
the most talented"_ (meaning #2), they are not talking about people who can
self-improve (meaning #1).

In this essay, Jacob Kaplan-Moss is talking about meaning #1. Yes, you can
read it and take all his advice to heart. However, you still have to
understand meaning #2 _to properly decode_ what others are talking about when
sports teams, music record labels, Hollywood, venture capitalists, and
startups all say they are _" looking for the best talent"_.

------
pmcollins
Lately, I've started thinking of programming as an art form. If you substitute
programming with music, how would you make all of these evaluations about the
craft and of its practicioners?

You may be hiring for guitarist and require at least 3 years experience
playing the guitar. J.S. Bach applies, but has never played the guitar. As an
industry, we typically wouldn't hire him due to lack of experience. Instead we
might hire some mediocre kid with the 3+ years experience and a history of
guitar lessons, even though after a 100 days on the job, J.S. Bach would have
been a mind blowing, mesmerizing guitar player, even if he was still a little
clumsy. And after a few years, he'd be more amazing still. Yet as an industry,
we focus the ability to be productive on day 10 instead of day 100 or 1000.
For long term positions. Why?

How would the software industry conduct an interview for a musician? We'd ask
you about all of the songs and instruments you've ever played and have you
talk about those experiences. We might ask a hypothetical question about what
if you had to play a certain piece, how would you handle it. Maybe we'd have
you answer some trick questions: "What are the frequencies of the first five
harmonic multiples of B right below middle C?"

I find this to be utter madness.

I think the best way to find a good (or potentially good) developer is to have
them do what we do in our jobs, which is, given some vague requirements and
some undefined period of time -- a few days or so -- write code to solve a
simple problem.

And I loved the part in the article about mediocrity. I've found the best
developers to be humble enough to constantly work on improving their craft.
So, don't reject a candidate because they appear to "lack confidence".

~~~
dajohnson89
will you pay me for those 3 days' work? and tbh it's not even the money, it's
my non-existent time.

~~~
pmcollins
No, but I will let you put what you created on GitHub. That becomes part of
your portfolio. Put a link to your GitHub account on your resume.

If you already have enough sample code, there may not be a need to provide
more.

~~~
humanrebar
I think your ideas are valid, but there are many potential candidates who
cannot do any of the above because they have full time jobs that prohibit open
source contributions without prior approval.

------
vinceguidry
While on the surface of it, sure, programming is a skill and not an innate
talent, it would be foolish to compare it to other career fields in that way.
You can go to school to learn how to be an architect, then go and get a job as
an architect and be immediately productive. You can go to school to learn how
to lay bricks, then go to a job site and immediately start building something.

You cannot go to school to learn how to be a programmer, and then expect
immediately to be productive at any arbitrary programming job, _unless you 're
a talented coder_. The education gap is too great. It's like medicine in which
you need a few years of residency before the medical field considers you fully
competent.

If you go to code school and learn Rails and React, then you can expect to be
somewhat immediately productive on a Rails / React project. You can't expect
anything out of them if it's not a Rails / React project. They may be able to
ramp up quickly, if they're talented. If they're not talented, then they won't
be able to, and the employer has to take the hit.

We will need a revolution in software development pedagogy before individual
aptitude stops mattering to employers. The state of education at the moment is
so bad that unschooled yet talented individuals can be much much better at
fulfilling business requirements than trained and educated professionals. Try
that with medicine!

~~~
lazyasciiart
> You can go to school to learn how to be an architect, then go and get a job
> as an architect and be immediately productive. You can go to school to learn
> how to lay bricks, then go to a job site and immediately start building
> something.

Do you actually know anyone who's worked in these fields? Because that's not
true. Wanna be an architect? Go to school + get 2 years of experience + take a
professional certification THEN you can be employed as an architect. Wanna lay
bricks? Get a job and you'll be taught there.

~~~
LyndsySimon
I've never laid brick, but I've been an electrician. Tradesmen are almost
never working independently, and certainly not when they are working in a
junior position. There's a lot of mentorship that goes on, and a lot of tribal
knowledge that's shared - things that are simply not written about.

When I started as an electrician, I knew a lot about electricity already. I've
always been a bit of a nerd and knew more about how electricity actually works
than many journeymen I met. I knew almost nothing about how to actually put
that into practice, though.

For example - when wiring an electrical outlet, you have to wrap the end of
the wire around a small screw. It's obvious enough that if you do it clockwise
tightening the screw holds the wire in place; if you do it counterclockwise,
tightening the screw moves the wire and makes life difficult. What _wasn 't_
obvious was that instead of taking a pair of needle-nosed pliers and bending
the wire to the right shape, there was a small hole in each side of a pair of
wire strippers that was exactly the right size to do it:
[http://www.kleintools.com/sites/all/product_assets/catalog_i...](http://www.kleintools.com/sites/all/product_assets/catalog_imagery/klein/11046.jpg)

Had the person I was working for not shown me that, I would have probably
never figured it out.

I think the role of a junior developer is very similar to that of an
apprentice electrician, in that the dev knows at least enough to implement
something on their own so long as they are given concrete tasks. A mid-level
dev is similar to the journeyman; they take a partially-defined task, break it
into well-defined chunks, and either implement or delegate. A senior dev is
the master electrician - they decide what tools to use, make the larger-scope
decisions on a project, etc.

This analogy breaks down once we start talking about software "engineers" or
"architects". I can't really think of anything I saw in the trades that maps
to it; it's more about identifying and anticipating important changes over
time and mitigating their costs.

------
adam-a
I think this is absolutely spot on. So many people put their programming
expertise or productivity down to some innate quality (that is apparently
overabundant in white men). To me it seems nearly every one of those rockstar
ninjas has also spent an enormous amount of time learning their trade -
usually a lot of time outside of formal school or a 9-5 job.

I think if there's one skill that might be innate and that helps people be
better at programming, it's patience. Learning to program and learning
programming tools is for most people a boring and extremely frustrating task.
You need patience to stick with it after spending two days solid trying to
debug some linker error or CSS bug or whatever esoteric programming issue you
inevitably have to deal with.

~~~
Will_Parker
> So many people put their programming expertise or productivity down to some
> innate quality

Yes. Some people (both as kids and adults) seem to be innately interested in
different kinds of activities. And it is perhaps impossible to separate talent
with passionate interest since B leads to A.

Take the kids from my tribe, extremely passionate about patterns and things
and systems and numbers and coding from early childhood, _despite_ concern
from parents and teachers, social ostracization, and efforts to limit computer
time. We also tend to acquire talent.

------
itamarst
If our starting point is that programming is mostly about skills, productivity
starts getting interesting - what does productivity mean?

My personal take is that it means solving _problems_ with less wasted effort.
Less code (a 0.1× programmer can solve problem with 10% of the code -
[https://codewithoutrules.com/2016/08/25/the-01x-programmer/](https://codewithoutrules.com/2016/08/25/the-01x-programmer/)),
but also by solving the right problem, and coming up with better solutions
([https://codewithoutrules.com/2017/10/04/technical-skills-
pro...](https://codewithoutrules.com/2017/10/04/technical-skills-
productive/)).

These are all skills you can learn. And I think focusing on learning
technologies obscures a lot of these skills, since they're about communication
and listening and project management.

For productivity in terms of technological knowledge I'm starting to think
that, since choosing _which_ tool is more important than _how_ to use it, a
better way to get better is to study case studies. Instead of trying to learn
"how can I use Mongo, how can I use PostgreSQL" you try to learn "when should
I use Mongo, when should I use PostgreSQL".

I'd love to hear about good sources of case studies.
[http://www.aosabook.org/en/index.html](http://www.aosabook.org/en/index.html)
is good, but doesn't cover kind of programming one would do at a company,
much.

~~~
iamcasen
This is exactly correct. In the past, I didn't consider myself an excellent
programmer, because I struggled to solve esoteric number permutation problems
and recursive graph search problems during whiteboard interviews. It seemed to
me that all my peers could do it, and they were getting good jobs for it.

Over time I learned that the real value comes from solving the right problems,
and recognizing wasted effort. It comes from architecting systems that are
easily maintainable. That's what makes money in the business.

Solving narrow, intensely interesting algorithms, is a rare case that is not
widely needed in the industry at large.

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

Aren't these all talents?

* learning many things

* learning difficult things

* recalling things you've learned when you need them

If something is a skill, one would expect all engineers to get better at it
with practice. But there are many abilities in engineers that don't seem to
work that way.

~~~
itamarst
Learning is a skill you can get better at, so it's just a dependency. Learning
is not an unchangeable talent. Some books that will help you learn better:

* Power of Intuition, about naturalistic decision making - [https://www.amazon.com/Power-Intuition-Feelings-Better-Decis...](https://www.amazon.com/Power-Intuition-Feelings-Better-Decisions/dp/0385502893/)

* How Learning Works - [https://www.amazon.com/How-Learning-Works-Research-Based-Pri...](https://www.amazon.com/How-Learning-Works-Research-Based-Principles/dp/0470484101) (my review: [https://codewithoutrules.com/2016/03/19/how-learning-works/](https://codewithoutrules.com/2016/03/19/how-learning-works/))

No doubt others can recommend more books.

~~~
toasterlovin
Wether or not a trait is mutable is different from the _degree_ to which that
trait is mutable. The distinction is important. Most breeds of dog can be
trained to learn some simple commands, but good luck getting some mutt from
the pound to herd sheep like a border collie.

Here's a video of border collies in action:
[https://www.youtube.com/watch?v=bpjP3mxv21s](https://www.youtube.com/watch?v=bpjP3mxv21s)

------
ionised
The only thing stopping someone becoming a programmer is a genuine interest in
the craft.

People generally don't get good at things they find boring.

We software developers are not special. We don't have something that non-
programmers lack, apart from maybe an inflated sense of self-worth.

------
pixelperfect
Does anyone else disagree with this article? There is talent for programming,
and that talent is correlated with IQ. A person with average or below average
IQ is very unlikely to excel as a programmer. There is a lot of academic
literature to back this up.

~~~
humanrebar
I think innate intelligence (whether measured by IQ or more qualitatively) is
a real thing. I think people implicitly live that way and organize society
that way.

I also think it's also considered a faux pas to actually say as much. People
tie respect, identity, and self worth into intelligence a lot. It's hard to
say Kimberly is smarter than David without offending people. Let alone to say
engineers are generally smarter than elevator operators (to pick a mostly
extinct job).

To some degree, all the interview hazing and discussion about "programming
talent" is all dancing around the West's inability to discuss intelligence
quantitatively and dispassionately.

To be fair, historically there has been a lot of sexism, racism, bigotry, and
pseudoscience tied up in the science of intelligence. I'm not sure how to get
society to re-approach the subject in a scientific, productive, and beneficial
way.

------
foreigner
The sentiments in this article are all very nice and progressive, but... have
you ever actually tried to interview people for a programming job? The simple
fact is that lots of people, perhaps most people who apply for jobs as
programmers, are completely helpless. They couldn't code their way out of a
paper bag. It's actually really depressing interviewing them, because you
_want_ them to be successful and yet most of them fail miserably at the most
basic things.

------
mistrial9
"programming" is not one thing.. most comments here fail to make even a basic
distinction between [ php forms developers; dev-ops Go pipeline builders; game
developers; domain-specific problem solvers] or other. Include in any of those
categories varying, more or less GUI design, more or less quality, more or
less efficient execution, more or less language mastery, more or less elegant
design.

Fish apparently are not good at describing water (!)

------
Adamantcheese
All I'm seeing here is that regardless of actual dictionary definition I still
won't be hired because of some vague opinionated definition in someone's head.

------
jbellis
I guess "programming talent is a normal distribution, not a U distribution"
doesn't make for as catchy a headline.

------
maerF0x0
> The US Bureau of Labor Statistics estimates that by 2020 there will be a 1.5
> million programming job gap

This makes me wonder 2 things

1) Why are we debating if we should keep the ~500k H1B visa holders around (of
course we should) and

2) Why don't we just train the top 10% (in ability + willingness) of the ~13M
unemployed people in this country?

~~~
humanrebar
a. There isn't really a gap. Employers are just slow to adjust to market rates
for quality engineers.

b. If engineer salaries went up to the market clearing rate, certain business
models that assume certain labor costs will become flawed

c. Who is going to pay for the training, especially in the case that all the
training doesn't actually end up making the candidate any _good_ at the job?

------
d0lph
I don't want to be mean but it looks like programming is both:

Talent:

1\. natural aptitude or skill.

Passion:

2\. strong and barely controllable emotion.

...

* an intense desire or enthusiasm for something.

...

~~~
humanrebar
Couldn't passion be innate as well? If you hate cilantro, you certainly won't
have a talent for eating cilantro.

(Also, passion in this context doesn't imply any sort of lack of control. You
don't program in the "throes of passion".)

~~~
d0lph
I've skipped meals programming, when things are interesting at least.

------
weirdmantis
It's like drawing. Sure maybe with a lot of effort anybody could draw a close
approximation of a good drawing but unless you are innately talented and
driven you will never be at a good enough level to make a great career at it.

------
israelsonbj
Why do computer science curriculums yield such a common thought toxicity? How
can they engage greater diversity and cultivate empathy, compassion, and give
students perspective to self-evaluate themselves?

------
draw_down
I understand why it's important to emphasize that programming skills can be
learned and that we aren't just a bunch of god-given talents. But how far are
we going to take this? Surely we can admit that for any given set of skills
some people are going to take to it more readily than others, and we can't
account for the difference simply in terms of amount of practice or hard work.
The top mathematicians or violin players or whatever in the world probably do
work harder than others in their field, but that's not the same as saying that
the difference between them and others is simply the amount of work/practice.

~~~
Zimahl
I think his point was that there's a bell curve and chasing this idea that
there is a load of top talent is absurd. There obviously are really great,
amazing developers out there, but there are magnitudes more 'mediocre'
developers that can still accomplish some really great, amazing products.

------
mnglkhn2
If you believe programming is not a talent then you won't complain when your
pay is not structured the same way that talent pay is.

