4 ms·

The tone of your comment suggests you think the guy is bragging or showing off, or something -- I really doubt it. Maybe the guy is trying to be a better teach

The tone of your comment suggests you think the guy is bragging or showing off, or something -- I really doubt it. Maybe the guy is trying to be a better teacher? Maybe he thinks that there is a real effect aside from the selection effect you observe, and is trying to maximize his teaching? Maybe he just wants his students to do well? I submit that the answer to all these is yes. My evidence is that fact that the article ends with questions about how people learn to program well so he can incorporate it into his course.

Tycho 16y ago
If the 'some programmers can be often 10x more productive than their colleagues' statistic is interesting, then this one is too. The 10x probably refers to experienced developers on both sides of the equation; this statistic is more like 'talented beginner' vs 'talented and experienced expert.' It would be interesting to see other calculations like this. If you can work out exactly what makes someone 45x more productive then maybe you can hire/freelance more efficiently for individual tasks.
- vog 16y ago
  > If you can work out exactly what makes someone 45x more productive then maybe you can hire/freelance more efficiently for individual tasks. You don't need a study to figure that out. When your project needs help in a specific area, just hire someone who is an expert in the area. No matter if that person is clever or even talented: As long as (s)he is clearly experienced in that field, (s)he will work a lot more efficiently than anyone else in your team. And of course you should have someone in your present team working with him/her or at least reading and adapting her/his code, so you get more people of your team up to speed. Also, that way you'll notice timely in case the expert status isn't justified (i.e. in case the "expert" wasn't one).
joe_the_user 16y ago
The "some programmers are X times faster than others" phrase is extraordinarily strong and in my opinion destructive meme. The reason believe this meme is destructive is because it mostly powers the approach of "if there's a problem with the development process, it's because we have the wrong people" rather than "we have the wrong methodology, we have a broken relationship between customer and programmer" or any approach that could get your existing people working smarter. In any case, A computer science teacher should, at least, be well aware that a post like this is feeding the meme. Concomitantly, anything that debunks the meme is worthwhile.
- Peaker 16y ago
  I find it hard to believe that some programmers don't believe in the huge productivity differences between developers. Of the people I personally know, there's absolutely no circumstances under which the slower developers could reach 1/5th of the speed of the fastest developers. There's just a huge gap and it's not just methodology. If you haven't witnessed it, you must have been put in very homogeneous environments.
  - sophacles 16y ago
    Also, if a methodology change speeds up the slow developers by x%, it will probably speed up the fast developers by x%. One exception to this is when workflow/task splitting is properly done. Then the "good devs" can do the hard stuff, and create the toolset/primitives for the rest to used to build the product. This split will make the "lesser" devs more productive while making the "good devs" the same amount of productive.
  - joe_the_user 16y ago
    I certainly have seen huge gaps in apparent ability. Usually, the "slow" programmers simply don't know how accomplish certain things - for some tasks, I am infinitely faster than an "average programmer" - for example, if the average programmer doesn't understand what a recursive descent parser is or doesn't understand that a database require logical constraints. However, a team's productivity can be made N times greater if said adopts a coherent process, including education to fill in the gaps of "unproductive" programmers. It is certainly true that a certain percentage of unproductive programmers would rather quit than upgrade themselves. I've worked with them. But a management approach of demanding a willingness to learn will give you an environment 100x more pleasant than a management approach of shouting "we want A-players". And said approach might indeed improve the total productivity of the team.
    - Peaker 16y ago
      I agree that the less productive programmers ought to be willing to learn and can improve. But at least in some of the cases I know, the difference in productivity is based on a couple of extra decades of intensive experience (fanatic code-all-day experience) and does not get narrowed down significantly by studying new techniques. I agree these are the outliers, though.
