10 ms·

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

• justbaker 9y ago
  Semi-true; it depends how the extra 20 hours are spent for myself. I've had weeks where I program 60 hours or more and it's all spent well, and then the next week I might be a little more burnt out.. take it a little easier and then sprint again.
  • JustSomeNobody 9y ago
    Which goes towards 60 hour weeks are not sustainable...
    • monk_e_boy 9y ago
      60 hours weeks aren't sustainable, but just look at teams during crunch weeks. They sure get a lot of work done. Sometimes you've just got to put the hours and effort in to get the work done on time. Now I quit very quickly after doing stupid hours a week. But I'd like to think the work produced was fine. Not that much different to a normal week. The work was all planned in detail, there weren't any big surprises, just lots of code to type in, lots of tests to write and run. I was just more tired.
      • learc83 9y ago
        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?
        • sokoloff 9y ago
          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.
          • majewsky 9y ago
            That's a popular adage: "I have a motivation problem until I have a time problem."
    • jcranberry 9y ago
      A have a couple friends who work dawn until dusk for their startup. After several months they struggled with depression and managing their work life. After a little over a year they've adjusted and it's just routine.
      • ikeyany 9y ago
        > After a little over a year they've adjusted You mean they developed depression and gave up having a healthy work-life balance?
      • justbaker 9y ago
        I can sympathize, as this recently provoked myself to take a vacation for my mental health to recover. I went to an island with horrible internet and phone service and disconnected.. this helped me restore the fragile work/life balance I require. ^
    • justbaker 9y ago
      I agree. This leads to burnout and it is not a pattern for a lengthy or successful career. I had to recently take time off in order to recharge from burnout... avoid getting to that point at all costs!
    • luispedrocoelho 9y ago
      Which is a good reason not to work 60 hours regularly over the long term, but not a reason to never put in a 60 hour work week or even a few in a row. Elsewhere, I've written how it may be better to switch between periods of very long hours and downtime rather than a steady pace: https://metarabbit.wordpress.com/2014/02/26/average-work-week-is-over-a-few-thoughts-on-productivity/ https://metarabbit.wordpress.com/2014/02/26/average-work-wee...
• trendia 9y ago
  TL;DR: MS Paint [0] [0] http://imgur.com/a/YrlD7 http://imgur.com/a/YrlD7
  • mlvljr 9y ago
    Impressive. Are you in marketing? :)
  • barrkel 9y ago
    That graph doesn't reflect the gist of the comment you're replying to. It explicitly talks about negative productivity, not asymptotically zero output like the graph.
• jonas21 9y ago
  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_cat_kittles 9y ago
    i've never thought about how these two things relate to each other: asymptotic productivity of work, and winner take almost all nature of capitalism. seems like a very succinct way of explaining why people work so damned much. i'm actually kind of embarrassed i've never connected the two. it seems to make the argument against it more clear too- if marginal hours worked grow less productive, and marginal improvement to the product is negligible in every day terms, we ought to mitigate that somehow, unless its something people are doing because they love it.
    • rhizome 9y ago
      asymptotic productivity of work, and winner take almost all nature of capitalism. seems like a very succinct way of explaining why people work so damned much A myth of capitalism is that the donkey can reach the carrot hanging from the stick if they work harder, that "almost all" can be won by those who are being driven to work more hours. However, this doesn't take into account that there are at least as many carrots-on-sticks as donkeys, and that carrots are cheap.
      • the_cat_kittles 9y ago
        i dont get what you are trying to say. something about how its easy to mislead people into working long hours?
        • rhizome 9y ago
          In this context, that "the nature of capitalism" is not evenly distributed, though the rhetoric says it is.
• tome 9y ago
  Is this really so? Perhaps in the long term 40-hour-a-week pickers pick more than 60-hour-a-week pickers in absolute terms simply because the extra recovery time helps them be fitter and have more energy.
  • MaysonL 9y ago
    Apple picking is like crunch time – or at least like crunch time should be – it's not a long-term activity: the time between apples ripening and the first frost ruining them is not long.
• conanbatt 9y ago
  I doubt that the bugs provoked by tiredness have an aggregate of negative productivity. And even if so, it can be mitigated. As a webdeveloper, when Im tired i do the most menial tasks which means that bugs introduced there are rare and not important.
  • marcosdumay 9y ago
    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?
    • roel_v 9y ago
      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, issue tracker triaging, ... There is so much in software development that is menial yet isn't worth or can't be automated.
      • pharrington 9y ago
        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-.
    • conanbatt 9y ago
• nickbauman 9y ago
  There's a ton of conflation going on in the article. Most importantly, what defines "productive work" versus just "output" is not defined. He seems to focus on "academic" work but doesn't define terms well. I've written about this here before, in summary: 1) Work has a cost to the endeavor too. Even with salaried workers. 2) If what you're doing can be boiled down to time-and-motion studies, you can always make cases where longer hours yield more "output". BUT pushing even these types of work beyond marginally has been found to incur large ongoing cost the mission. This is backed by research that has been done many times since WWII with thousands of subjects. 3) Then, what software developers do is NOT amenable to time-and-motion studies. So even the marginal increases in time working has an even greater case of dubious value.
• rlkf 9y ago
  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).
  • agumonkey 9y ago
    Is there something peculiar around 14:00 beside lunch ?
  • jakubp 9y ago
    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.
• watwut 9y ago
  That is just his guess tho. He does not have study to confirm it nor appears to know what actually was done in studies he criticises nor their conclusions. Studies found that crunch slows down only after few weeks of crunch and 40-50 hours a week had same product long term. He article implies different results.
  • luispedrocoelho 9y ago
    OP here. "Studies found that crunch slows down only after few weeks of crunch and 40-50 hours a week had same product long term" [citation needed] Can people please stop claiming that "studies found..." without citations?
• mrighele 9y ago
  Your reasoning can be applied to a regular job: if I am tired I make more mistakes and every mistake has a cost. If the cost of mistakes made during the extra hours exceed the value of the job done, those extra hours didn't produce anything useful. Even not taking into account mistakes, there is another important factor to consider: you need to recover energy from one day to another. The more you work the more you need to recover and less time you have to do it. If you don't, you will be less productive the following day. I think that for this reason it is reasonable to say that there is a limit after which the productivity start to drop, though it probably depends on the individual and on a number of factors.
• skybrian 9y ago
  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 work longer hours when under time pressure. And the cumulative effects of working while tired might result in worse results the next day, even if a single day doesn't do it. But I'm just speculating. It would be interesting to see a study that tries to distinguish between these different effects.
  • bsder 9y ago
    > It seems plausible that programming while tired doesn't do a whole lot of damage in itself (more than the usual amount of bugs) I can tell you in embedded devices that simply isn't true. In a lot of embedded programming, you can cause real damage--short out boards, crash equipment, etc. If I have been at something for too many hours, I may simply stop. I will certainly stop if I recognize that I just did something really boneheaded and simple. That means that I'm likely to continue doing boneheaded things and cause real damage.
  • majewsky 9y ago
    > 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.
• kbutler 9y ago
  > even if you only pick one apple per hour after that, you will still pick more apples working 50 hours than 40. How about your 2 week total? Or 52-week total? If weeks 2-52 are one apple per hour, 50 hours per week, you've done less work in more time.
• raymondh 9y ago
  > 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. That logic presumes that the first 40 hours aren't affected by the additional hours. IIRC, one of the premises of the "sustainable pace" rule for Extreme Programming was that people know when they are being pushed to work a lot of hours and either consciously or unconsciously slow down at the outset (with the mind or body shifting out of a sprint-mode and into a marathon-mode).