10 ms·

I think about Spolsky's post on programmer productivity quite often [1]. I think the most interesting part of the post is when he says, "The mediocre talent ju

by tpatke 15y ago

I think about Spolsky's post on programmer productivity quite often [1]. I think the most interesting part of the post is when he says, "The mediocre talent just never hits the high notes that the top talent hits all the time." Obviously, I wonder if I am a programmer who can hit the high notes and, if not, what it will take to get there. When I read a post like this, I try to apply it to making myself a better programmer in the "high note" sense. Trouble is - it just doesn't apply (and I am a huge fan of Dweck's work). This article is one for the masses - not people who are trying to create the next Google. Motivation, hard work and an ability to learn from mistakes are all necessary, but ultimately not sufficient for our craft. If I had to guess what the missing ingredient is, I would say creativity. Heck - we are programmers. We get immediate feedback on our mistakes all day long and anyone reading this post has most likely gotten really really good and learning from those mistakes. ...but, how many of us are hitting those high notes? [1] http://www.joelonsoftware.com/articles/HighNotes.html http://www.joelonsoftware.com/articles/HighNotes.html

mburney 15y ago
I have seen programmers make the same avoidable mistakes over and over again without learning much from them. Sure, they learn from syntactical errors and perhaps how to avoid specific kinds of errors. But how many programmers will actually re-model their entire coding paradigm in order to improve?
- mekoka 15y ago
  In order to learn from a "mistake" there needs to be some sort of feedback. Many programmers make the same mistake over and over because it hasn't yet come back to seriously bite them in the ass, or because the evidence of it isn't clear. Only then is the mistake corrected and the lesson learnt. For example, in this day and age of fast processors, abundant memory, large hard-drives, you can't expect a novice to put much emphasis on efficiency. He'll code and will run his program just to see the output appear almost instantly. A veteran will look at it and shake her head, but that's because she knows that back in her days, code this inefficient guaranteed that you'd spend the day in the lab just waiting to see the first letter of the output. Don't expect the newbie to learn that lesson any time soon, with his blazingly fast laptop, on which he's working comfortably from his bedroom. Now, hand him one of those snail computers at his next internship and watch the transformation operate.
  - commanda 15y ago
    If it never comes back to bite you (or anyone else) in the ass, was it really a mistake?
    - Splines 15y ago
      True enough, needless optimization is often unnecessary. The difference is that an expert will be able to make a good decision about that trade-off. A novice is restricted to the tools and practices they are familiar with - they might come to the same conclusion, but not for the same reasons.
    - jerf 15y ago
      Taking your question literally and in isolation, no. But the manifestation more relevant to the real world is not having the experience base to realize it's biting you in the ass. Specifically, even though X is working, it could be working better, for less effort. Or another common case is X is not working and you misidentify why ("lazy developers not willing to do the work" instead of "used the wrong paradigm for the job", for instance).
jackpirate 15y ago
It's very easy for us to forget about variance and standard deviation of programmer productivity when all other factors are equal. Let's imagine we have 1000 of the world's best programmers working for a year on creative projects. All of them will try something innovative. Only some of them, however, will succeed. Who succeeds is a function of what projects they were working on. And that, is almost purely random and a result of circumstances. We like to think that Sergey and Larey were more brilliant than anyone else, for example, but the truth is they just stumbled into the right thing at the right time. Don't discredit yourself as a programmer for not yet having a huge stroke of luck.
- bored 15y ago
  And the very best just seem to be "luckier" than the rest...
  - WalterBright 15y ago
    The difference between lucky people and unlucky ones is that the lucky ones were able to recognize opportunity better. I've seen some research on this, but don't have a link handy.
    - simon_weber 15y ago
      I prefer the idea that the lucky ones "made their own luck" by increasing luck surface area. In this view, the lucky may not have recognized opportunity better, just created better opportunities for themselves (through hard work). Even if this notion isn't completely correct, I like how it incentivises working rather than waiting.
      - ryanmolden 15y ago
        Nassim Taleb talks about this, I think in Fooled by Randomness. He couched it in terms of increasing exposure to chance (serendipitous) occurrences via being more social, studying across disciplines, keeping friends whose views differ from yours, etc... Edit: corrected my phone's overzealous auto-correct.
ohyes 15y ago
I think the point of this article is that it doesn't matter if you are top talent. It is detrimental to your growth think that you are. It is better to approach learning anything from a position of humility and interest rather thank thinking that you are hot shit.
- jongraehl 15y ago
  Beware drawing conclusions about causes in the top decile based on averaged effects over the whole distribution. And adults based on studies of kids, etc. But sure, it's suggestive of what you say.
aristus 15y ago
I've thought a lot about creativity by watching the people around me in art and science. I suspect that an important, perhaps defining characteristic of highly creative people is their ability to change their mind at will. (Similar to how a good scientist develops the ability to change his mind utterly when confronted with solid evidence, and change it back when that evidence is refuted.) A factor in that is developing a strong associative memory. This means seeking out many many kinds of knowledge and experiences and constantly trying to connect them together. It's not banging "random" ideas together, because your associative memory filtera it down.
- jilebedev 15y ago
  Article: > unless we experience the unpleasant symptoms of being wrong — that surge of Pe activity a few hundred milliseconds after the error, directing our attention to the very thing we’d like to ignore — the mind will never revise its models tpatke: > it just doesn't apply (and I am a huge fan on Dweck's work). This article is one for the masses - not people who are trying to create the next Google aristus: > defining characteristic of highly creative people is their ability to change their mind at will. ... A factor in that is developing a strong associative memory ... seeking out many many kinds of knowledge and experiences and constantly trying to connect them together Being wrong, persisting, and trying to learn from the mistake takes effort. It's difficult, and I suspect as difficult as (if not directly linked to) exerting self-control. Connecting thought is here: http://psr.sagepub.com/content/11/4/303.short http://psr.sagepub.com/content/11/4/303.short A good question for Moser/Dweck would be: is the physiological response of a child to a mistake a function of their blood glucose levels? I suspect that it is: anecdotally, people are a lot more optimistic and willing to explore an issue instead of yielding to to surface obstacles if they're on a sugar high.
  - invalidOrTaken 15y ago
    | A good question for Moser/Dweck would be: is the physiological response of a child to a mistake a function of their blood glucose levels? I suspect that it is: | anecdotally, people are a lot more optimistic and willing to explore an issue instead of yielding to to surface obstacles if they're on a sugar high. I wondered this as well. Even if it's not necessarily glucose-focused, there are a ton of angles. Depression? The two ends of manic/depressives? Sleep -> mood -> mistake response? Talking to an attractive member of the opposite sex and having it go well/not well?
