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

[Sique]

Actually, you don't have this U-curve with musicians. But many people just see the low end (the child of the neighbours screeching away on the violin when you want to take a nap), and the top end (the star violinist in the news). This creates the false impression of an U-curve. But there are hundreds and thousands of violinists you usually don't see, because they play in some university orchester in a small town you've never visited, or they play at marriages and 50th birthday parties, or they earn their money as bar violinists. And most of them are average.

Re:Depends how you evaluate the curve

[Sique]

Actually, data available from the Künstlersozialkasse, a health insurance for musicians and other artists in Germany, suggests that that curve is a hyperbola, as expected from a phenomenom in a social context.

Re:Depends how you evaluate the curve

[CastrTroy]

I agree that many people can play instruments if they work hard enough at it, but I don't think that you can draw a direct comparison between something like playing violin and programming.

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. Most people can learn to do this well. However, composing an original piece of music is more like making up a recipe of your own from scratch and having it turn out well. I know people who are very good at following recipes and make amazing food, but who are unable to figure out which spice to substitute for another when they are out of an ingredient. Or are unable to take a random bunch of stuff they have left over in their cupboard and turn it into something good.

Relating this back to programming, I think that programming is quite hard to grasp for a lot of people. It's easy enough for them to grasp the basics. Tell them the exact specifications of small function, such as "write a function that removes all the vowels from a string", and they could probably do a pretty good job of it. However, give them a larger problem without a direct answer, like for instance, "write an application that allows 2 users to send messages to eachother" and they are completely lost. They have no idea how to plan out the application and will probably take 10 times longer to complete the project than a good programmer would.

There's a huge problem, even with people already working in the field, who can't do something as complicated as Fizz Buzz. That should be a simple function, and yet a lot of people fail even this simple test.

Re:Depends how you evaluate the curve

[Minwee]

Now, what's a hyperbola?

It's something that people on the other end of that U-curve of math knowledge from you all know about.

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

[narcc]

I tuned the radio to the local top-40 station. It would appear that the worst musicians do indeed make money.

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

The Curve on Academic Courses

[Anonymous Coward]

On academic programming courses - of which I've taught on many - the grade distribution is definitely bimodal and there is a clear gap between those who can and those who can't. Of course, there is variance among those who can but the difference is largely that those who can largely get better whilst those who can't never get even get it.

Re:The Curve on Academic Courses

[Bongo]

Maybe then there is something about how to really teach programming that everyone is missing. With drawing, people are either good at drawing or awful at it, regardless of classes, until teachers figure out what drawing really is and what the mind is doing when it is drawing. The people who have been seen to do well "in class" are just the ones who happen to have already got that mind skill. So I would wonder whether education has this figured out with programming, and that you'll see bimodal until it does.

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:The Curve on Academic Courses

[Orgasmatron]

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've used a similar technique with cousins and nephews who have come to me, as the adult in the family that works with computers, for advice when trying to decide to start (or sometimes quit) a CS course.

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:The Curve on Academic Courses

[pla]

I can appreciate the difference between "I don't like this code because it looks different than how I would have written it", and "I don't like this code because the author clearly has no clue how to accomplish the required task and only barely managed to cobble together enough crap to get the desired outputs on a handful of test cases".

The former, I can work with (and sometimes learn from). The latter, I know that I will eventually need to waste more time "helping" the author repair it when it breaks, than I would have just doing it correctly the first time myself.

The real problem here comes not from professional programmers, for the most part (though yes, truly awful "professionals" do exist). The problem comes from having most of the people "programming" in a modern office environment not actually programmers. You have accountants writing god-awful VBA, you have help deskers writing crappy web forms to automate part of their work, you have business analysts who know juuust enough SQL to get an answer, albeit a completely wrong answer, from the data.

This has nothing to do with style, and everything to do with "programming" as an increasingly required bullet point on the average office worker's resume. Yeah, you know some VBA, good for you - Now learn when you can accomplish the same thing with normal Excel formulas, and quit turning every spreadsheet you touch into a smouldering heap of unmaintainable side effects.

Re:The Curve on Academic Courses

[phantomfive]

until teachers figure out what drawing really is and what the mind is doing when it is drawing.

FWIW it's been figured out (at least, the teaching aspect has been figured out, even if we still don't know what's actually going on inside the brain).

Re:The Curve on Academic Courses

