7 ms·

An empirical study of working speed differences between software engineers [pdf]

60 points by mikebike 10y ago

ivan_ah 10y ago
In 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.
- jsvaughan 10y ago
  It also say this: "Thus, if we ignore the most extreme cases, the differences between the slowest and the fastest individuals are by far not as dramatic as the 28:1 figure suggests" Why would you ignore the most extreme cases?
projectramo 10y ago
I 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.
questionr 10y ago
"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."
- douche 10y ago
  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.
  - bbcbasic 10y ago
    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.
  - Scarblac 10y ago
    I'm much slower these days than I used to be, and it's because I'm bored. That I need to do my work with a web browser, usually necessarily with internet access doesn't help.
    - drumdance 10y ago
      For the last year I've been working on a project that has a complex toolchain, such that every time I hit cmd-s I have to wait 2-5 seconds before I can reload the browser to see the changes. It's remarkable how easily I can get distracted in that short interval, especially if I experience it dozens of times per day. For the last couple days I've been doing Project Euler with Ruby and the lack of lag time translates into much better focus.
umanwizard 10y ago
I 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.
- snoman 10y ago
  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.
  - enraged_camel 10y ago
    >>but getting things done faster leaves more time for doing them better. I don't buy it. Sometimes you need to do things deliberately slowly in order to think everything through. All the use cases, the potential edge cases, failure modes, and so on. IMO a "10x" programmer is someone who knows when to crank out code and when to take things slow.
  - verinus 10y ago
    hehe in my experience once it's done, it's done- no time to make it better as there is the next feature up waiting and the customer does not buy quality only "quantity" (of features,...)
    - beambot 10y ago
      Is your experience in consulting...?
  - amazingman 10y ago
    >getting things done faster leaves more time for doing them better I'd love to believe that, but it assumes that the incoming rate of things to be done is and will remain lower than your sustainable velocity. In practice, that "more time for doing them better" has a significant chance of becoming additional technical debt.
iamleppert 10y ago
It would be interesting to have biographical sketches of the best and worst developer in this study.
philangist 10y ago
I'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?
- ScottBurson 10y ago
  If you're saying that your code is actually cleaner, better-tested, and better-documented than that of your fellow developers who seem to work faster, then I don't think you have anything to worry about, as long as you find a job where the value of those things is understood.
- ktRolster 10y ago
  Is this something to be concerned about long-term Don't be concerned about it, but try to get faster.
- Joeri 10y ago
  One of the slower developers on my team is also very precise and methodical. He gets those tasks which require those attributes. It would be difficult to replace him.
- BurningFrog 10y ago
  Find fast people to pair program with. You'll learn some good speedup techniques.
  - fapjacks 10y ago
    This is really a fantastic suggestion! Pair programming can't be advocated enough. I used to think it was stupid many years ago, and then I made friends with a guy who'd been programming longer than I'd been alive. We'd both stay late and shared an office, and in the evenings he started mentoring me, and we'd pair program. I think there is no better way for bringing programmers up to speed (whether junior-senior or slow-fast or new-old or whatever). Also, having tried a variety of interviewing techniques, I find pair programming to have one of the highest concentrations of useful information about a candidate. Work sample being another.
naveen99 10y ago
I would think the speed ratio between the best and worst programmers has to be infinite. Some programmers simply cannot accomplish a task. Once they die you may as well divide by infinity. For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks. Iq just a standin for mental compute capacity.
- Dr_tldr 10y ago
  Surely you must realize how ridiculous that sounds. You can build basically anything (including a kernel) by working from tutorials and starter projects, then hacking through it. Someone's solution may be extremely sub-optimal, but I've yet to see a programming task that wouldn't to googling and persistence. Inventing Calculus was hard, but virtually anyone can learn to pass a Calculus test given enough time and incentives.
  - naveen99 10y ago
    Most programming tasks don't have tutorials. Programming tasks in general are more like inventing then passing a test on some book material. Also like you say, everyone won't pass calculus. Not even programmers.
  - laksjd 10y ago
    Imagine you're given a problem that is completely novel in its description yet is actually reducible in some non-trivial way to a well-known NP-complete problem that has great probabilistic algorithms available for it. Googling the original problem description will (for a novel formulation of the problem) not result in any advantage and implementing a standard algorithm will not work if you need n to be large for your application. I will admit that it's a slightly contrived example ;)
    - saiya-jin 10y ago
      you just described what maybe 0.001% devs will face, so not really... that's not how studies are done nor intended
