Live data from Hacker News

Research does not say that people produce more when working 40 hours per week

metarabbit.wordpress.com

141–150 of 198 posts

Re: Research does not say that people produce more when working 40 hours per week

#141
post #21
post #9

TL;DR: you can get more done if you work 60 hours instead of 40 hours in a week, but the work done in that extra 20 hours might be a small fraction of what gets done in 20 hours during a 40 hour week. This is self-evidently true for many jobs. E.g., if you pick apples for 40 hours, then even if you only pick one apple per hour after that, you will still pick more apples working 50 hours than 40. We software developer…

I think you might be missing the author's last point which is that in a competitive field, even a small increase in output can lead to a large increase in payoff. In his example of getting research funding, it's a step function: either you get funded (y=1) or you don't (y=0), and because you're competing with others, even a small output increase can take you from the 0 side to the 1 side.

The point your predecessor was making was that if you make bad design decisions or create bugs, your output isn't growing.

Re: Research does not say that people produce more when working 40 hours per week

#142
post #76

Earlier quoted context omitted.

What is a menial task in software development? I mean, our entire field exist for pushing menial tasks into computers. If you have as many of them to fill 50% of your work load, there's probably something wrong. Besides, are you sure bugs in menial tasks are not important? When did you judge those tasks to decide this?

So many: fleshing out test suites, setting up that build server, automating your documentation generation process, making that internal tool a bit more generic to be useful, fixing those warnings from that analysis tool, checking for performance regressions against the data from when you last did it 3 months ago, refactoring some of that code from 3 years ago for which there is now a more idiomatic way of doing it, i…

Just talking about the first item: you're asserting that first verifying your understanding of specifications, discovering then specifying currently implicit requirements of an in-production system, then automating your system's compliance with specs in a way that does not require changing the automation while specs remain constant but the system grows, is menial. At least to me, as a person who struggles even with math proofs, and is trying to figure out a robust way to discover features in complex systems (for example, to reverse engineer/port video games without access to the source), that is -very surprising-.

Re: Research does not say that people produce more when working 40 hours per week

#143
post #133

Earlier quoted context omitted.

All of those companies exist in a world with the threat of anti-trust regulation, and some were directly affected by it. There are plenty of counterexamples from before that regulation, and there are still some today (e.g. ISPs).

> There are plenty of counterexamples from before that regulation Name one :-)

Literally the entire reason antitrust laws were written? Standard Oil? General Motors? AT&T?

A little disingenuous to pretend that never happened.

Re: Research does not say that people produce more when working 40 hours per week

#144
post #9

TL;DR: you can get more done if you work 60 hours instead of 40 hours in a week, but the work done in that extra 20 hours might be a small fraction of what gets done in 20 hours during a 40 hour week. This is self-evidently true for many jobs. E.g., if you pick apples for 40 hours, then even if you only pick one apple per hour after that, you will still pick more apples working 50 hours than 40. We software developer…

It seems plausible that programming while tired doesn't do a whole lot of damage in itself (more than the usual amount of bugs), provided that you also write unit tests and do code review. This could include self-review: that is, don't check in while tired, and read it over the next morning. On the other hand, the shortcuts people take while under deadline pressure seem more damaging, and people are more likely to wo…

> provided that you also write unit tests and do code review

Not necessarily. Imagine submitting a patch on 8 PM, when everyone has already been in the office for 10 hours. It has a glaring bug in a particular branch that's not covered by the unit tests in a way that coverage testing doesn't show, yet everyone is too tired to see that bug. Thus the patch gets greenlit and applied to production. Just as everyone is heading home to fall into bed, pagers start ringing because prod is on fire.

Re: Research does not say that people produce more when working 40 hours per week

#145
post #28

Earlier quoted context omitted.

How much of that extra work was because of the extra hours put in and how much was because people work harder when deadlines are close?

I was talking with a colleague the other day about "strategies for how to focus for 4 straight hours". The one that works best for me is for the deadline to be 4 hours and 15 minutes away.

That's a popular adage: "I have a motivation problem until I have a time problem."

Re: Research does not say that people produce more when working 40 hours per week