abeppu 16y ago
I didn't think he was bragging, and I'm totally willing to believe that he just wants to teach better. I just think that he's wrong to believe that (a) the 45x difference is surprising, given the way he seems to have taken his measurements, (b) that given his observed 45x difference, we should then expect there would be a similar 45x difference in programming speed on tasks not based around the material in his course, and (c) that this is evidence of some sort of deficiency on the part of his students that he as an educator should fix. I don't think his problem is ego; I think his problem is an unusually flawed way of comparing programming speed.

Tycho 16y ago

If the 'some programmers can be often 10x more productive than their colleagues' statistic is interesting, then this one is too. The 10x probably refers to experienced developers on both sides of the equation; this statistic is more like 'talented beginner' vs 'talented and experienced expert.' It would be interesting to see other calculations like this. If you can work out exactly what makes someone 45x more productive then maybe you can hire/freelance more efficiently for individual tasks.

vog 16y ago
> If you can work out exactly what makes someone 45x more productive then maybe you can hire/freelance more efficiently for individual tasks. You don't need a study to figure that out. When your project needs help in a specific area, just hire someone who is an expert in the area. No matter if that person is clever or even talented: As long as (s)he is clearly experienced in that field, (s)he will work a lot more efficiently than anyone else in your team. And of course you should have someone in your present team working with him/her or at least reading and adapting her/his code, so you get more people of your team up to speed. Also, that way you'll notice timely in case the expert status isn't justified (i.e. in case the "expert" wasn't one).

joe_the_user 16y ago

The "some programmers are X times faster than others" phrase is extraordinarily strong and in my opinion destructive meme. The reason believe this meme is destructive is because it mostly powers the approach of "if there's a problem with the development process, it's because we have the wrong people" rather than "we have the wrong methodology, we have a broken relationship between customer and programmer" or any approach that could get your existing people working smarter. In any case, A computer science teacher should, at least, be well aware that a post like this is feeding the meme. Concomitantly, anything that debunks the meme is worthwhile.

Peaker 16y ago
I find it hard to believe that some programmers don't believe in the huge productivity differences between developers. Of the people I personally know, there's absolutely no circumstances under which the slower developers could reach 1/5th of the speed of the fastest developers. There's just a huge gap and it's not just methodology. If you haven't witnessed it, you must have been put in very homogeneous environments.
- sophacles 16y ago
  Also, if a methodology change speeds up the slow developers by x%, it will probably speed up the fast developers by x%. One exception to this is when workflow/task splitting is properly done. Then the "good devs" can do the hard stuff, and create the toolset/primitives for the rest to used to build the product. This split will make the "lesser" devs more productive while making the "good devs" the same amount of productive.
- joe_the_user 16y ago
  I certainly have seen huge gaps in apparent ability. Usually, the "slow" programmers simply don't know how accomplish certain things - for some tasks, I am infinitely faster than an "average programmer" - for example, if the average programmer doesn't understand what a recursive descent parser is or doesn't understand that a database require logical constraints. However, a team's productivity can be made N times greater if said adopts a coherent process, including education to fill in the gaps of "unproductive" programmers. It is certainly true that a certain percentage of unproductive programmers would rather quit than upgrade themselves. I've worked with them. But a management approach of demanding a willingness to learn will give you an environment 100x more pleasant than a management approach of shouting "we want A-players". And said approach might indeed improve the total productivity of the team.
  - Peaker 16y ago
    I agree that the less productive programmers ought to be willing to learn and can improve. But at least in some of the cases I know, the difference in productivity is based on a couple of extra decades of intensive experience (fanatic code-all-day experience) and does not get narrowed down significantly by studying new techniques. I agree these are the outliers, though.

abeppu 16y ago

I didn't think he was bragging, and I'm totally willing to believe that he just wants to teach better. I just think that he's wrong to believe that (a) the 45x difference is surprising, given the way he seems to have taken his measurements, (b) that given his observed 45x difference, we should then expect there would be a similar 45x difference in programming speed on tasks not based around the material in his course, and (c) that this is evidence of some sort of deficiency on the part of his students that he as an educator should fix. I don't think his problem is ego; I think his problem is an unusually flawed way of comparing programming speed.