lifeisstillgood 10y ago
I want to start the "Slow Code" movement after the slow food movement. Yesterday at a clients code base I was under pressure to fix a thing, and the obvious approach was adding gobs more code, quickly implementing the most obvious route. And after a (inordinately long) time reading, the light bulb moment happened and I added a single line of code. In my view, when you are in the business of making Seven-League Boots, you don't need to sprint. Yes we want to deliver products quickly, but the link between good products, effective business and speed of code writing is tenuous at best. Take your time, line up your shots, and be sure you are a value multiplier. (That's the real 10x programmer. 10x as valuable. That might mean using good SEO techniques to get paying customers, but using boring old SQL back ends) (Link to the years old article I have not written yet, comments welcome http://www.mikadosoftware.com/articles/slowcodemovement http://www.mikadosoftware.com/articles/slowcodemovement)
- codingmyway 10y ago
  That's so true. The 10x programmers are those that make everyone else's work faster and more accurate. To me the main job of a lead dev is setting up all the boring processes of build scripts, continuous deployment, package libraries, testing environments etc., that make the other developer's jobs easier.
jondubois 10y ago
Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher quality code. It's MUCH better to have an engineer which takes 3 days to implement a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year than to have an engineer which takes 4 hours to build that same feature but in such a way that the feature has to be revised 10 times by 5 different engineers within the course of the year. The second approach actually consumes much more time in the medium and long term. By putting too much pressure on engineers to implement features quickly, you encourage them to create technical debt which another engineer will have to deal with later. It's basically a blame-shifting strategy.
- modarts 10y ago
  How do you explain that to companies that follow the Google interviewing model?
  - fredophile 10y ago
    What do you mean by "Google interviewing model"? Are you suggesting that this is a problem at Google and companies that interview the way it does?
    - ghgfhgfhn 10y ago
      I think he means: The Google culture is built around cerebral competition. The drive to dominate ones peers, possessed by many technical types, is used to create a fiercely competitive atmosphere. This competition is used to drive productivity. The trouble with this is that it is difficult to measure code quality but easy to measure how quickly the code is produced. Thus within highly competitive environments code tends to be produced as quickly as possible, rather than as well as possible. Of course this is debatable and if true, is only a tendency...
    - ForHackernews 10y ago
      A "dead" (or shadowbanned?) user replied to you: << ghgfhgfhn 26 minutes ago [dead] [-] I think he means: The Google culture is built around cerebral competition. The drive to dominate ones peers, possessed by many technical types, is used to create a fiercely competitive atmosphere. This competition is used to drive productivity. The trouble with this is that it is difficult to measure code quality but easy to measure how quickly the code is produced. Thus within highly competitive environments code tends to be produced as quickly as possible, rather than as well as possible. Of course this is debatable and if true, is only a tendency...>>
davidgerard 10y ago
(2000)
kpil 10y ago
I think that this test is only indicative, and the long time real world ratio is much higher. Inefficient and complicated solutions build up and the mediocre developer ends up fixing old problems. (slow is just an indication of mediocre) Unfortunately the long term effects are not visible until after a long time (duh), hiding the individual differences.
SFJulie 10y ago
The Grant Sackman experiment, often quoted, rarely reproduced. To «prove» a 10x programmer existence you would need a bi-modal repartition on the percentile of workers/speed. The grant sackman/peopleware/The Mythical Man Month all try to answer a question that is tricky : what makes someone creative productive? People focus on the speed. But they are just forgetting the most important part of the experiment. One of the most important part of G/S experiment that everybody forget is the lack of correlation between performance and 1) diploma 2) experience after 2 years of practice. Having done more than one job, other fields of works that are also creativity based, the «feeling» was that it is not only about coders but musicians, intellectual professions, journalists, project manager... What are the implication of the lack of relation between diploma and experience? 1) Diploma are overpriced, the job market is artificially skewed in favor of those who have the money for it; 2) New devs are underpaid, old devs overpaid. The burden of the proof that a diploma/experience is relevant for a job should be in the hand of the one selling diploma. Diploma especially in computer science seems to be a SCAM The effect of this scam is : 1) young workers enslaved by loans in jobs they may not be good at/liking; 2) a rigid job market that prevent people from moving hence artificially creating difficulties to have full employment 3) an artificial exacerbated competition resulting in cheating from both sides.
Fede_V 10y ago
I have a feeling that implementation speed is an instance of Goodhart's Law (https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law). If you keep everything constant (code quality, amount of tests, documentation, etc) then a faster engineer is obviously better. However, if you start using speed as a criteria to judge engineers, then the easiest way to increase speed is to sacrifice things which make code maintainable and modular. Finding metrics which work well even when people try to game them is incredibly difficult (if not impossible).
alephnil 10y ago
From the article: > [] Three of the twelve subjects did not use the recommended high-level language JTS for solving the task, but rather programmed in assembly language instead. Two of these three in fact required the longest working times of all subjects. One might argue that the decision for using assembly is part of the individual differences, but presumably most programmers would not agree that doing the program in assembly is the same task as doing it in a high-level language. In my experience, making the right decisions like that is the real difference between good and not so good programmers. Good programmers do on average better choices that results in less code, code that is easier to maintain and reason about, and choosing language and architecture that fit the problem at hand. It is not that good programmers develop so much faster usually.

