An empirical study of working speed differences between software engineers [pdf]
page.mi.fu-berlin.de
An empirical study of working speed differences between software engineers [pdf]
1–10 of 74 posts
Re: An empirical study of working speed differences between software engineers [pdf]
#2In summary, the difference between "fast" programmers and "slow" programmers is not 28 (as per Grant and Sackman folklore), but more in the range 1--7. Specifically, The work time variability tends to be larger for task type “test/debug” (SF50 = 2.4, SF25 = 3.2) and even more for “programming” (SF50 = 2.4, SF25 = 7.1) than it is for “maintain” (SF50 = 1.7, SF25 = 2.4) or for “understand”
(SF50 = 1.8, SF25 = 2.9). Task type “review” is special. It exhibits both low variability
(SF50 = 1.1, SF25 = 1.3) and low skewness.
Re: An empirical study of working speed differences between software engineers [pdf]
#3I think they still found a large difference between the best and worst developers. Another summary (quotes that I can't seem to format):
The main findings from this investigation of the dataset variance.data can be summarized as follows:
The interpersonal variability in working time is rather dif- ferent for different types of tasks.
More robust than comparing the slowest to the fastest in- dividual is a comparison of, for example, the slowest to the fastest quarter (precisely: the medians of the quarters) of the subjects, called S F .
The ratio of slowest versus fastest quarter is rarely larger than 4:1, even for task types with high variability. Typ- ical ratios are in the range 2:1 to 3:1. The data from the Grant/Sackman experiment (with values up to 8:1) is rather unusual in comparison.
Caveat: Maybe most experiments represented in variance.data underestimate the realistic interper- sonal variability somewhat, because in practical contexts the population of software engineering staff will often be more inhomogeneous than the populations (typically CS students) used in most experiments.
Still only little is known about the shape of working time distributions. However, variance.data exhibits a clear trend towards positive skewness for task types with large variability.
The effect size (relative difference of the work time group means) is very different from one experiment to the next. The median is about 14%.
The oft-cited ratio of 28:1 for slowest to fastest work time in the Grant/Sackman experiment is plain wrong. The cor- rect value is 14:1.Re: An empirical study of working speed differences between software engineers [pdf]
#4"The ratio of slowest versus fastest quarter is rarely larger
than 4:1, even for task types with high variability. Typical
ratios are in the range 2:1 to 3:1. The data from
the Grant/Sackman experiment (with values up to 8:1) is
rather unusual in comparison."
Re: An empirical study of working speed differences between software engineers [pdf]
#5I suspect that the most important difference between great and typical engineers is that the great ones make a better product, not that they make it faster. If my hunch is correct, worrying about concepts like "10x" is missing the point.
Re: An empirical study of working speed differences between software engineers [pdf]
#6"The ratio of slowest versus fastest quarter is rarely larger than 4:1, even for task types with high variability. Typical ratios are in the range 2:1 to 3:1. The data from the Grant/Sackman experiment (with values up to 8:1) is rather unusual in comparison."
Even if it isn't the mythical 10x ratio, hiring somebody that can do 3 times more than the next person is a no-brainer. Although I honestly wonder if that baseline is dragged down so hard by all the people that really can't do the job they are supposed to be doing. Programming is hard, and doing it well is even harder. "Everyone can code" movements are great propaganda, but I'll be honest, I've never known anybody that actually could code who wasn't a couple of standard deviations smarter than the average Joe or Jane.
Re: An empirical study of working speed differences between software engineers [pdf]
#7It would be interesting to have biographical sketches of the best and worst developer in this study.
Re: An empirical study of working speed differences between software engineers [pdf]
#8"The ratio of slowest versus fastest quarter is rarely larger than 4:1, even for task types with high variability. Typical ratios are in the range 2:1 to 3:1. The data from the Grant/Sackman experiment (with values up to 8:1) is rather unusual in comparison."
Even if it isn't the mythical 10x ratio, hiring somebody that can do 3 times more than the next person is a no-brainer. Although I honestly wonder if that baseline is dragged down so hard by all the people that really can't do the job they are supposed to be doing. Programming is hard, and doing it well is even harder. "Everyone can code" movements are great propaganda, but I'll be honest, I've never known anybody th…
I'm good at tests where you need to code fast and to a high level of quality. But there is no way is keep that speed up for 2k hours per year.
Another issue is of course the person who replays technical debt on every completed JIRA ticket will probably be a bit slower. And the person who removes lines of code and asks if a feature is really necessary is another beast. All that thinking is going to slow down your LOC per second.
Re: An empirical study of working speed differences between software engineers [pdf]
#9I suspect that the most important difference between great and typical engineers is that the great ones make a better product, not that they make it faster. If my hunch is correct, worrying about concepts like "10x" is missing the point.
I'm not saying anything about you here, but I feel like this is what a typical engineer would like to believe to make themselves feel better, but getting things done faster leaves more time for doing them better. Once you're at that stage, it's a simple matter of discipline.
Re: An empirical study of working speed differences between software engineers [pdf]
#10I'm pretty sure that I'm a "slow" developer. Not in terms of actually coming up with the core fix to a problem that I'm working on (that's actually the most straightforward part of any project) but everything else that follows. That is to say writing clean, well-tested, documented and maintainable code. Is this something to be concerned about long-term or should I just accept that my work will always take a little longer to complete than my fellow developers?