The Programming Talent Myth

HughPickens.com writes: Jake Edge writes at LWN.net that there is a myth that programming skill is somehow distributed on a U-shaped curve and that people either "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" which doesn't make much sense. If you could measure programming ability somehow, its curve would look like the normal distribution. According to Edge this belief that programming ability fits into a bi-modal distribution 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." 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 leading people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.

The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned. Programming isn't even one thing, though people talk about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed. 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 the bar for success is set "at okay, rather than exceptional", the bar seems a lot easier to clear for those new to the community. According to Edge the tech industry is rife with sexism, racism, homophobia, and discrimination and although it is a multi-faceted problem, the talent myth is part of the problem. "In our industry, we recast the talent myth as "the myth of the brilliant asshole", says Jacob Kaplan-Moss. "This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic. In reality, given the normal distribution, it's likely that these people aren't actually exceptional, but even if you grant that they are, how many developers does a 10x programmer have to drive away before it is a wash?"

Comments

Depends how you evaluate the curve

[xtal]

If you're looking for people who generate a profit from their time, the curve is almost certainly U-shaped based on my now not-so-light 30+ years in the trenches.

Why is this any different than the population of other skilled professionals? You will see the same curve for musicians, for example; it's not necessarily about being able to eventually get the skill, but it's about doing so in a reasonable efficient amount of time proportional to the effort expended.

In terms of actually learning, the guy probably has a point - eventually, I could learn to play the violin - but having tried, I'm never going to do it professionally.

Ask me to develop OMAP firmware or drivers, otoh..

Re:Depends how you evaluate the curve

[radtea]

If you're looking for people who generate a profit from their time, the curve is almost certainly U-shaped based on my now not-so-light 30+ years in the trenches.

The skill distribution doesn't have to be U-shaped to produce a U-shaped distribution. All there has to be is a threshold of skill that must be reached to perform effectively: http://www.tjradcliffe.com/?p=...

I liken this to a wall-climbing task in an obstacle course: some combination of height/weight/strength is necessary to get over the wall. If you measure them individually you'll see broad distributions with soft correlations with ability to get over the wall (because short/strong/light people will be able to do it and tall/strong/heavy people will be able to do it, but short/strong/heavy people won't and tall/weak/light people won't, etc). The wall-climbing task requires the right combination of a small number of such skills to be over some threshold. This trivially (as the simple model in the link shows) generates the observed U-shaped distribution in programming outcomes.

People who claim that anyone can be taught to code well enough to pass a first year computer science course have the opportunity to make a very simple, compelling argument in favour of their thesis: tell us how to teach people to program! If you can do that--if you can get rid of the U-shaped mark distribution that has been documented in first year computing for decades despite all kinds of efforts to understand and deal with it, your argument will be made. Everything else is just hot air: ideological and unconvincing.

There are certain things we know do not cause the bimodal mark distribution in first year computing:

1) Bad teaching (because the issue has been researched and any number of caring, intelligent teachers have thrown themselves at it, and anyone's sucky first year computing prof does not disprove this)

2) Language (because the bimodal mark distribution persists in all languages)

3) Years of coding experience of incoming students (because if that were the case it would have been identified as the differentiator in the decades of research that have gone into this: someone with no coding experience can do as well as someone with years... if they are over some threshold of skill.)

So while it's fun to watch equalitarian ideologues tub-thump this issue, they unfortunately bring nothing to the discussion but ideological blather. The U-shaped, bimodal, mark distribution in first-year computing is robust evidence of a threshold of some kind that people have to be over to code well. There may be other thresholds higher up the scale (I've seen estimates that 25% of coders will never get OO... god knows what the figure is for FP, which I'm still struggling with myself.) But the claim "It would be dreadful if everyone can't code!" is not an argument, it's an emotional outburst, and we need to focus on the data, not the way we wish the world is.

Personally, I would love it if we could figure out how to teach coding better. I see journalists, economists, politicians, business-people, all sorts who are dependent on coders to help them out on the most rudimentary questions. If we could teach everyone to code the level of data-driven discourse would go through the roof. But I'm not counting on that happening any time soon.

Re:Depends how you evaluate the curve

[AthanasiusKircher]

I agree with you that the analogy with music and programming is not exact. HOWEVER...

I think that the music equivalent of programming would be something like song writing or composing. With playing a song, your are really just following the instructions that somebody else gave you, like following a recipe in a cook book.

I think that's a bit of a misunderstanding of how one gets to the "top tier" of musicians, and for that matter, how one becomes a great chef.

It what you say were true, no violinist would ever bother recording another version of some piece of music. In fact, nobody would ever bother even going to see a concert of a standard piece, since there would be nothing new -- it would just be the same "script" or "recipe," and most well-known pieces already have arguably a number of "perfect" recordings (at least in terms of "playing all the notes in the right rhythm and in tune" or whatever your standard is).

