3 ms·

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

• 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.
    • nostrademons 16y ago
      In my experience, there's fairly little difference between programmers in lines of code per hour. The most I've seen is a factor of about 3, measured over a couple years, and it's largely because the slower programmers are working on harder problems (that require more thinking), or the faster ones work longer hours, or the faster ones do more copy & paste. There is, however, a massive (orders of magnitude) difference on impact that the better programmers have. And that largely comes with being familiar with high-leverage development practices, being willing to apply them, and being alert to opportunities where a process can generalize to a large scale and investments in automation are worth it. So for example, one programmer might spend a couple hours tracking down a bug, while another programmer spends a week improving the compiler's diagnostics and then a couple days writing a script that applies that and automatically fixes several hundred occurrences of the bug across the codebase. One programmer might spend a month refactoring 30 or so source files, while another programmer spends that month writing a script that fixes 5000 source files. One programmer might waste 6 years of his life writing Web 2.0 startups that nobody uses, while another might spend 6 years of his life inventing Google. These are all teachable skills, but they can take a while to teach, particularly the ones that rely upon judgment.