3 ms·

From the article: "The truth is that much of the extra effort these entrepreneurs and their employees are putting in is pointless anyway. Working beyond 56 hour

by dahdum 9y ago

From the article: "The truth is that much of the extra effort these entrepreneurs and their employees are putting in is pointless anyway. Working beyond 56 hours in a week adds little productivity, according to a 2014 report by the Stanford economist John Pencavel. " I don't see how the study, which was done on manufacturing / production workers, necessarily applies to knowledge workers or entrepreneurs? My experience working 80-90 hr weeks was that as long as I had flexibility to vary the tasks I didn't sense any drop in productivity. In many cases the fewer context switches increased the amount of "flow", and projects went more quickly than they would have.

Analemma_ 9y ago
> My experience working 80-90 hr weeks was that as long as I had flexibility to vary the tasks I didn't sense any drop in productivity. In many cases the fewer context switches increased the amount of "flow", and projects went more quickly than they would have. Did your experience rigorously measure how many mistakes (bugs, if you're a developer) you made during hours over 56 relative to baseline, and how much it cost someone else down the road in cleanup and opportunity costs to fix them? With programmers, at least, they can keep writing code well into 100 hours a week and beyond, but the trustworthiness of that code falls off, and that's a problem. It's a well-known result that fixing bugs costs many times more than not making them to begin with.
- bigleagueposter 9y ago
  If it was a failed startup all their code was in the end useless garbage.
  - vecter 9y ago
    That's a pretty silly, cynical, and useless way to look at it. The evaluation should be from a technical point of view of code quality: did the code do what it was supposed to do, and do it well? After all, that's what's being debated in this particular thread. This is independent of the business value of the code, which of course matters in an entirely different way. However, that's not really the responsibility of the engineer so much as it is the business leaders.
- dahdum 9y ago
  I saw no difference in quality of work, nor did I get reports on any. I believe the key reason is the ability to change tasks. Been writing code for 4 hours and tired of it? Switch to documentation, regression testing, managerial tasks, ticket triage, spec writing, or something else from your list instead. Want to go see a movie in the middle of the day, take a nap, or take a two hour lunch to regroup? No one cares. For startups especially it's do-or-die, so this type of pressure will never go away. Imagine you had two 5-person startups each building a social media management platform to capitalize on a growing market. The space is quickly becoming crowded, and while not winner-take-all, most entrants will fail. Company A: They work 90 hour weeks, weekends included. The willingly give up their social lives, take no vacations, and work as hard as they can. They'll sleep at the office if they have to. Company B: They work 40 hour weeks, and take a normal amount of time off. At the end of the day they go home and relax with family/friends. Either company could succeed in the end, but which has the better chance? Which attracts more VC interest? Who gives a better impression to prospective clients? Who builds a fully functional platform first? In my experience Company A often trounces Company B.
  - deleted 9y ago
    [deleted]
kelnos 9y ago
I know I can push myself to write code for well over 70 hours per week, but I definitely find that the quality of that code degrades sharply at some point. When I look at some of that code later, after I've had time to rest, I wonder what the hell I was thinking. I might have produced more output, but all the mistakes I've made have to be fixed at some point, sometimes by someone other than me, and there's a real cost to that. The longer a bug lingers, generally the more expensive it is to fix (even if it's being fixed by the person who wrote it in the first place). The kind of death marches we're talking about rarely involve time to go back to fix any but the worst bugs or pay down any technical debt, at least not until much later down the line. And regardless of that, why would I want to spend all my waking hours writing code? Life is so much more than that. (You're welcome to disagree with that, but I dare say you'd be in the minority.)
kamaal 9y ago
I had a Math professor in college who used to say amount of effort almost doubles if you wish to score a few extra marks above some point. Like say if the you are already scoring 80/100. Going to 90 will almost take same the effort it took going from 0-80. Going 5 more marks higher will mean a similar long slog effort. It was simply his way of saying doing big stuff required insane amounts of effort. Often not justifiable. I have seen something similar in competitive programming too. After a while solving regular problem gives your very little exposure in return, to keep your returns coming, you have to up your problem difficulty level at every step. And that consumes time.

by dahdum 9y ago

Analemma_ 9y ago

> My experience working 80-90 hr weeks was that as long as I had flexibility to vary the tasks I didn't sense any drop in productivity. In many cases the fewer context switches increased the amount of "flow", and projects went more quickly than they would have. Did your experience rigorously measure how many mistakes (bugs, if you're a developer) you made during hours over 56 relative to baseline, and how much it cost someone else down the road in cleanup and opportunity costs to fix them? With programmers, at least, they can keep writing code well into 100 hours a week and beyond, but the trustworthiness of that code falls off, and that's a problem. It's a well-known result that fixing bugs costs many times more than not making them to begin with.

bigleagueposter 9y ago
If it was a failed startup all their code was in the end useless garbage.
- vecter 9y ago
  That's a pretty silly, cynical, and useless way to look at it. The evaluation should be from a technical point of view of code quality: did the code do what it was supposed to do, and do it well? After all, that's what's being debated in this particular thread. This is independent of the business value of the code, which of course matters in an entirely different way. However, that's not really the responsibility of the engineer so much as it is the business leaders.
dahdum 9y ago
I saw no difference in quality of work, nor did I get reports on any. I believe the key reason is the ability to change tasks. Been writing code for 4 hours and tired of it? Switch to documentation, regression testing, managerial tasks, ticket triage, spec writing, or something else from your list instead. Want to go see a movie in the middle of the day, take a nap, or take a two hour lunch to regroup? No one cares. For startups especially it's do-or-die, so this type of pressure will never go away. Imagine you had two 5-person startups each building a social media management platform to capitalize on a growing market. The space is quickly becoming crowded, and while not winner-take-all, most entrants will fail. Company A: They work 90 hour weeks, weekends included. The willingly give up their social lives, take no vacations, and work as hard as they can. They'll sleep at the office if they have to. Company B: They work 40 hour weeks, and take a normal amount of time off. At the end of the day they go home and relax with family/friends. Either company could succeed in the end, but which has the better chance? Which attracts more VC interest? Who gives a better impression to prospective clients? Who builds a fully functional platform first? In my experience Company A often trounces Company B.
- deleted 9y ago
  [deleted]

kelnos 9y ago

I know I can push myself to write code for well over 70 hours per week, but I definitely find that the quality of that code degrades sharply at some point. When I look at some of that code later, after I've had time to rest, I wonder what the hell I was thinking. I might have produced more output, but all the mistakes I've made have to be fixed at some point, sometimes by someone other than me, and there's a real cost to that. The longer a bug lingers, generally the more expensive it is to fix (even if it's being fixed by the person who wrote it in the first place). The kind of death marches we're talking about rarely involve time to go back to fix any but the worst bugs or pay down any technical debt, at least not until much later down the line. And regardless of that, why would I want to spend all my waking hours writing code? Life is so much more than that. (You're welcome to disagree with that, but I dare say you'd be in the minority.)

kamaal 9y ago

I had a Math professor in college who used to say amount of effort almost doubles if you wish to score a few extra marks above some point. Like say if the you are already scoring 80/100. Going to 90 will almost take same the effort it took going from 0-80. Going 5 more marks higher will mean a similar long slog effort. It was simply his way of saying doing big stuff required insane amounts of effort. Often not justifiable. I have seen something similar in competitive programming too. After a while solving regular problem gives your very little exposure in return, to keep your returns coming, you have to up your problem difficulty level at every step. And that consumes time.