No pop star would ever bother recording a cover of an older song. After all, a great singer already did it.

But of course that isn't true. Composers don't generally write every single detail of interpretation in a score, just like there's a lot of "unwritten knowledge" in most recipes about how to actually produce good results. Beyond that, music is a process that happens in real-time. A skilled performer will be sensitive to everything from how their instrument sounds that day to the quality of acoustics in the playing environment to the fact that today they just happened to play the high note in that first theme a little stronger, and maybe they'll bring that note out again a little later because it creates a cool connection (which listeners may not consciously be aware of, but it suddenly brings out an emotion or creates a feeling of continuity which changes the piece).

Performance is an artform at the highest levels. You may not be interested in such nuances, and that's fine. But people who spend hours and hours every day of their lives practicing instruments aren't just "learning notes." They are developing techniques, learning ways to produce better interpretations of music (beyond the basic blueprint in the score), gaining a facility to make real-time adjustments that will create a better experience for listeners at a live event, etc. Similarly, a skilled chef may follow the same instructions you do from a cookbook, but the result in quality may be vastly different. The execution often makes the difference between mediocre and truly great.

I've had people tell me that a particular piece of music was worthless, even when played by top performers who can do flawless execution of the notes. I've then played them a recording of the exact same piece (with all the same notes, played from the same score) played by another performer -- and I've had people say they suddenly thought the piece was amazing... they heard things they never did before, or it had a kind of "energy" that made it enjoyable or whatever.

Anyhow -- this isn't just about music. It's recognizing the value of performance in all walks of life. It's also about recognizing how great artists, whether they generate a product or whether they perform on a stage, are able to tap into dynamic and creative processes to produce effects that are much better than others. You may have been given the greatest set of Powerpoint slides in the world, and you may basically follow a script for a presentation -- but there can still be a huge difference between a completely engaging live presentation and a crappy one that "just follows the instructions that somebody else gave you."

I know you probably didn't mean to denigrate performers, but I think we often tend to think of what's written down as the "primary stuff," no matter what line of work you're in. But there is a lot of knowledge and skill that's passed down orally and learned verbally or through tactile/kinesthetic engagement which makes the difference between following a rec

Measurements

[phantomfive]

If you could measure programming ability somehow, its curve would look like the normal distribution.

This guy doesn't know how to measure programming ability, but somehow manages to spend 3000 words writing about it.

So he doesn't know......programmer ability might actually be a bi-modal distribution. If he had collected data to support his hypothesis, then that would have been an interesting article.

Re:Measurements

[Registered Coward v2]

If you could measure programming ability somehow, its curve would look like the normal distribution.

This guy doesn't know how to measure programming ability, but somehow manages to spend 3000 words writing about it.

Defining programming ability is a real challenge and the definition probably varies based on what is being programmed. I had a teacher who defined it as being able to complete a task in as few lines of code as possible. OTOH, is it worth spending 2x the hours to get rid of 2 lines of code when a quicker solution works just fine? Maybe ability is being able to produce working code that meets the design specifications. Ability, IMHO, depends on the capability to complete the tasks at hand; and thus what constitutes ability will vary. I guess instead of being a 2D U curve or some such thing it is really a 3 D space with peaks and valleys.And thus I reveal my true ability: To change the parameters and drive a discussion to the end I want; which is why I am a consultant.

Re:Measurements

[lgw]

Further, he's perpetrating the myth that the most talented programmers "drive away others, but you have to put up with them", which falls outside the definition of "talented" that most people would accept. Sure, you do very rarely hear about that cliche - the guy who you only give solo projects, but he's hyper-productive - but that's maybe 1 in 1000?

The truth is, for most companies with full-career technical tracks and VP-equivalent top technical pay grades, the more senior you are, the less you code (though hopefully it never goes to zero), and the larger the organization you must have technical influence over. Since you have to build that influence yourself through a combination of leadership skills and writing code everyone uses, you'll never make it if you "drive people away".

OTOH, you don't belong in this industry if you take code reviews personally. Every day the compiler will call you illegal, invalid, and wrong, and you co-workers might say the same about your code in CR. If you start taking that as personal criticism, you're not going to last. We're not writing opinion pieces here.

Re:Measurements

[tompaulco]

Essentially there are two types of companies: * Startups (etc) who want the best programmers and are willing to pay. * Others who want to pay as little as possible to get the job done.

In my experience the two types of companies are:
* Startups (etc) who want the best programmers and want to pay as little as possible to get the job done.
* Others who want to pay as little as possible to get the job done.

No one wants this

[phantomfive]

"In our industry, we recast the talent myth as "the myth of the brilliant asshole", says Jacob Kaplan-Moss. "This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic.