[goose-incarnated]

Maybe then there is something about how to really teach programming that everyone is missing. With drawing, people are either good at drawing or awful at it, regardless of classes, until teachers figure out what drawing really is and what the mind is doing when it is drawing.

While I agree with your premise I disagree with your analogy; drawing, specifically, can be taught. There are purely mechanical rules to producing a reasonably high quality sketch of a face, or scene or object. I can (and have) taught the basics of drawing, sketching and shading in pencil.

Re:The Curve on Academic Courses

[grantsellis]

As someone who was briefly an art major, drawing is largely a matter of practice and having the proper foundation (which is gained by practice). Classes increase the rate that practice helps. If you practice, art education teachers have already figured out how to help you improve. What you see in high school art classes is the division between people who care and people who don't. People who don't care don't practice and consequently don't have the foundation to practice further. Because there's no future in art, in college the only people who take art classes are the ones who care and who have the proper foundation, so (allowing for the typical small class size) there is a much more normal distribution in skill.

Re:The Curve on Academic Courses

[Beetle B.]

On academic programming courses - of which I've taught on many - the grade distribution is definitely bimodal and there is a clear gap between those who can and those who can't.

I'm guessing those who can't will not go on to become professional programmers. If you look at active and professional programmers, is it still bimodal?

Re:The Curve on Academic Courses

[narcc]

I've said this before. Having taught many programming classes myself, I've never once encountered one of these mysterious "can't" students.

It's possible that you're just not a very good instructor.

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

[phantomfive]

It might - but that appears quite unlikely to me. Surely it has a normal distribution with the majority being somewhere in the middle

There is a reason for it to be bimodal.......those are the kinds of programmers companies demand.

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.

Those conflicting motivations could easily create a bimodal distribution (between programmers who are passionate, and those who are just doing a job). I don't know if that's happened because I haven't measured, but it seems plausible to me.

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

[Anonymous Coward]

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.

Let me know if you have any other questions.

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.

Re:Measurements

[tnk1]

There are few more useful tools than a code review. After all, another opinion is useful in just about any field and a team needs to make sure they keep up with how other people are doing things in their modules. You find a lot of things to fix when someone is looking over your shoulder.

However, people can be dickish about how they do them. I'm not a big fan of going through elaborate rituals to make people feel better about their code, but at the same time, when you're a dick to someone in a CR, you're making them feel defensive when you want them to be more open to accept constructive criticism.

If people are being defensive about criticism of their code, then they need to change that, but let's not pretend that it's all on the person whose code is being reviewed.

Re:Measurements

[tompaulco]

I've lost count of the number of startups I've turned down because their salary offerings have been laughable and their benefits non-existent coupled with the high risk of outright company failure.

Yeah, I learned my lesson with startups as well. I was getting underpaid by about 33% according to industry average. They considered me to be overpaid because they could get brand new people fresh out of college for about half what I was getting paid who were able to do about 1/4 as much work with lots of handholding and rewriting. But I digress. They kept going on about how I was going to get shares in the company and get a big payoff when we sold. However, after years of coding, when I finally got everything done, they let me go.
So from now on, I am no longer going to be a source of credit dollars for employers. Cash up front only. If you want to give me shares, that is fine. But I also want industry standard wages.

Not Mutually Exclusive

[ohnocitizen]

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.

Lost me here. Programming can definitely be a passion, and it can also be a talent. One might have a natural aptitude at programming. That doesn't mean one cannot learn the skill of programming, or that someone who finds it difficult in the beginning will not become an expert.

In my career I've noticed that there are developers who are brilliant, and developers who struggle. The ones who struggle can succeed through mentoring and training.

There are also developers who are kind and have great social skills, as well as those who do not. This is true of any employee at a company, including managers. Social skills can also be a passion, a talent, and a skill. That is also something that can be improved through mentoring and training.

The primary reasons we don't see this happen for social skills are office politics and the false view that personalities and behaviors are fixed.

If you are reading this and your programming skills or social skills are lacking - invest in yourself and work on them. It will pay off handsomely.

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.

Re:No one wants this

[SQLGuru]

