Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

page.mi.fu-berlin.de

Post reply on HN
Print view View original

11–20 of 74 posts

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

#11

Post by Scarblac »

douche wrote: post #6
questionr wrote: post #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."

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

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

#12

Post by naveen99 »

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.

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

#13

Post by ktRolster »

questionr wrote: post #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."

The ratio of slowest versus fastest quarter

Dividing the data into quarters instead of looking at individuals is definitely going to have a smoothing effect.

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

#14

Post by cle »

School-Cotton wrote: post #5

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.

The answer is in between. The best engineers know how to balance speed with quality. Great engineers make good products, fast.

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

#15

Post by enraged_camel »

snoman wrote: post #9
School-Cotton wrote: post #5

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.

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.

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

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

#16

Post by lifeisstillgood »

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)

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

#17

Post by Dr_tldr »

naveen99 wrote: post #12

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 comput…

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.

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

#18

Post by drumdance »

Scarblac wrote: post #11
douche wrote: post #6

Earlier quoted context omitted.

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

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.

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

#19

Post by ScottBurson »

philangist wrote: post #10

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 lo…

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.

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

#20

Post by verinus »

snoman wrote: post #9
School-Cotton wrote: post #5

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.

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.

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,...)
Post reply on HN