#146

Earlier quoted context omitted.

What is a menial task in software development? I mean, our entire field exist for pushing menial tasks into computers. If you have as many of them to fill 50% of your work load, there's probably something wrong. Besides, are you sure bugs in menial tasks are not important? When did you judge those tasks to decide this?

tasks.sort { |a,b| b.difficulty a.difficulty }

  tasks.sort_by(&:difficulty).reverse
Readable code FTW.

Re: Research does not say that people produce more when working 40 hours per week

#147
post #84
post #9

TL;DR: you can get more done if you work 60 hours instead of 40 hours in a week, but the work done in that extra 20 hours might be a small fraction of what gets done in 20 hours during a 40 hour week. This is self-evidently true for many jobs. E.g., if you pick apples for 40 hours, then even if you only pick one apple per hour after that, you will still pick more apples working 50 hours than 40. We software developer…

At my previous work, we attempted to find the correlation between faulty code and the time of commit in the version control. Most bugs were written after 14:00. (And no: we didn't check-in all code at the end of the day).

A fellow student of mine did a study back in 2005 about this. He found that the worst time to fix a bug was Friday afternoon, as it introduces the most (new) bugs into the code.

I see similarities to another area where I have more experience: business meetings. I believe that most people are terrible at meetings held in the afternoon, either due to heavy lunch, or just because it's after 3pm and they are simply tired. A single meeting like this can cause great damage to the individuals and whole teams, measured in intangibles such as motivation, trust, momentum.

Re: Research does not say that people produce more when working 40 hours per week

#148
post #51
post #36

Earlier quoted context omitted.

It's actually flawed because there are other things that need to be done in a week besides work, recreation, and rest. For example: - eating: 12-15 hours/week - making food (or travelling to get food): 7-10 hours/week - showering, shaving, grooming: 4-7 hours/week - laundry, cleaning, house chores: 2-4 hours/week - commuting: 5-10 hours/week - waiting in line (checkout lines, customer service reps, Comcast/DMV/insura…

Your estimate on time to take care of children is ridiculously low.

I was thinking the same. I don't have children, either, but observing my friends and siblings who do would make me estimate this at 40+ hours/week. (Estimate applies to children below age 6-8. Of course, it's progressively less the older and more independent the child grows.)

Re: Research does not say that people produce more when working 40 hours per week

#149

This essay and most of the comments saying, "of course more work time yields more work completed" ignore the fact that there is no magic reset to full productivity Monday morning. If you work every hour of week 1, your output of week 2 will be drastically reduced. There is therefore some optimal balance between work time and recovery time. It may be 40 hours, or 20, or 80. It probably varies between tasks and individ…

> Sometimes the best thing you can do to get the job done is to stop working on it for a while.

This. I like to have several side projects at once so I can switch to another one when I'm stuck on the current one.

On the downside, this procedure made me question if I can actually work as a programmer professionally, where I don't have the liberty to just leave any task assigned to me lying around for a week (or a month). It worked out nicely, though, since I found that I can get my train of thought unstuck by discussing the problem with a colleague.

Re: Research does not say that people produce more when working 40 hours per week

#150

Earlier quoted context omitted.

I think you may have misunderstood the article - if anything this is an argument for death marches.

I wonder if the author being a student pushing for a European PhD[1] warps his thinking about this. With a PhD all the reward is at the end. You either make or break. None of the work you do has any tangible results outside of the end goal. Most work isn't like that. The rewards are continuous and ongoing. Meaning every task has captured value. If a loan officer closes 19 loans this month instead of 20, productivity…

> None of the work you do has any tangible results outside of the end goal.

Depends on the field. From what I hear [citation needed], what you describe generally holds true in the humanities.

In contrast, I have two friends who're submitting their PhD theses around now, and they already have a ton of tangible results: They're required to publish papers during the research period for their thesis. They got to speak at conferences because of their published findings. They collaborated with other researchers whom they met at these conferences. And that, again, fed back into more papers and a better thesis. Even if they didn't get their PhD (which I'm sure they will), they still have made a name for themselves in their respective fields.

Post reply on HN