60 points by mikebike 10y ago

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

jsvaughan 10y ago
It also say this: "Thus, if we ignore the most extreme cases, the differences between the slowest and the fastest individuals are by far not as dramatic as the 28:1 figure suggests" Why would you ignore the most extreme cases?

projectramo 10y ago

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

questionr 10y ago

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

douche 10y ago
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.
- bbcbasic 10y ago
  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.
- Scarblac 10y ago
  I'm much slower these days than I used to be, and it's because I'm bored. That I need to do my work with a web browser, usually necessarily with internet access doesn't help.
  - drumdance 10y ago
    For the last year I've been working on a project that has a complex toolchain, such that every time I hit cmd-s I have to wait 2-5 seconds before I can reload the browser to see the changes. It's remarkable how easily I can get distracted in that short interval, especially if I experience it dozens of times per day. For the last couple days I've been doing Project Euler with Ruby and the lack of lag time translates into much better focus.

umanwizard 10y ago

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

snoman 10y ago
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.
- enraged_camel 10y ago
  >>but getting things done faster leaves more time for doing them better. I don't buy it. Sometimes you need to do things deliberately slowly in order to think everything through. All the use cases, the potential edge cases, failure modes, and so on. IMO a "10x" programmer is someone who knows when to crank out code and when to take things slow.
- verinus 10y ago
  hehe in my experience once it's done, it's done- no time to make it better as there is the next feature up waiting and the customer does not buy quality only "quantity" (of features,...)
  - beambot 10y ago
    Is your experience in consulting...?
- amazingman 10y ago
  >getting things done faster leaves more time for doing them better I'd love to believe that, but it assumes that the incoming rate of things to be done is and will remain lower than your sustainable velocity. In practice, that "more time for doing them better" has a significant chance of becoming additional technical debt.

iamleppert 10y ago

It would be interesting to have biographical sketches of the best and worst developer in this study.

philangist 10y ago

I'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?

