Live data from Hacker News

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

page.mi.fu-berlin.de

41–50 of 74 posts

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

#41

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…

Find fast people to pair program with. You'll learn some good speedup techniques.

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

#42
post #17

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

I read somewhere that people who don't know calculus somehow invent it by themself when faced with a problem that requires it.

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

#43
post #34

Earlier quoted context omitted.

How do you explain that to companies that follow the Google interviewing model?

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?

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

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

#44
post #25
post #17

Earlier quoted context omitted.

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

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

you just described what maybe 0.001% devs will face, so not really... that's not how studies are done nor intended

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

#45
post #25

Earlier quoted context omitted.

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

you just described what maybe 0.001% devs will face, so not really... that's not how studies are done nor intended

0.001% of devs would be around a few hundred in the whole world, there are way more CS grad students than that...

I'd guess that at you get to at least a few percent if you count grad students, researchers, people working on performance critical stuff like GPU drivers, people working on state of the art tooling like Google internals or large OS libraries etc.

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

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

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

#47
post #2

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). Ta…

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?

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

#48
post #35

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…

Can you give an example of an "IQ requiring task"? I'd buy that there are programs you can't write without the proper background knowledge, but I don't understand what IQ has to do with any of this.

Write a sensible search engine for the web with 1995 knowledge.

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

#49
post #34

Earlier quoted context omitted.

How do you explain that to companies that follow the Google interviewing model?

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?

A "dead" (or shadowbanned?) user replied to you:

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

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

#50

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

What if one's slow is someone else's fast ?
Post reply on HN