This is swinging at a strawman. A person can be a 'brilliant' "10x programmer' without being an asshole. A person can also be a -10x programmer while being an asshole.

Also, if a programmer can't work well with other programmers, she's not a 10x programmer, she's just a fast typist. Any software that is unmaintainable by others isn't good code.

You still need creativity.

[ThePhilips]

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

Why people forget the creative side of programming?

The programming is indeed bunch of skills. But if you do not have right mind set - inquisitive and creative - your career in programming would be full of frustration.

The only software where one doesn't really need any creativity - is already written and there is literally no work there.

P.S. Of course there is the "flip side" to the creative side of the programming - "monkey" coding and testing. But for most of this work you do not even need to have any deep programming skills. Reading and comprehending documentation fully (an ability which is again easily forgotten by the sensational headline writers) is more useful and also much under-appreciated. And then there is also the writing of tech documentation...

Hmmm ...

[gstoddart]

Now, I don't have stats to back this up ... but many moons ago I was told by numerous profs that programming/CS had pretty much always been the bi-modal distribution, and one of them even showed me the graphs of previous years of first year programming courses to back it up.

I have seen an academic paper discussing the bi-modal distribution.

So, is he saying "among people who are programmers there isn't a bi-modal distribution", or is he saying "among people learning to program there isn't a bi-modal distribution"?

Essentially he has no statistics to back his claims, and seems to be saying that "among people who are already programmers there's all kinds" -- which is FAR different from refuting the observation in academia that people learning programming are most definitely showing a bi-modal distribution.

This sounds like he's talking from his 'feels' instead of from his 'facts'.

Of course it's a myth!

[jvj24601]

This is perpetuated by a small percentage of vocal but talented programmers who, in fact, lack the skill to work with people whom them don't think are as brilliant as they are. This probably works fine in a startup. However, if you don't ever learn to work with people of varying skill-sets, you severely limit the types of jobs you can get later in your career.

Programmer worth/productivity vary a lot.

[CraigCruden]

When you work in a manufacturing plant making cars (for example), a productive worker if allowed to produce is about twice that of a poor producer.... When it comes to programmers/coders the quality and productivity of your upper end programmer can easily be 12 or more times as productive as your weak programmers. In worst case examples some programmers are actually a net negative when it comes to defects etc. The wages however tend to vary between 2 and 3 times your junior programmer (who could be a star or not himself). Some programmers are overpaid at the bottom pay scale, and some are underpaid at the top end. I have worked at some of the top companies, and some that are far far from it so I have been able to see both ends of it.

Programming is a natural skill which can be enhanced greatly when you work in an environment that values talent and you have people that are better than you or at least near the top of their game if you are one of the gifted. I have seen University graduates that are at best average, and I have seen self taught programmers that are among the best......

In short it is not a myth.

Re:Programmer worth/productivity vary a lot.

[complete loony]

A junior programmer fresh out of Uni, joining my team. Learning a new language / framework / application, working full time. Will usually take more of my time to help them than if I just wrote the code myself. I have to explain which existing functions they should use. I still have to flesh out most of the design and implementation of the tasks they are assigned. I may need to take over their keyboard and type some of the code in for them, as the fastest way to get the point across that I'm trying to teach them. And getting their patches up to scratch can take a number of iterations.

After about 3 months, this equation should start to shift. Even though they will still take far longer to complete a task than I would, it should take less of my time to get the same work done. At this point, the addition of someone to the team starts to pay back the initial training period. We can evaluate if this new person is still worth investing time in.

And that's for the graduates that I'd consider hiring in the first place. Most CompSci graduates I wouldn't consider employing at all.

Re:The Curve on Academic Courses

[jythie]

I think it is less a problem with how programming is taught, and more one with how programming is evaluated. Programmers, as a subculture, have serious issues separating stylistic from functional differences, with people looking for things that scan the way they write, with tests for readability and correctness really coming down to 'did the person do it the way I would?'.

Re: News?

[Anonymous Coward]

It's not bimodal but 10x rule still applies. Skills may follow a normal distribution but the task (any non-trivial programming) is a strongly nonlinear task. There are things only 5% of programmers wil be able to do and you cannot replace them even with 10 average ones.

Simple question

[king neckbeard]

how many developers does a 10x programmer have to drive away before it is a wash?"

By definition, 10. Perhaps being able to figure things like that out is what separates 10x programmers.

Re:Some poeple think I am genius

[PRMan]

or that my ability has something to do with the fact that I have been accept into Mensa

That's a funny typo.

Re:The Curve on Academic Courses

[tompaulco]

One of my friends (who now has a masters in CS) was asking me why his programming 101 course was so heavy on pointers when nearly everything in the 200+ range was taught using pointerless, or nearly pointerless, languages. The reason, of course, is to figure out as early as possible which camp each student was in.