I think anyone who is a 10x programmer (which I consider myself to be) should be interested in bringing as many people as possible up to their level. Who wants to be LeBron James playing pick-up basketball in the rec league when they could be LeBron James playing in the NBA championships? When you are so much further ahead of everyone around you, people can't fully appreciate how great you really are.....but if you are surrounded by stars and yet still shine far above all of them, you look that much more awesome. It's one of the reasons that I spend time with the noobs mentoring them.......also, if I mentor them, they'll be more apt to do things my way.

Re:No one wants this

[Beetle B.]

When you are so much further ahead of everyone around you, people can't fully appreciate how great you really are.....but if you are surrounded by stars and yet still shine far above all of them, you look that much more awesome. It's one of the reasons that I spend time with the noobs mentoring them.......also, if I mentor them, they'll be more apt to do things my way.

See this above?

This is an example of an asshole programmer.

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

Re:You still need creativity.

[ThePhilips]

I have worked ~5 years in maintenance and have intentionally omitted it.

In maintenance, for it to be any effective, the problem is even worse: you have to be twice as creative, to find solutions which do not have side-effects yet fit the original specification/requirements.

I have seen many results of maintenance done by the "generic" outsourced stuff and on average they were not spectacular, and occasionally they were outright disastrous.

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

Re:Hmmm ...

[avandesande]

Anecdotally I haven't seen this- the best teams have one or two star people and the rest with good work ethic and personality.

Re:Hmmm ...

[gstoddart]

From what I can tell, the only people who believe it have no other skills and are terrified that if the truth were known (that anyone can learn to program) then they'd no longer be special.

Well, then let's dispel with that piece of bullshit, shall we?

When I say "but many moons ago I was told by numerous profs that programming/CS had pretty much always been the bi-modal distribution" ... I mean tenured professors, with PhD's, with published books and actively teaching in accredited universities. Not just "I heard it from a guy".

You seem to be comfortable suggesting I feel my penis will be larger if I convince myself this is a true fact. Allow me to suggest this: You're acting like a dick and making an ad-hominem attack -- a sign of a moron or an asshole; or both.

I'm telling you what I've heard from professors, and what I've personally seen.

I marked both first and second year CS courses, I have personally seen graphs of the same course's grades for a trailing decade. And it was empirically a real thing.

I honestly have no idea the extent to which this is universally applicable, isolated, or purely random. But I have had it described to me by professors, I have seen it in courses I've marked, and been hearing this 'factoid' for ... well, almost three decades.

This doesn't come out of nowhere. It isn't a self inflating of ego. It is, in my own personal and exceedingly constrained opinion, an actual observation of reality. It is a thing, and I am curious as to what it really means.

If you think I have my personal identity wrapped up in being some special little snowflake who is unique as a programmer (something I no longer do, BTW)... well, either you're a moron, or you're just an ass who has no better reasoning skills than to fall back on the claims that I must be delusional and acting out of self interest in saying this.

I am genuinely curious if this is true, and would love to see definitive stats ... it has always baffled me, but I've witnessed it ... but if you think I'm saying this out of some mechanism of puffing myself up, then you can piss off.

But if you can state your counterargument without suggesting I need to justify my existence to you or anybody else, I might actually be interested in hearing evidence to the contrary.

Re:News?

[BarbaraHudson]

"there is a myth that programming skill is somehow distributed on a U-shaped curve"

Never heard of this "myth." I always thought it was a slope - a lot of bad ones, a fair amount of decent ones, and some really good ones - and that it was in many ways dependent upon experience - the more experience you have, the better you get - or you go into something else after a few years.

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.

Wrong things

[fractalus]

1. Programming skill is more likely to have a power law distribution rather than a normal distribution. That is, lots of very unskilled people, a chunk of decently-skilled people, and a handful of "rock stars." This would more closely match the distributions (and success rates) of other skills. This also matches my experience working with programmers of varying skill levels for more than twenty years.

2. You can teach a lot of the concepts but there is an inherent knack for logical thinking that is very hard to teach. If one has this knack, new concepts are easily grasped, solutions to problems using currently-known tools are more easily found, and troubleshooting is simpler. If one DOESN'T have the knack, they can still be successful, but it is harder, requires substantially more effort, and more of their time will be taken at each step.

It's not always pobox where someone sits on the talent distribution. This is also not a perfect predictor of their ability to produce; some people are very bright but unmotivated and unmotivatable. I would rather have someone with Leeds talent who was willing to work and produce. It's also important for a team to code to roughly the same competence level; if you have one rock star who writes code that no one else understand, you create a bottleneck for yourself on that one person being able to work with that code.

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:News?