msg 15y ago
I'm not a zealot for it, but test driven development does shorten the feedback loop in significant ways. You get specific feedback for problems and avoid making the same mistakes twice. When I'm working with code that doesn't have it, runtime errors significantly lengthen the time between insights, as I hunt for the root cause of some bug. The general point is that you do better work in small increments and revisions than you do, like Coleridge, getting high and watching masterpieces spill out of you, like Kubla Khan. You will be less sensitive to small things destroying your work, like Coleridge's visitor. Truish story.
kevinalexbrown 15y ago
EDIT: So I got a coke and thought about this a bit. I like your point, but I feel like maybe the high-noters are high-noters precisely because they're ruthlessly self-critical and growth-minded. Ever see someone who was really good at something cringe after what you thought was an amazing performance, because they missed, e.g. the f6 in Mozart's Queen of the Night? They're better (honest?) at seeing their mistakes, and they're better at addressing them. Maybe that's the natural talent? Aside from the tone, maybe, this article is not 'one for the masses.' Jony Ive didn't just sit down and whip up the iPod, to use Spolsky's example. We don't see the blood/sweat/tears that goes into it. From Ive: One of the hallmarks of our team is this sense of looking to be wrong ... It’s about being excited to be wrong because then you’ve discovered something new. Obviously Ive has the creative ingredient. And some are going to be predisposed with talent. Michael Jordan may have had his famous "4am club" where he hit the court every morning to just drill, but so did Scotty Pippen, and he never hit the Jordan high note clutch performances that make my jaw drop watching 20-year-old replays. So I see your point, that talent matters. But the other way to look at it is that Jordan was just better at learning from his mistakes in those 4am practices. So no, this is not some pedestrian piece of feel-good soup. Great work, in programming, design, anything, is about repeatedly pushing a boundary, recognizing where you messed up, fixing it, and repeating that all over again. The people who do this best are the people who believe that by iterating they can get better. This works even as you get all the way up into the stratosphere of a field. [1] http://www.dailymail.co.uk/home/moslive/article-1367481/Apples-Jonathan-Ive-How-did-British-polytechnic-graduate-design-genius.html#ixzz1nEKjLSAN http://www.dailymail.co.uk/home/moslive/article-1367481/Appl...
- aik 15y ago
  >>Maybe that's the natural talent? It could partially be natural talent, however much of it is nurture. Carol Dweck has proven that the growth-mindset can be taught. Parents, friends, communities, media and school systems alike can promote "fixed" mindset thinking through various means, thus limiting learning from mistakes. It's incredible how much harm someone can do by steering someone off the growth-mindset path.
