The best information is at the very end of the report where all the tables and graphs are. They show that munition workers are at peak production at around 50 hours or so. There are many many caveats for drawing conclusions from these results:
* The collected data is from 1915-1920
* The collected population is very very small
(most sets are less than 50 individuals, one is ~100)
* The work performed by the population is extremely repetitive manual labor
With these caveats, it is safe to say that most of the audience of HN has nothing to gain from the results of this study.
Empirically, my best output p/hour will peak with 35h/week. More than 40h/week and I start to feel overworked. I did also manual labour and the feeling wasn't very different. The difference is that instead of feeling mental tired you feel mental bored.
The fact that the data is from 1915 - 1920 does not invalidate it unless you want to suggest that human nature in 1915-1920 is different than it is now - which would seem a strange point to defend. And the sample sizes are quite decent.
I know that the HM userbase had a tendency to dismiss studies that are incorrectly conducted, but I don't think that this is one of those cases.
Very well put. Hard to extrapolate factory work to office work.
I do believe that there are diminishing returns in software development (and startups) but a lot of it depends on the type of job, stage of company, existing support processes, etc.
I'm curious as to the effects of extending past the 40-49 hours in week one, on subsequent weeks.
That information I think would be more compelling to an employer (or self-employer), because without it, you're simply saying 'You'll get more out of overworking people, you just won't get as much more.'
Repetitive manual labour seems as good a proxy as any for productivity. It would be nigh on impossible to find such a robust index for software development work, but other modern professions, particularly repetitive ones, e.g. administrative positions, may be an interesting population to study today.
Software specifically is too variable to accurately measure productivity. It's too subjective. Not only from a personal point of view, but also dependent on the task. Given the tendency towards automating the boring tasks, it seems that conducting such a study in the software development world becomes less and less likely.
[+] [-] jvdh|10 years ago|reply
[+] [-] galfarragem|10 years ago|reply
[+] [-] 78666cdc|10 years ago|reply
The fact that the data is from 1915 - 1920 does not invalidate it unless you want to suggest that human nature in 1915-1920 is different than it is now - which would seem a strange point to defend. And the sample sizes are quite decent.
I know that the HM userbase had a tendency to dismiss studies that are incorrectly conducted, but I don't think that this is one of those cases.
[+] [-] mathattack|10 years ago|reply
I do believe that there are diminishing returns in software development (and startups) but a lot of it depends on the type of job, stage of company, existing support processes, etc.
[+] [-] mastermojo|10 years ago|reply
[+] [-] georgeecollins|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] philmcc|10 years ago|reply
That information I think would be more compelling to an employer (or self-employer), because without it, you're simply saying 'You'll get more out of overworking people, you just won't get as much more.'
Which still reads like "more."
[+] [-] yunque|10 years ago|reply
Software specifically is too variable to accurately measure productivity. It's too subjective. Not only from a personal point of view, but also dependent on the task. Given the tendency towards automating the boring tasks, it seems that conducting such a study in the software development world becomes less and less likely.
[+] [-] dolzenko|10 years ago|reply
[+] [-] pbhjpbhj|10 years ago|reply
[+] [-] awinter-py|10 years ago|reply
One can argue that frequent interruptions from these sources gives workers the opportunity to 'micro-recharge'.
[+] [-] namenotrequired|10 years ago|reply
[+] [-] cma|10 years ago|reply
[+] [-] xchaotic|10 years ago|reply
[+] [-] tehrei|10 years ago|reply
[deleted]