[jythie]

Both variants are floating around. I mostly see the 'U' view of things in younger west coast programmers with fat wallets and a superiority complex, thus anyone who thinks like them is a superstar while anyone different 'sucks.

Agree about U curve, disagree with the rest

[allcoolnameswheretak]

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.

I disagree with this statement. I enjoy programming and I am very good at it because I enjoy it. Enjoying it means that I am interested, stay up to date and learn new things all the time. It means I do alot of programming in my spare time, which further increases my skills.
Many developers I know do it as a job and forget programming when they leave the office. This makes a huge difference.

But no, programming talent is not distributed along a U curve. However, I firmly believe that an average developer is 10 times more effective than a poor developer. A good developer is 10 times more effective than an average developer, and an excellent developer is 10 times more effective than a good developer.

Maybe not exactly 10 times, but certainly by an order of magnitude.

Re:Agree about U curve, disagree with the rest

[PRMan]

While I agree with you in principle, I don't know ANY programmer that is 1,000x faster than another. At every job I have been at, I am the fastest programmer I know. I write the least code, it runs the fastest (because it's short), and it's very easy even for a junior developer to maintain (because it's short and easy).

When I leave a position, I am typically replaced by at least 3 programmers. And the work output goes to one-half or one-third anyway. This means, AT BEST, I am 5x-10x better than my replacements. Could someone be 10x faster than me? I haven't seen it in over 30 years, but maybe I could see 2x faster or 3x. That still puts the maximum I could imagine at about 20-30x faster than the least.

Re:Agree about U curve, disagree with the rest

[gstoddart]

Well, arguably being the fastest at writing code doesn't mean any of it is actually good.

I once worked with a guy who could crank out massive quantities of code. It made for some pretty amazing proof-of-concept and demo stuff -- but it was utterly unusable in the real world because it was, overall, really badly written code.

It didn't have any robustness. It made stupid architectural decisions. It made unfounded and unsupportable assumptions. It had an awful lot of hardcoded magic because he only solved one use case.

It impressed the heck out of the VPs and the customers who said "oooh, gotta get me some of that". But in trying to turn any of it into production level code, by the time you started trying to fix the glaring holes, remove the things which just simply couldn't work in the real world, and take out some of the shortcuts and voodoo -- there was very often nothing workable left.

This was coupled with the fact that he couldn't/wouldn't debug his own code, couldn't/wouldn't go in and make even simple modifications to it without breaking it, and had quite likely moved onto something else new and shiny and couldn't be persuaded to actually fix or maintain previous projects.

He left a wake of crap code and demos, but almost nothing which could be used in the real world. Which means everyone around him started saying "look, if you want to use the super awesome code he wrote, go ahead, but leave me out of it unless you can get him to complete what he started and not leave us with a half-finished demo which can't be made real, we're not supporting the shit he leaves behind him".

Everyone else considered him a nightmare, because while he was prolific and wrote cool looking things ... it was all smoke and mirrors, which covered about 2% of the functionality and 75% of the sales demo.

I was glad when I transferred to another group and he was someone else's problem. Though, I did notice the carnage of sales people and clients who bought into the bullshit and thought they were getting something real only to find it had an awful lot of "pay no attention to the man behind the curtain".

I hope he was a very unusual case, but he was an absolutely prolific coder, who wrote absolutely terrible code.

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

[phantomfive]

Don't worry too much. Alan Kay said:

"I feel like my answers are quite trivial since nobody really knows how to design a good language, including me."

Similarly, no one really knows how to do programming really well. Some are better than others, but we're all feeling our way through the unknown early days of software programming. In 100 years, who knows what programming will look like?

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.

Re:Rock Star =

[jythie]

More like personality. Being a rock star in programming has nothing to do with output or quality, but of convincing peers and managers that you are good. The greatest trait to have for becoming a rock star is narcissism and the social skills (even if they fashionably broken) to pass that off as competence. Most 'rock stars' I have worked with generally needed drones to clean up their work, but they were great at giving the impression they walked on water to anyone who mattered.

Absolute bollocks

[msobkow]

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.

Competent, basic programming may be, but there is also an aspect of art and talent to it that can't be taught no matter how much the "we don't fail kids here" people might wish it weren't the case. Companies aren't looking for competent programmers -- they offshore those jobs. They're looking for the exceptional talent that can drive the whole process from top to bottom, including issuing the designs and models those "competent" programmers are expected to work from.