- jimbokun 15y ago
  And Scottie Pippen only became maybe one of the top 20 basketball players of all time. So maybe there is something to being part of a "4am" club.
einhverfr 15y ago
First as a disclaimer. I have ADD and will never be a great C programmer (I can hack, but my ADD makes it extremely difficult to get the consistency in results that C demands when doing bulk coding, but that's a topic for another time). I have done some C programming and I will do some more. However there are hard limits for me that a lot of other people don't have. Now this being said, in the environments where I work, I have met a lot of top-notch programmers and a much larger number of mediocre programmers who crank out huge quantities of unmaintainable code. And of course unmaintainable code is contagious: if you work with it, the quality of your own code suffers. And so I have come to a contrarian perspective on a lot of this. The difference I think is that the top notch programmers tend to be interested in improving. There is nothing worse than reading through the SQL-Ledger codebase and realizing that despite some modest improvements in security over the years (though not enough IMO) the coding style has never improved (\%$form? Really? Still? And no 'use strict?' what will it take?). Instead they make up for a lack of self-improvement with extra brute force effort in things like testing and debugging. So this leads me to conclude there are two fundamental types of programmers out there: brute force programmers (the majority), and those programmers who substitute quality of effort for quantity of effort. The majority of programmers are mediocre and never hit high notes because they believe that what matters is how much time and effort they put into programming. The other programmers spend less time and effort coding, and more time and effort thinking about coding. They recognize that this is where the key investment lies, and that time spent here saves a lot of effort elsewhere. One problem with programming is that you rarely get immediate feedback on the mistakes that matter---areas like style, clarity, maintainability, and elegance of design. It's only if you go back and question your ability in these areas can you improve. But time spent thinking about these things, going over past efforts and critiquing them, is time that is not spent programming. I sometimes think programming should be learned first through an apprenticeship, then through journeyman programs where an individual learns from many accomplished programmers, and finally certified to take on students.
ak39 15y ago
Spolsky is a wanker. High notes, low notes who cares? The test of the acceptable programmer is in the works he/she creates. And to judge that requires answering the following: 1. Does the software do what it's supposed to do? 2. Does it do what it does efficiently? That's it. Forget wanting to belong to the legions of hallowed programmers who use the latest/best programming languages or frameworks. No programmer hits a low note ... unless they want to. Those are not programmers but itenerant workers just filling in for the time-being. (Which could last 30 years. :) ) Ciao
EricDeb 15y ago
Another thing to consider with Spolsky's student example is that there are a wide variety of experience levels in a programming class IME. I just finished 5 years of CS school (3 years undergrad, 2 grad), and I would attribute the variety in time it takes to complete a project mainly due to experience with the language/project type/etc. There could be kids in the class with 2 years internship experience with the exact language on similar projects and those that have never programmed before. Comparing professionals would be much more useful.

by tpatke 15y ago

mburney 15y ago

I have seen programmers make the same avoidable mistakes over and over again without learning much from them. Sure, they learn from syntactical errors and perhaps how to avoid specific kinds of errors. But how many programmers will actually re-model their entire coding paradigm in order to improve?

mekoka 15y ago
In order to learn from a "mistake" there needs to be some sort of feedback. Many programmers make the same mistake over and over because it hasn't yet come back to seriously bite them in the ass, or because the evidence of it isn't clear. Only then is the mistake corrected and the lesson learnt. For example, in this day and age of fast processors, abundant memory, large hard-drives, you can't expect a novice to put much emphasis on efficiency. He'll code and will run his program just to see the output appear almost instantly. A veteran will look at it and shake her head, but that's because she knows that back in her days, code this inefficient guaranteed that you'd spend the day in the lab just waiting to see the first letter of the output. Don't expect the newbie to learn that lesson any time soon, with his blazingly fast laptop, on which he's working comfortably from his bedroom. Now, hand him one of those snail computers at his next internship and watch the transformation operate.
- commanda 15y ago
  If it never comes back to bite you (or anyone else) in the ass, was it really a mistake?
  - Splines 15y ago
    True enough, needless optimization is often unnecessary. The difference is that an expert will be able to make a good decision about that trade-off. A novice is restricted to the tools and practices they are familiar with - they might come to the same conclusion, but not for the same reasons.
  - jerf 15y ago
    Taking your question literally and in isolation, no. But the manifestation more relevant to the real world is not having the experience base to realize it's biting you in the ass. Specifically, even though X is working, it could be working better, for less effort. Or another common case is X is not working and you misidentify why ("lazy developers not willing to do the work" instead of "used the wrong paradigm for the job", for instance).

