5 ms·

There's totally a selection effect going on here. - The professor gets to pick the problems; of course he picks ones he can solve quickly and easily. - The st

by abeppu 16y ago

There's totally a selection effect going on here. - The professor gets to pick the problems; of course he picks ones he can solve quickly and easily. - The students are taking a class from this professor; presumably they lack certain skills or knowledge which he has, and which will be developed during the assignments. When we normally observe '10X' differences in programmer productivity, it's not the case that one of the programmers being measured is picking the tasks for all the others, and that the others being tested are selected on the basis of not knowing (or having only recently been introduced to) central concepts required for those tasks. Even if his measurement of the students' programming time is solid, and even ignoring that he and his students have different incentives (his students don't necessarily benefit from speeding through assignments), of course you see a dramatically wider difference in programming speed in this case than in most contexts.

sophacles 16y ago
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.
- 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.
webvampires 16y ago
You got some points. I think programming is like looking up in dictionary. It's much faster if you use an electronic dictionary. Buy it's even faster to forget that word. Using a paper dictionary is fun. It's slower but will help you remember the word better. The students are much slower than the professor, but they may learn much more than the professor. So I don't think speed them up is really important.

by abeppu 16y ago

sophacles 16y ago

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

webvampires 16y ago

You got some points. I think programming is like looking up in dictionary. It's much faster if you use an electronic dictionary. Buy it's even faster to forget that word. Using a paper dictionary is fun. It's slower but will help you remember the word better. The students are much slower than the professor, but they may learn much more than the professor. So I don't think speed them up is really important.