I may not believe in the "10x programmer", but I most certainly do not believe that just "anybody" can be taught to be good programmer. I don't believe that of anything except the most basic of manual labour jobs.

eh

[buddyglass]

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.

Yes and no. I'd argue it depends on how you define "programming". If you're talking about "can code up basic solutions to relatively straightforward problems" then yes, with enough time, most people can probably learn to do that. Considerably fewer ever reach the point where the code they produce is (usually) elegant. Where they're capable of troubleshooting the most elusive bugs. Where they fairly quickly identify solutions that are orders of magnitude more efficient than the naive approach to a given problem.

I tend to think the folks who reach that level are able to do so by a combination of experience and some inherent traits that you can't just pick up in a programming class. An example from my current job:

My employer makes apps. Our app downloads some images over the network when it launches. It caches them so unless something changes there's not much going over the wire, but the initial download can take a while. Up to 30 seconds where the user is stuck watching a progress indicator on the splash screen. At least two different developers had worked on this app. Then the company hired a new guy (not me). One of the first things he did was refactor the image download code to use multiple threads and transfer the images concurrently instead of in serial. With 8 threads the speedup was approximately 5x. His key insight was that most of the images were very small, so much of the total time was latency and not lack of bandwidth. Especially since latency is so high on mobile networks.

Now the previous developers were not right out of school. They had years of experience. They could "program". But they didn't recognize an enhancement with significant implications for users when it was right there in front of their faces. It's possible that if they had been specifically instructed to optimize the image loading logic they would have come up with a similar solution. Maybe, maybe not. But why did the third guy immediately recognize the problem (and put in place a very effective solution) without being prompted? Was that a "skill" he learned in a programming class?

On multiple occasions this same guy has identified long-standing bugs in our app that I'm almost positive no other member of our team would have ever been able to figure out even with infinite time.

Re:eh

[Jeremi]

But why did the third guy immediately recognize the problem (and put in place a very effective solution) without being prompted? Was that a "skill" he learned in a programming class?

It might have been that he was just a clever guy, but let me offer an alternate possibility -- the new guy recognized the problem precisely because he was the new guy.

Specifically, it's common for people not to think about minor annoyances they have grown used to. It's the boiling-frog effect -- a programmer who has been working on that app every day since the very beginning, as more image assets were slowly added, might not notice the gradual slowdown of the app's startup phase, because at first it was fast enough, and eventually he/she just got used to the slow startup because "that's just how it is with this program".

The new guy, OTOH, sits down with the app and because he's had little or no previous experience with the delay, finds himself noticeably annoyed and says to himself, "that is a problem... maybe I can find a way to improve that".

tl;dr -- a person with fresh eyes can often see problems that the old hands have grown too accustomed to, to notice.

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:Rock Star =

[eulernet]

While you are partly true (in France, we use the term "savoir faire" -expertise- opposed to "faire savoir" -publicize-), I think another factor is more meaningful: intrinsic interest.

If you let me program something interesting, I'll be the best programmer in the world, following the strictest guidelines without complaining.

But if you let me program some boring shit, I'll be as useless as any lazy guy.

In your case, this can be expressed as: the rockstar does all the interesting work, and delegates all the menial tasks to other people.
When you are a beginner, everything is interesting.
As you grow older, a lot of things become boring.

Re:One

[BVis]

I can also recall a manager I had who, within the first month of him being brought in had 20% of his developers quit, referencing him as WHY they were quitting.

This is a win for management. The other 80% of developers that DIDN'T quit will have to do the work of the 20% who have left. That manager just saved the company approximately 20% on programmers' salary (assuming that those developers got paid roughly the same.) Since reducing costs is good for the profits, this manager will not be fired.

But he was a superstar, and last I checked he is now the CEO of the company, with 95% of the staff gone (and down to 1 or 2 developers), and he is credited with keeping the company afloat.

Sure, he saved 95% off salaries. It's easy to keep a company afloat when you don't worry about working people to death.

Re:So where do you place the women folks?

[Anonymous Coward]

Fuck you. I'm the best. I write all my own libraries and never use anyone else's code.

The corporate definition of a rockstar dev

[Applehu Akbar]