jackpirate 15y ago

It's very easy for us to forget about variance and standard deviation of programmer productivity when all other factors are equal. Let's imagine we have 1000 of the world's best programmers working for a year on creative projects. All of them will try something innovative. Only some of them, however, will succeed. Who succeeds is a function of what projects they were working on. And that, is almost purely random and a result of circumstances. We like to think that Sergey and Larey were more brilliant than anyone else, for example, but the truth is they just stumbled into the right thing at the right time. Don't discredit yourself as a programmer for not yet having a huge stroke of luck.

bored 15y ago
And the very best just seem to be "luckier" than the rest...
- WalterBright 15y ago
  The difference between lucky people and unlucky ones is that the lucky ones were able to recognize opportunity better. I've seen some research on this, but don't have a link handy.
  - simon_weber 15y ago
    I prefer the idea that the lucky ones "made their own luck" by increasing luck surface area. In this view, the lucky may not have recognized opportunity better, just created better opportunities for themselves (through hard work). Even if this notion isn't completely correct, I like how it incentivises working rather than waiting.
    - ryanmolden 15y ago
      Nassim Taleb talks about this, I think in Fooled by Randomness. He couched it in terms of increasing exposure to chance (serendipitous) occurrences via being more social, studying across disciplines, keeping friends whose views differ from yours, etc... Edit: corrected my phone's overzealous auto-correct.

ohyes 15y ago

I think the point of this article is that it doesn't matter if you are top talent. It is detrimental to your growth think that you are. It is better to approach learning anything from a position of humility and interest rather thank thinking that you are hot shit.

jongraehl 15y ago
Beware drawing conclusions about causes in the top decile based on averaged effects over the whole distribution. And adults based on studies of kids, etc. But sure, it's suggestive of what you say.

aristus 15y ago

I've thought a lot about creativity by watching the people around me in art and science. I suspect that an important, perhaps defining characteristic of highly creative people is their ability to change their mind at will. (Similar to how a good scientist develops the ability to change his mind utterly when confronted with solid evidence, and change it back when that evidence is refuted.) A factor in that is developing a strong associative memory. This means seeking out many many kinds of knowledge and experiences and constantly trying to connect them together. It's not banging "random" ideas together, because your associative memory filtera it down.

jilebedev 15y ago
Article: > unless we experience the unpleasant symptoms of being wrong — that surge of Pe activity a few hundred milliseconds after the error, directing our attention to the very thing we’d like to ignore — the mind will never revise its models tpatke: > it just doesn't apply (and I am a huge fan on Dweck's work). This article is one for the masses - not people who are trying to create the next Google aristus: > defining characteristic of highly creative people is their ability to change their mind at will. ... A factor in that is developing a strong associative memory ... seeking out many many kinds of knowledge and experiences and constantly trying to connect them together Being wrong, persisting, and trying to learn from the mistake takes effort. It's difficult, and I suspect as difficult as (if not directly linked to) exerting self-control. Connecting thought is here: http://psr.sagepub.com/content/11/4/303.short http://psr.sagepub.com/content/11/4/303.short A good question for Moser/Dweck would be: is the physiological response of a child to a mistake a function of their blood glucose levels? I suspect that it is: anecdotally, people are a lot more optimistic and willing to explore an issue instead of yielding to to surface obstacles if they're on a sugar high.
- invalidOrTaken 15y ago
  | A good question for Moser/Dweck would be: is the physiological response of a child to a mistake a function of their blood glucose levels? I suspect that it is: | anecdotally, people are a lot more optimistic and willing to explore an issue instead of yielding to to surface obstacles if they're on a sugar high. I wondered this as well. Even if it's not necessarily glucose-focused, there are a ton of angles. Depression? The two ends of manic/depressives? Sleep -> mood -> mistake response? Talking to an attractive member of the opposite sex and having it go well/not well?

msg 15y ago

I'm not a zealot for it, but test driven development does shorten the feedback loop in significant ways. You get specific feedback for problems and avoid making the same mistakes twice. When I'm working with code that doesn't have it, runtime errors significantly lengthen the time between insights, as I hunt for the root cause of some bug. The general point is that you do better work in small increments and revisions than you do, like Coleridge, getting high and watching masterpieces spill out of you, like Kubla Khan. You will be less sensitive to small things destroying your work, like Coleridge's visitor. Truish story.

kevinalexbrown 15y ago

