Hacker News Reader

Comment by Piskvorrr | Hacker News Reader

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.

View on HN

One 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?

Simply have the developer use two computers at the same time, thereby doubling their man-hours

Quadratically, IINM, not exponentially.

I 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.

MMM 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.)

> 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.

Maybe 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.

I am thirty and I find the same. More than two weeks of heavy days and my productivity plummets until I get proper time off.

If 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.

That's a benefit to some business types. You're getting grey and expensive.

I'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.

At 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!

lol.. 55 would be the dream, most weeks I do 80+ most of my team do 60+

50% coding/50% hackernews browsing then? ;)

50% coding would also be a good target .. :P

Well that is the worst place ever to work.

I wouldn't be so harsh. If you are young, and if you breathe, drink and eat your product, this could be awesome. None of that lasts forever, of course, but if it happens - what a time to be alive! Not a place for everyone, indeed, and not conventional.

If, on the other hand, you are only interested in the product, and/or you have other stuff to take care of, that would be Hell on Earth for you.

do 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.

I 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 .

zsh, 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

So, no life outside work at all? And a work that doesn't appreciate you enough to work sane hours? What's the point then? Stocking money for later on?

If 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."

> 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)

A lot depends on how into the project I am.

>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.

Took me a while to realize that PHB = pointy haired boss.

Reply on news.ycombinator.com