Is a person under 40 who you can get cheap. After the age limit and salary bar have been passed, the same person finds himself on the other side of the U.

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.

key skill

[lkcl]

the key skill needed for programming is to be *able to pay attention to detail*. if you are unable, by any means, to focus on one thing for any length of time (because, for example, you have the attention span of a spider on cocaine or worse caffeine, because, for example, you have been brought up on txting and IMing and twittah) then it should come as absolutely no surprise that you are utterly useless at programming.

another person mentions that creativity is needed in programming. well, yes, this is true. if you have a bug that you don't know how it got there, you need to be extraordinarily patient [attention to detail] with yourself and your work, going over it *creatively* in different ways until such time as you have found, understood and then fixed the bug.

if you do not have the patience because you are, once again, brought up on a diet of twitter, instant gratitfication and refined sugar products, *no amount* of creativity is going to help if you cannot apply it.

i call myself a programmer: what i actually have is obsessive compulsion to be able to pay attention to one task for spans of time that exceed healthy limits. i can be freezing cold and not even notice... because i'm debugging something. only sheer complete exhaustion can get through under those circumstances. this is where it helps to be working in part of a team, as it sets some structure for social interaction. it's no accident, then, that there are entrepreneurs [this goes back a few years on slashdot - there's an article somewhere] who *only* take on *english language* majors [US i presume], and train them to be programmers. why? because people who can *communicate* turn out to make better programmers than people who have been through a university-driven programming course.

straw man supporting a stupid conclusion

[sribe]

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

30 years full-time in the industry, NEVER heard that before. There's a lot of companies doing mediocre work who believe their mediocre developers are rock stars. That's because to marketing and management types, successfully getting a computer to do anything at all is magic, and they cannot readily distinguish between ho-hum "accomplishments" and serious ones.

The truth is that programming isn't a passion or a talent...

Bull. Fucking. Shit. This is not a truth nor a new insight, it's just wishful thinking, and this author is far from the first management prick to delude himself this way.

...it is just a bunch of skills that can be learned.

Of course it is. But excelling at it takes certain aptitudes and talent. Confusing "it is a just a bunch of skills" with "pretty much anybody could potentially be as good as anybody else" is just stupid.

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.

Well now, that's actually true. But it's equally true that all those jobs ads for "junior" or "intermediate" developers are looking for okay developers, not rock stars. There's jobs for them, and I've never met anybody who expected newbies to excel. So it's kind of an implicit straw man argument--but still, we should all be careful not to drive away newcomers, and keep in mind not creating this (possible) problem.

...the tech industry is rife with sexism, racism, homophobia, and discrimination...

Maybe where this asshole worked ;-) And certainly there are companies where this is true, but how common is it? Where I've worked, I really believe the women and minorities were treated well. Granted I've never actually asked them that question, but then again, exactly how would that make them feel like they fit in?

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.

No way. We all know (I hope) that although the 10x (or 25x, or 50x, or infinity-x) must have certain personality traits related to sustained concentration and so on, that when it comes to pleasant vs asshole, they actually exist in a pretty normal distribution. The problem of course is that because they are somewhat rare, it's harder to screw up the nerve to fire one if you think you have one.

And, BTW, there are infinity-x programmers. There are plenty of problems that average programmers would simply not even be able to solve at all--not the majority of work of course. Relative to the amount of work available, problems that require unusual skill to even solve are rare. But given the huge amount of work, there are plenty of problems beyond the grasp of the average...

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?

[ceoyoyo]

Just read the rest of the comments. Slashdot is a hotbed of programmers who think they're god and everyone else sucks. They also argue that programming is some kind of talent you're born with.

I teach programming mostly to people you wouldn't expect. Anybody can learn and, just like any other skill, their ability is mostly determined by the time and motivation they put in. Learning programming is even easier than a lot of academic subjects because there's instant, fairly unambiguous feedback.

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:the 10x programmer is no more toxic than averag

[tnk1]

It's probably less about sour grapes than it is about the image of a certain kind of coder which makes for a good story.

People like their assholes. They don't like being too close to them, but they like assholes who cut through the "bullshit" and make things happen.

News outlets tend to pick up on those stories and people who are assholes tend to encourage that, because some star coders are just assholes and like the idea that their particular dysfunction makes them seem hip and employable, as opposed to being relegated to a closet somewhere.