EDIT: So I got a coke and thought about this a bit. I like your point, but I feel like maybe the high-noters are high-noters precisely because they're ruthlessly self-critical and growth-minded. Ever see someone who was really good at something cringe after what you thought was an amazing performance, because they missed, e.g. the f6 in Mozart's Queen of the Night? They're better (honest?) at seeing their mistakes, and they're better at addressing them. Maybe that's the natural talent? Aside from the tone, maybe, this article is not 'one for the masses.' Jony Ive didn't just sit down and whip up the iPod, to use Spolsky's example. We don't see the blood/sweat/tears that goes into it. From Ive: One of the hallmarks of our team is this sense of looking to be wrong ... It’s about being excited to be wrong because then you’ve discovered something new. Obviously Ive has the creative ingredient. And some are going to be predisposed with talent. Michael Jordan may have had his famous "4am club" where he hit the court every morning to just drill, but so did Scotty Pippen, and he never hit the Jordan high note clutch performances that make my jaw drop watching 20-year-old replays. So I see your point, that talent matters. But the other way to look at it is that Jordan was just better at learning from his mistakes in those 4am practices. So no, this is not some pedestrian piece of feel-good soup. Great work, in programming, design, anything, is about repeatedly pushing a boundary, recognizing where you messed up, fixing it, and repeating that all over again. The people who do this best are the people who believe that by iterating they can get better. This works even as you get all the way up into the stratosphere of a field. [1] http://www.dailymail.co.uk/home/moslive/article-1367481/Apples-Jonathan-Ive-How-did-British-polytechnic-graduate-design-genius.html#ixzz1nEKjLSAN http://www.dailymail.co.uk/home/moslive/article-1367481/Appl...

aik 15y ago
>>Maybe that's the natural talent? It could partially be natural talent, however much of it is nurture. Carol Dweck has proven that the growth-mindset can be taught. Parents, friends, communities, media and school systems alike can promote "fixed" mindset thinking through various means, thus limiting learning from mistakes. It's incredible how much harm someone can do by steering someone off the growth-mindset path.
jimbokun 15y ago
And Scottie Pippen only became maybe one of the top 20 basketball players of all time. So maybe there is something to being part of a "4am" club.

einhverfr 15y ago

First as a disclaimer. I have ADD and will never be a great C programmer (I can hack, but my ADD makes it extremely difficult to get the consistency in results that C demands when doing bulk coding, but that's a topic for another time). I have done some C programming and I will do some more. However there are hard limits for me that a lot of other people don't have. Now this being said, in the environments where I work, I have met a lot of top-notch programmers and a much larger number of mediocre programmers who crank out huge quantities of unmaintainable code. And of course unmaintainable code is contagious: if you work with it, the quality of your own code suffers. And so I have come to a contrarian perspective on a lot of this. The difference I think is that the top notch programmers tend to be interested in improving. There is nothing worse than reading through the SQL-Ledger codebase and realizing that despite some modest improvements in security over the years (though not enough IMO) the coding style has never improved (\%$form? Really? Still? And no 'use strict?' what will it take?). Instead they make up for a lack of self-improvement with extra brute force effort in things like testing and debugging. So this leads me to conclude there are two fundamental types of programmers out there: brute force programmers (the majority), and those programmers who substitute quality of effort for quantity of effort. The majority of programmers are mediocre and never hit high notes because they believe that what matters is how much time and effort they put into programming. The other programmers spend less time and effort coding, and more time and effort thinking about coding. They recognize that this is where the key investment lies, and that time spent here saves a lot of effort elsewhere. One problem with programming is that you rarely get immediate feedback on the mistakes that matter---areas like style, clarity, maintainability, and elegance of design. It's only if you go back and question your ability in these areas can you improve. But time spent thinking about these things, going over past efforts and critiquing them, is time that is not spent programming. I sometimes think programming should be learned first through an apprenticeship, then through journeyman programs where an individual learns from many accomplished programmers, and finally certified to take on students.

ak39 15y ago

Spolsky is a wanker. High notes, low notes who cares? The test of the acceptable programmer is in the works he/she creates. And to judge that requires answering the following: 1. Does the software do what it's supposed to do? 2. Does it do what it does efficiently? That's it. Forget wanting to belong to the legions of hallowed programmers who use the latest/best programming languages or frameworks. No programmer hits a low note ... unless they want to. Those are not programmers but itenerant workers just filling in for the time-being. (Which could last 30 years. :) ) Ciao

EricDeb 15y ago

Another thing to consider with Spolsky's student example is that there are a wide variety of experience levels in a programming class IME. I just finished 5 years of CS school (3 years undergrad, 2 grad), and I would attribute the variety in time it takes to complete a project mainly due to experience with the language/project type/etc. There could be kids in the class with 2 years internship experience with the exact language on similar projects and those that have never programmed before. Comparing professionals would be much more useful.