ScottBurson 10y ago
If you're saying that your code is actually cleaner, better-tested, and better-documented than that of your fellow developers who seem to work faster, then I don't think you have anything to worry about, as long as you find a job where the value of those things is understood.
ktRolster 10y ago
Is this something to be concerned about long-term Don't be concerned about it, but try to get faster.
Joeri 10y ago
One of the slower developers on my team is also very precise and methodical. He gets those tasks which require those attributes. It would be difficult to replace him.
BurningFrog 10y ago
Find fast people to pair program with. You'll learn some good speedup techniques.
- fapjacks 10y ago
  This is really a fantastic suggestion! Pair programming can't be advocated enough. I used to think it was stupid many years ago, and then I made friends with a guy who'd been programming longer than I'd been alive. We'd both stay late and shared an office, and in the evenings he started mentoring me, and we'd pair program. I think there is no better way for bringing programmers up to speed (whether junior-senior or slow-fast or new-old or whatever). Also, having tried a variety of interviewing techniques, I find pair programming to have one of the highest concentrations of useful information about a candidate. Work sample being another.

naveen99 10y ago

I would think the speed ratio between the best and worst programmers has to be infinite. Some programmers simply cannot accomplish a task. Once they die you may as well divide by infinity. For every task you need some minimal iq. Some tasks need higher iq than others. A programmer is someone who can at least do the least iq requiring task. He will fail on some more difficult tasks. Iq just a standin for mental compute capacity.

Dr_tldr 10y ago
Surely you must realize how ridiculous that sounds. You can build basically anything (including a kernel) by working from tutorials and starter projects, then hacking through it. Someone's solution may be extremely sub-optimal, but I've yet to see a programming task that wouldn't to googling and persistence. Inventing Calculus was hard, but virtually anyone can learn to pass a Calculus test given enough time and incentives.
- naveen99 10y ago
  Most programming tasks don't have tutorials. Programming tasks in general are more like inventing then passing a test on some book material. Also like you say, everyone won't pass calculus. Not even programmers.
- laksjd 10y ago
  Imagine you're given a problem that is completely novel in its description yet is actually reducible in some non-trivial way to a well-known NP-complete problem that has great probabilistic algorithms available for it. Googling the original problem description will (for a novel formulation of the problem) not result in any advantage and implementing a standard algorithm will not work if you need n to be large for your application. I will admit that it's a slightly contrived example ;)
  - saiya-jin 10y ago
    you just described what maybe 0.001% devs will face, so not really... that's not how studies are done nor intended

lifeisstillgood 10y ago

