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

[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.

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'.

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: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]

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.

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.