Slashdot Mirror
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?"
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?"
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.
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.
"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.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
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.
Lost at C:>. Found at C.
Let me know if you have any other questions.
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
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.
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.
"Those that start by burning books, will end by burning men."