I would think that the reason was the same reason that we teach people to add before we teach them to use a calculator. After understanding the basics, one can make better use of the tools.
Unfortunately, most 4GLs (and even some 3GLs) obfuscate what is really going on in the background such that you either can't write efficiently or at least the effort involved would be ludicrous, so we end up with bloated monstrosities.

Re: News?

[Anonymous Coward]

What annoys me is that despite the Mythical Man Month still being the only vaguely scientific analysis, and despite the fact that it demolished a bunch of received wisdom and only created ONE fact of its own - the existence of the 10x programmer - somehow because it was written a long time ago that means it "no longer applies".

Of course your misrepresentation of the 10x rule isn't helping. The 10x rule is that the best developers are 10x as productive as the worst 10 developers. That's all it says. So you can replace them with 10 worse developers, that's the whole frickin' point of the 10x rule.

If you wish to invent another rule, that some tasks are so hard that only some programmers can succeed at them, you can go gather your own evidence, but don't pretend it's "the 10x rule" because it isn't, and your rule did not come out of the only vaguely scientific analysis that's been done, and you shouldn't pretend that it did.

Re:News?

[bondsbw]

I love this tidbit:

If you could measure programming ability somehow, its curve would look like the normal distribution.

So, they're saying that they know the result of the measurement despite admitting that they don't even know how to perform the measurement. I see.

Re:News?

[Shortguy881]

A downward slope would just be non-normalized data. If there are a lot of bad ones, bad just becomes the mean. Programming talent, like most things, probably falls neatly into a bell curve.

The U curve the article is referring to is a bimodel distribution, which is rare even in nature. It occurs for something like a disease that effects immune compromised people. Thus the age distribution of infected would be the very old and very young.

Another Hugh Pickens "special"

[Anonymous Coward]

Hugh Pickens, the British wannabe-programmer forum troll, posts more BS fresh from the island of marmite.

This time he is channeling Jake Edge, a person much like himself, i.e., a wannabe-programmer from Merry Old England who spews 100 lines of opinion for every 1 line of code he has ever written.

Why do the Slashdot editors think this stuff is interesting? I think there must be some British Slashdot editor who keeps pushing this garbage.

Re:Dunno about that, I still suck at programming.

[Xest]

The fact you think you suck already means you have drastically higher potential than a large number (perhaps even a majority) of developers

Far better to think you suck and know that you can improve than to think you're awesome and stay shit forever.

Humility is the number one most important defining trait shared by the world's genuinely great developers. I've met plenty of developers who think they're great, claim they're great, but repeatedly prove their development ignorance when they start talking about the subject. In contrast, I've never met a humble programmer that isn't either awesome, or well on their way to being awesome.

Re:News?

[ShanghaiBill]

I mostly see the 'U' view of things in younger west coast programmers with fat wallets and a superiority complex

I am a west coaster, and have never heard of the "U" shape myth, and what you say makes no sense. What the "U" shape means is that there are many bad programmers, many great programmers, and almost no average programmers. Believing that greatness is common is the opposite of a "superiority complex".

I doubt that the "U" myth existed before the author of TFA made it up.

Re:News?

[ShanghaiBill]

many users inexplicably believing that programming requires a "special mind", dividing people in to two groups: "can program" and "can never program".

This is not "inexplicable". It is obvious to anyone who has taught programming to beginners, or any type of introductory abstract math. About a third of the population is simply incapable of abstract reasoning. If you think otherwise, I invite you to come to my house, and I will give you a free dinner while you explain "vectors" to my 15 year old daughter. Good luck with that.

Re:News?

[Anonymous Coward]

It is obvious to anyone who has taught programming to beginners, or any type of introductory abstract math.

Having spent time in grad school as a TA and tutoring dozens of high school & university students on the side for extra money, I disagree, and don't think it is anywhere close to obvious. Many of the tutoring students were people pegged as the can't learn it types, but needed to get through math, physics or CS topics for one reason or another.

Just about any student or person can be reached, it just takes time and effort. Often it takes multiple, varied approaches to teach someone a new topic, when the course material and professor only have time to try one way, before needing to move on. It might take enough time that majoring in the subject would be completely impractical, but I had not seen someone who couldn't be made to pass an intro level course as long as they tried and made it a priority. Sometimes it isn't even an issue with the material in general, but because they failed to grasp a topic that is a foundation for later topics, and I've seen a few students "suddenly" catch up and able to keep up on their own once they fixed a few problems with the basics.

Come on. What tripe.

[fyngyrz]

From TFS:

If you could measure programming ability somehow, its curve would look like the normal distribution.

Since you can't measure programming ability "somehow" or otherwise, you don't know what the curve would look like. Which reveals the entire set of claims here as utter garbage. If you don't know what the distribution is, you don't know what the distribution is. How difficult is that to understand?