6 ms·
Quoting TMMM as a justification for product death march? Wow. A programmer who works 55 hours a week will produce twice as much code - but for how long? Once f
by Piskvorrr 10y ago
Quoting TMMM as a justification for product death march? Wow.
A programmer who works 55 hours a week will produce twice as much code - but for how long? Once fatigue settles in (a few weeks in), you're back at the 40-hour productivity levels, just paying it at 55-hour rates (and organizational overhead for overtime, oooh boy!), plus burning out the developers (and organizational overhead for employee churn).
Your assumption is that 55 hour weeks are sustainable: just change this number in the spreadsheet from 40 to 55, and voila! And while we're at it, why not 80? Why not 200? Very PHB-ish, in my unhumble opinion.
- sintaxi 10y ago> A programmer who works 55 hours a week will produce twice as much code - but for how long? By my experience I would say around 18-24 months.
- Ma8ee 10y agoMaybe it's because I'm a little bit over forty, but for me only a few days working 10 hours a day (plus a significant commute) decreases my productivity significantly. That is at least if I have to work on more that one project at a time. If I don't have to switch tasks and it is relatively straightforward work I can probably manage for a few weeks, but not much longer and I know that I'll definitely hate my life.
- Mikushi 10y agoI am thirty and I find the same. More than two weeks of heavy days and my productivity plummets until I get proper time off.
- ferentchak 10y agoIf the project is fun I can work two times as long without fatigue. For example if I think this is important and my effort personally can make the difference. Or if I am using a new technology or something that feels like a "portfolio" piece.
- Spooky23 10y agoThat's a benefit to some business types. You're getting grey and expensive.
- Piskvorrr 10y agoAt which point they ragequit. But hey, never mind the burnout, let's just find another cog for the machine. Never mind the ramp-up cost - fifty-five hours a week, yeeehaw!
- manquer 10y agolol.. 55 would be the dream, most weeks I do 80+ most of my team do 60+
- Piskvorrr 10y agoIf it works for you, I see no problem :) The issue I had was with this as the answer to life, universe and everything: "thou shalt not have life outside of work."
- eeZah7Ux 10y ago> If it works for you, I see no problem There's a reason why 80-90% of the wealthy/developed countries make it illegal to overwork people (even if the worker would be willing to work)
- sharemywin 10y agodo you get a lot of actual work done? I found communication slows things done a lot. waiting on answer from other people seems to be a pretty big bottle neck. I like to have a couple project going at once to be more productive.
- daef 10y agozsh, i3, ssh, openvpn, pidgin, tmux, vim, firefox, vlc - about everything i need all 6hr working day long if i want to shortcut communication i simply call mates via dialthrough or skype
- manquer 10y agoI get very little of "real" work during regular hours, most of it goes in meetings, code reviews and of course communication. I code during the off hours essentially two jobs i guess, one I love(coding) makes the other(management) bearable .
- sharemywin 10y agoA lot depends on how into the project I am.
- matwood 10y agoI'm naturally a sprinter type, so I tend to set up my work the same way. I tend to work more in the winter (55+ hours) since there isn't much else to do anyway, and work less during the summer (40 or less). I'll also work like you suggest for multi-month stretches and then take a few weeks off and go on vacation. I've tried the steady working, but I just do not operate that way. When there is work to do I do it, and simply have a hard time sitting still or concentrating on something else. I'm fortunate to be in a field and with a company that is flexible in this way. I also really like this method. When I'm on vacation that is my 100% focus. I'd much rather work a lot and then completely unplugged instead of always working even on vacation.
- mannykannot 10y agoMMM is actually an important part of the answer, and it is unfortunate that it was presented this way (death marches are deprecated for their own reasons.) The right way to think of this is to consider four people each working two hours a day on the same problem. Sustained effort and focus matter. This is most true for tasks that are more intellectually demanding, like the development of large-scale software (which is what Brooks was writing about.) The more routine a task is, the easier it is to divide it up (though that is rarely to the benefit of the worker.)
- deleted 10y ago[deleted]
- skywhopper 10y agoOne of the points of TMMM is that communication and coordination overhead is a cost and a risk and that it grows exponentially in relation to the number of programmers you have. So, you won't get double the productivity out of twice as many programmers (unless they're on unrelated projects--but more projects == more overhead as well). 200 hour weeks would be quite unsustainable, indeed. Forget not sleeping, where do you get the other 32 hours?
- Sniffnoy 10y agoQuadratically, IINM, not exponentially.
- Piskvorrr 10y agoI was wondering whether anyone would catch on ;) Anyway, I wasn't arguing that more developers is easier (I do believe it might be better) - I was saying that piling hours on top doesn't scale either.
- corobo 10y agoSimply have the developer use two computers at the same time, thereby doubling their man-hours
- coldtea 10y ago>Once fatigue settles in (a few weeks in), you're back at the 40-hour productivity levels, just paying it at 55-hour rates Rather you're back at far worse than 40-hour levels. Once fatigue settles in the code will be much worse.
- codingoutloud 10y agoTook me a while to realize that PHB = pointy haired boss.