The reality is that there are excellent coders of both the nice and the asshole variety. It's just that you don't hear about the nice ones because they're not grandstanders. The assholes tend to be.

If given a limited budget and resources, I'd probably pick the star coder, even if an asshole. I think the real issue with a 10x coder, as opposed to a team of average coders is the overhead of managing a team of coders. If you have one guy, he has one vision and it doesn't have to be transmitted to and adopted by the team. This is useful for certain projects.

For other projects, where you are not going to be able to get any one person to be able to finish it, then team dynamics become much more important, and it becomes much more important to not have assholes on your team. If you're forced to have an asshole star developer, then you need to find people who will execute that vision without complaint. At that point, you're going to tend toward worker bees instead of highly skilled individuals because you don't want a religious war between the the two assholes writing your code.

However, if you lose the assholes, you're much more likely to find a team of above average coders because they can actually work together without trying to backstab or snipe at each other constantly. You don't need to limit yourself to coders who are just puppets of the asshole senior coder.

Don't get me wrong, puppet coding can certainly work, but is probably something you only really want in a short term startup where you can have that vision, without having to deal with larger teams.

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?

[Viol8]

Most people can do most things averagely well given enough time and practice. However to be exceptional at something takes an innate talent. Mozart was born, not made. Ditto einstein. And the same applies to programmers (and no, I don't count myself as one these elite).

Re:News?

[Art Challenor]

I would agree with this in the same way I would agree that anyone can learn to play a musical instrument. However, I still think it take an innate talent as well a (lot of) training to become an orchestral soloist.

Not to overwork the metaphor, but there are also people who would work in menial jobs so that they could program at night if it weren't for the fact you can make a living programming - the same people who have jobs coding and write software, say for open source projects, on weekends.

The real problem is weeding out the people who have no interest but still try to make a living writing code. I can only assume that those people write some of the websites out there, such as the ones that insist you enter credit card numbers without spaces or other punctuation. It's a 16 digit number, you can ignore anything that isn't a digit and feed it through the payment service to see if it's valid.

Re:News?

[jellomizer]

I think it is in terms of observations.
The Rock Stars, the company will go out of its way to try to keep them
The under performers, will just stay at the same place as they have a hard time getting a job elsewhere.
So the organization has the long timers as the Rock Stars or the Under performers.
The middle people will often stay there for a few years and move on. So they are in flux, and that makes it hard for our observations to see the middle ground, as the majority.

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.

Elites are real, kind of...

[Tablizer]

I've been around a while, and I agree there are what can be called "elite programmers", but with a caveat. Such people are "masters of code", but generally they are not very good communicators, and work on projects and niches that require a high degree accuracy, fastidiousness, and debugging skills. They often work on systems software, such as OS's, database engines, network control software, weapons control systems, etc., and are usually paid quite well.

But they don't do so well when the requirements are fuzzy or change often. They don't handle ambiguity well.

Of course, this is probably an oversimplification, and possibly a feedback loop where one that is highly "code oriented" will tend to be given yet more code-centric projects away from fuzzy office politics and fickle customers such that they don't develop their "fuzzy" analytical skills. Thus, they are not necessarily inherently "bad" at dealing with Dilbertian chaos, it's just that they lack experience with it because they went into a field or niche that is more technology focused, which helps keep them away from office politics and goofy users.

It's hard to master both human nature AND machines in one lifetime. Those who focus on a mix of both are probably in-between skill-wise between people and machines, and this is where the majority of developers and developer/analysts are.

And of course there are exceptions to the rule: some master both, but those are rare in my experience. (Those who believe they have mastered both are common, but egos tend not to be accurate to their owners.)

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.

Re:News?

[pr0fessor]

My wife the business woman {who does more math than I do on any given day} has bailed out and now I'm only one left to help my son with his freshman algebra because "Algebra!?!?!?"

Anyway I found very quickly that the key to helping him understand algebra is to pry the cell phone from his hands and turn it off.

Re: News?

[Cederic]

What gets me about the summary is the assumption that 10x programmers are arseholes.

Some programmers are significantly more productive than others.
Some programmers are twats.

The two communities intersect, so focus on hiring members of the first group that aren't in the second. They exist. They're worth some extra pay.

Drive the twats out of the industry.

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?

Re:Come on. What tripe.

[ShanghaiBill]

Since you can't measure programming ability "somehow" or otherwise, you don't know what the curve would look like.

Except that you CAN measure it. Just give each person a few programming tasks that should take ten minutes or so. I do that all the time. It is called a "job interview". My experience is that most applicants are incapable of programming even trivial solutions, or even getting the syntax right ... and these are people applying for programming jobs. A fair number can come up with reasonable solutions. Only a few come up with elegant out-of-the-box solutions that I was not expecting.

The distribution is not "U" shaped, and it is not normal (bell shaped). It is high on the left, and slopes downward to the right.

Re:Come on. What tripe.

[sfcat]

The distribution is not "U" shaped, and it is not normal (bell shaped). It is high on the left, and slopes downward to the right.

That's called a power distribution. And its what you would expect the distribution of programmers to be given that programmers are drawn from the extreme edge of the normal distribution programming skill in society at large.

Everyone's a programmer. Even dead people!

[fyngyrz]

A variation of it is quite prominent on Slashdot, with many users inexplicably believing that programming requires a "special mind", dividing people in to two groups: "can program" and "can never program".

Some of us just have different metrics for drawing a line between "programming" and "stumbling around in a programming language doing dangerous, stupid, and occasionally functional things."

But, hey. If you can set your digital alarm clock, or interact with your microwave in such a way as to involve more than one button push (even if you're going to destroy the comestible), you're a programmer, right?

It's like kids with crayons. They're all artists! Special butterflies! Call the Louvre!

Now get off my nursing home's lawn

Re:News?

[narcc]

I've taught plenty of intro programming classes. You're likely just a terrible instructor. I've not found a single student that was incapable.

. About a third of the population is simply incapable of abstract reasoning.

Citation needed. What backwater pay-to-publish journal did you find someone that denies that 1/3 of the population fails to reach the the formal operational stage of development?

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.

I have a few teaching tricks I've picked-up for that. I have little doubt I could teach your otherwise normal child the basics of vectors in an evening. Well, at least well enough to get her through calc.

Teaching, like programming, is a skill. If you want to better help her, do some reading on formative assessment.

Inaccurate summary and poor form

[Mel]

The summary and comments often focus on what Jake Edge said where in fact, Edge is summarising what Jacob Kaplan-Moss said at a conference. The merits of the points made during the presentation can be discussed on their own but there seems to be a lot of vitriol aimed at Edge that has no basis in either fact or logic. Aside from an inaccurate summary, it's also sad to note that slashdot used a "subscriber link" feature which was meant to be used by a paid subscriber to share an article with a small number of people until it was free a week later. The feature was not intended for sharing with the entire audience of slashdot. That is just poor form.

Re:News?

[Gavagai80]

Actually, Michael Jordan was still a better baseball player than 99.99% of the population. Let's see you hit .200 and drive in 50 runs in AA pro baseball.

Disagree.

[fyngyrz]

Just give each person a few programming tasks that should take ten minutes or so.

Yeah, but actually no. Each skill set is different. I could write you a PCB router in under an hour, or whip up an image processing mechanism, layered image editing, signal processing, write an FFT from scratch. I can do assembly coding as fast as I can type while higher up, I favor c and Python for their various and highly disjoint abilities. I'm good at documentation, and I can manage effectively -- without getting the team to hate me. But fizzbuzz? Sort of boggles me. I solve it very slowly. Perhaps because there's no point to it and I don't really give a flying crap. :) But perhaps also because it's just not my thing. I despise puzzles-for-the-sake-of-puzzles, and avoid them like the plague.

Bottom line, any type of interview question or test will sit poorly with some high quality programmer. Some don't know a language, some have an unusual process, some aren't great communicators, some don't function well with someone staring at them or under immediate pressure... there is no perfect interview method, and surely no way to determine programmer competence outside of their actual accomplishments -- which, even when you can pull it off, is not the same thing as measuring their skills against others, placing them in an objective relationship to the skills of others, either.

Personally -- and this is strictly anecdotal, but reflects many decades of experience -- I've had a lot better luck asking many-possible-answer questions about techniques and areas of knowledge in a friendly, low-pressure atmosphere where the interviewee is made to feel they are welcome and respected the moment they walk in the door.

Summary is wrong.

[chris-chittleborough]

The LWN article is not an essay by Jake Edge. It is in fact a report on a talk given by Jacob Kaplan-Moss.