Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming Businesses IT

The Programming Talent Myth 425

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?"
This discussion has been archived. No new comments can be posted.

The Programming Talent Myth

Comments Filter:
  • by xtal ( 49134 ) on Tuesday May 05, 2015 @08:08AM (#49619609)

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

    • by Sique ( 173459 ) on Tuesday May 05, 2015 @08:22AM (#49619685) Homepage
      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.
      • by xtal ( 49134 )

        ..that's why I put the quantitative measure on those who generate a profit from their skill, or produce a profit on their time for others.

        I am quite certain that curve is U-shaped.

      • by CastrTroy ( 595695 ) on Tuesday May 05, 2015 @10:06AM (#49620523)

        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 [codinghorror.com]. That should be a simple function, and yet a lot of people fail even this simple test.

        • by AthanasiusKircher ( 1333179 ) on Tuesday May 05, 2015 @01:40PM (#49622665)
          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

    • by radtea ( 464814 ) on Tuesday May 05, 2015 @11:26AM (#49621265)

      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=... [tjradcliffe.com]

      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.

  • by Anonymous Coward on Tuesday May 05, 2015 @08:12AM (#49619623)

    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.

    • by Bongo ( 13261 ) on Tuesday May 05, 2015 @08:30AM (#49619743)

      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.

      • by jythie ( 914043 ) on Tuesday May 05, 2015 @08:36AM (#49619799)
        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?'.
        • by pla ( 258480 ) on Tuesday May 05, 2015 @09:41AM (#49620279) Journal
          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.
      • until teachers figure out what drawing really is and what the mind is doing when it is drawing.

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

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

      • 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
    • 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 c

      • by tompaulco ( 629533 ) on Tuesday May 05, 2015 @09:28AM (#49620147) Homepage Journal

        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.

    • 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?

    • by narcc ( 412956 )

      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 (Score:5, Insightful)

    by phantomfive ( 622387 ) on Tuesday May 05, 2015 @08:16AM (#49619647) Journal

    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 (Score:5, Insightful)

      by Registered Coward v2 ( 447531 ) on Tuesday May 05, 2015 @08:34AM (#49619789)

      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.

    • by AmiMoJo ( 196126 )

      Are there any examples of other skills where the distribution is bi-modal? It would be extremely atypical. I think the default assumption has to be that the curve is the classic bell shape, like most skills, unless there is evidence to the contrary.

      More over, I think the point that programming skills can be learned is an important one. In the west we tend to think people have certain innate abilities and weaknesses, like some people are just bad at maths and can't be helped. In some places the assumption is

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

      To be fair, you can spend a great deal of time talking about something and make progress on the issue without solving it.

      For example the current metrics are abysmal so it's worth explaining why they're abysmal. I just was able to delete several thousand lines of JavaScript from one of my projects after a data model change (through code reuse and generalization) -- yet I increased functionality. My manager was confused and thought it was a bad thing to get rid of code like that ... it was absolute dop

    • Re:Measurements (Score:4, Insightful)

      by lgw ( 121541 ) on Tuesday May 05, 2015 @08:43AM (#49619867) Journal

      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.

      • by tnk1 ( 899206 )

        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

    • Bi-modal or not, the less skilled you are as a programmer the more frustrating some parts of programming become. For the more skilled it's fighting boredom on easy work, but they stay productive and looking skilled.

      That could be pushing average programmers to find something more rewarding to do, rather than facing frustration regularly. Some of the merely above average ones are mostly above average in being more prepared to fight through that frustration - I'm one of them, the rest probably just quit.

  • by ohnocitizen ( 1951674 ) on Tuesday May 05, 2015 @08:17AM (#49619655)

    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 (Score:4, Insightful)

    by phantomfive ( 622387 ) on Tuesday May 05, 2015 @08:19AM (#49619665) Journal

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

    • by jythie ( 914043 )
      Thing is, being a '10x programmer' is more about image than objective ability. Given the strength of the 'brilliant asshole' myth, it is one of the major images one can adopt to help convince people that they are brilliant, and they will often get reenforcement out of it since people buy into it.

      You also forget that in many people's eyes, 'normal' programmers not being able to maintain a 'brilliant' one's code is their failing, not the superstar.
    • by PRMan ( 959735 )
      A 10x developer produces 1/10 the code and it still works and is easier to read and maintain and runs faster. It's these multigigabyte codebases (for a 100-page website) we have these days that are written by untalented people.
    • Re:No one wants this (Score:5, Interesting)

      by SQLGuru ( 980662 ) on Tuesday May 05, 2015 @08:59AM (#49619961) Homepage Journal

      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.

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

  • by gatkinso ( 15975 )

    The moment he or she drives someone away, fire them.

    • by jythie ( 914043 )
      If only it worked that way. I have worked with programmers who drive others away, crow, in my exit interview at my last company I specifically referenced another programmers for why I was leaving, and I was not even alone in this! But he was a '10x programmer' and was 'too valuable' to fire. Last I heard he was moving up the ladder because he has 'proven himself as a lead'. 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 h
      • by BVis ( 267028 )

        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 w

  • Assuming his designation is accurate...nine?
  • by ThePhilips ( 752041 ) on Tuesday May 05, 2015 @08:22AM (#49619691) Homepage Journal

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

  • I can't speak to the validity of the articles claims. But I do know that even though I suck at programming, I still keep trying. Luckily some people are patient enough to help me out and they are awesome for doing so.
    • There is plenty of room for people who suck at programming.

      Otherwise the country wouldn't be overrun with low-budget H1-Bs.

    • 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?

    • Are you sure you suck? Perhaps, aren't you just okay?
    • by Xest ( 935314 ) on Tuesday May 05, 2015 @10:52AM (#49621001)

      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.

  • Hmmm ... (Score:5, Insightful)

    by gstoddart ( 321705 ) on Tuesday May 05, 2015 @08:26AM (#49619723) Homepage

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

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

      • Right, but then we're back to "among the group of people who are already programmers" ... which in no way refutes the oft-cited observation that among people learning to program there's a very distinct double-tassel distribution.

        Within the group of people already called programmers, yes, there's going to be variation -- I've certainly known a few who crank out reams of code, which can sometimes make for a good prototype, but which often had to be completely scrapped to turn it into releasable code.

        But I've

    • by PRMan ( 959735 )

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

      What else would you expect these days? People love to spout off without doing any research. It's a favorite pasttime of the era.

  • by jvj24601 ( 178471 ) on Tuesday May 05, 2015 @08:30AM (#49619745)
    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 (Score:4, Informative)

    by fractalus ( 322043 ) on Tuesday May 05, 2015 @08:31AM (#49619753) Homepage

    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.

  • by Craig Cruden ( 3592465 ) on Tuesday May 05, 2015 @08:31AM (#49619755)
    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.
    • 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.

  • by allcoolnameswheretak ( 1102727 ) on Tuesday May 05, 2015 @08:31AM (#49619763)

    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.

    • by PRMan ( 959735 )

      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 repla

      • by gstoddart ( 321705 ) on Tuesday May 05, 2015 @09:12AM (#49620047) Homepage

        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.

  • It is very likely that programming skill (if such a thing actually exists in a measurable sense) is normally distributed. What looks like a bimodal distribution is really just an effect of current employment practices by Google/Facebook/etc. There are people who are "good enough" (measured very poorly by a job interview) to work at one of these "top" firms that pay really well, and everyone else simply isn't good enough. The difference in actual skill between a person who is "good enough" and one who is
  • You can be just a run-of-the-mill average regular prime minister and still hack out c++ code that solves sudoku. Yeah, it is not c++ but simple c masquerading as c++, but thats what you would expect from the average regular prime minister, right?
  • by msobkow ( 48369 ) on Tuesday May 05, 2015 @08:40AM (#49619843) Homepage Journal

    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.

  • And the reason it's bullshit is that it starts from the premise that if you could measure programming ability somehow, its curve would look like the normal distribution.

    Programming ability is exactly the kind of thing that does not fall in a normal distribution. It's not even close to a normal distribution. It's more like wealth distribution, there is no meaningful average.

  • eh (Score:4, Interesting)

    by buddyglass ( 925859 ) on Tuesday May 05, 2015 @08:47AM (#49619887)

    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.

    • by Jeremi ( 14640 )

      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 fa

  • Simple question (Score:4, Insightful)

    by king neckbeard ( 1801738 ) on Tuesday May 05, 2015 @08:53AM (#49619917)

    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.

  • in a paid professional environment, terms like 'rock star' and 'ninja' sound like giggly things our children might say about what they were learning in school today.

    Our team members have a skill level where they started at hire time, and then they learn and grow from there, both in the general languages and in our platform they work with. Nobody comes in as a 'ninja'. The longer they have been here working and learning this environment, the more we can trust them to lead projects. Everyone either improve

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

  • by lkcl ( 517947 ) <lkcl@lkcl.net> on Tuesday May 05, 2015 @09:45AM (#49620323) Homepage

    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.

  • by sribe ( 304414 ) on Tuesday May 05, 2015 @09:48AM (#49620351)

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

  • by Tablizer ( 95088 ) on Tuesday May 05, 2015 @12:03PM (#49621607) Journal

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

  • by Mel ( 21137 ) on Tuesday May 05, 2015 @02:54PM (#49623381) Homepage

    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.

  • by chris-chittleborough ( 771209 ) on Tuesday May 05, 2015 @11:14PM (#49626477) Journal
    The LWN article is not an essay by Jake Edge. It is in fact a report on a talk given by Jacob Kaplan-Moss.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...