I want to start the "Slow Code" movement after the slow food movement. Yesterday at a clients code base I was under pressure to fix a thing, and the obvious approach was adding gobs more code, quickly implementing the most obvious route. And after a (inordinately long) time reading, the light bulb moment happened and I added a single line of code. In my view, when you are in the business of making Seven-League Boots, you don't need to sprint. Yes we want to deliver products quickly, but the link between good products, effective business and speed of code writing is tenuous at best. Take your time, line up your shots, and be sure you are a value multiplier. (That's the real 10x programmer. 10x as valuable. That might mean using good SEO techniques to get paying customers, but using boring old SQL back ends) (Link to the years old article I have not written yet, comments welcome http://www.mikadosoftware.com/articles/slowcodemovement http://www.mikadosoftware.com/articles/slowcodemovement)

codingmyway 10y ago
That's so true. The 10x programmers are those that make everyone else's work faster and more accurate. To me the main job of a lead dev is setting up all the boring processes of build scripts, continuous deployment, package libraries, testing environments etc., that make the other developer's jobs easier.

jondubois 10y ago

Initial implementation speed is one of the least important parameters in software engineering. Senior engineers are generally a bit slower but produce higher quality code. It's MUCH better to have an engineer which takes 3 days to implement a feature in such a way that it doesn't need to be revised/fixed again for at least 1 year than to have an engineer which takes 4 hours to build that same feature but in such a way that the feature has to be revised 10 times by 5 different engineers within the course of the year. The second approach actually consumes much more time in the medium and long term. By putting too much pressure on engineers to implement features quickly, you encourage them to create technical debt which another engineer will have to deal with later. It's basically a blame-shifting strategy.

modarts 10y ago
How do you explain that to companies that follow the Google interviewing model?
- fredophile 10y ago
  What do you mean by "Google interviewing model"? Are you suggesting that this is a problem at Google and companies that interview the way it does?
  - ghgfhgfhn 10y ago
    I think he means: The Google culture is built around cerebral competition. The drive to dominate ones peers, possessed by many technical types, is used to create a fiercely competitive atmosphere. This competition is used to drive productivity. The trouble with this is that it is difficult to measure code quality but easy to measure how quickly the code is produced. Thus within highly competitive environments code tends to be produced as quickly as possible, rather than as well as possible. Of course this is debatable and if true, is only a tendency...
  - ForHackernews 10y ago
    A "dead" (or shadowbanned?) user replied to you: << ghgfhgfhn 26 minutes ago [dead] [-] I think he means: The Google culture is built around cerebral competition. The drive to dominate ones peers, possessed by many technical types, is used to create a fiercely competitive atmosphere. This competition is used to drive productivity. The trouble with this is that it is difficult to measure code quality but easy to measure how quickly the code is produced. Thus within highly competitive environments code tends to be produced as quickly as possible, rather than as well as possible. Of course this is debatable and if true, is only a tendency...>>

davidgerard 10y ago

(2000)

kpil 10y ago

I think that this test is only indicative, and the long time real world ratio is much higher. Inefficient and complicated solutions build up and the mediocre developer ends up fixing old problems. (slow is just an indication of mediocre) Unfortunately the long term effects are not visible until after a long time (duh), hiding the individual differences.

SFJulie 10y ago

The Grant Sackman experiment, often quoted, rarely reproduced. To «prove» a 10x programmer existence you would need a bi-modal repartition on the percentile of workers/speed. The grant sackman/peopleware/The Mythical Man Month all try to answer a question that is tricky : what makes someone creative productive? People focus on the speed. But they are just forgetting the most important part of the experiment. One of the most important part of G/S experiment that everybody forget is the lack of correlation between performance and 1) diploma 2) experience after 2 years of practice. Having done more than one job, other fields of works that are also creativity based, the «feeling» was that it is not only about coders but musicians, intellectual professions, journalists, project manager... What are the implication of the lack of relation between diploma and experience? 1) Diploma are overpriced, the job market is artificially skewed in favor of those who have the money for it; 2) New devs are underpaid, old devs overpaid. The burden of the proof that a diploma/experience is relevant for a job should be in the hand of the one selling diploma. Diploma especially in computer science seems to be a SCAM The effect of this scam is : 1) young workers enslaved by loans in jobs they may not be good at/liking; 2) a rigid job market that prevent people from moving hence artificially creating difficulties to have full employment 3) an artificial exacerbated competition resulting in cheating from both sides.

Fede_V 10y ago

I have a feeling that implementation speed is an instance of Goodhart's Law (https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law). If you keep everything constant (code quality, amount of tests, documentation, etc) then a faster engineer is obviously better. However, if you start using speed as a criteria to judge engineers, then the easiest way to increase speed is to sacrifice things which make code maintainable and modular. Finding metrics which work well even when people try to game them is incredibly difficult (if not impossible).

alephnil 10y ago

From the article: > [] Three of the twelve subjects did not use the recommended high-level language JTS for solving the task, but rather programmed in assembly language instead. Two of these three in fact required the longest working times of all subjects. One might argue that the decision for using assembly is part of the individual differences, but presumably most programmers would not agree that doing the program in assembly is the same task as doing it in a high-level language. In my experience, making the right decisions like that is the real difference between good and not so good programmers. Good programmers do on average better choices that results in less code, code that is easier to maintain and reason about, and choosing language and architecture that fit the problem at hand. It is not that good programmers develop so much faster usually.