Can People Really Program 80+ Hours a Week?

ibn_khaldun asks: "A question in light of the EA controversy. I'm an academic researcher who does his own programming -- I have to eat what I kill. In my 35 years of coding experience, any time I try to work on a complex program for more than, say, 60 hours a week (coding, not just showing up) for a couple weeks at a time, I'm just asking for trouble: I generate buggy code and debugging it only makes it buggier. Numerous studies in other fields (law firms, hospitals) have shown that mistakes rise exponentially after anyone works about 50 hours per week (don't think about this if you go to the emergency room at 3 a.m.)." Are these rational working conditions? (More below.) "Does EA sprinkle magic pixie dust on their serfs to get around this problem, or is the work so trivial that it can be done while pathologically sleep deprived, or are the PHB's so technically challenged they don't realize what is going on? This whole 'death march' mentality seems absolutely crazy to me as a programmer, but appears to be common. Honestly, can someone enlighten me as to how these 80+ hour weeks ever accomplish anything?"

Comments

Well, it can be done. But can it be done well?

[fishdan]

You can work 80 hours in a week, but I agree that you would find that 80 hours of work done in one week will be much less effective than 80 hours of week done in 2 weeks. There are diminishing returns on labor as time increases. But the point is that there ARE indeed returns, even at hour 80. If I work 80 hours in a week, and only get say 60 hours of good work done, that still puts me 20 hours ahead on Monday if I was working 40 hours a week.

Even if you were to assume that my productivity were to go down 10% for every hour over 50 I worked, I'd still be *somewhat* productive at hour 80. Of course it's not linear like that, but if something's *got* to get done, then it's got to get done, whether I'm tired or not.

And I find that I do have hours of clarity even at the end of a long period of work. So If I get that good hour or 2 at 70 hours, I would have missed it if I'd gone home/to sleep at 60 hours.

I don't think anyone can work 14 hours a day, 7 days a week. You need some time to refresh,recycle,renew. What's a reasonable amount of time to recuperate? I think one day always seems to do it for me. I've never had to pull crazy hours like that more than a few weeks in a row, and we always found a way to take off 24 consecutive hours each week. That was what made it work.

It also helps TREMENDOUSLY to work in a cool place with cool people. If you respect everyone around, and they're all busting ass, you'll find it's EASY to do the same, and hard to let anyone else down. I knew guys who would feel guilty about going home to see their kids when crunch was on.

Is that a healthy culture? Probably not. But we did get plenty of work done, and that's I think what you were asking.

EA Controversy

[the_mighty_$]

For those that dont know, here for about this 'EA controversy':

http://www.livejournal.com/users/ea_spouse/

Re:Well, it can be done. But can it be done well?

[The FooMiester]

Even things that are not-quite-so mentally demanding such as electrical work become very difficult once a certain point is reached. For me, it's at about 65 hours/week.

Ok, which wire goes where now!

Waiting For The Weekend

[2TecTom]

This book goes into this in great detail:

Waiting for the Weekend
by Witold Rybczynski
http://tinyurl.com/6kt4r [amazon.com]

The author discusses the disruption of the development of leisure time and it's implications for modern society. It's not a pretty picture. Welcome to salary slavery.

References (DeathMarch, PeopleWare)

[bill_mcgonigle]

The definitive work on the Subject is DeathMarch by Edward Yourdon. He goes over why these kinds of project keep happening, why they're bad (with numbers) and what to do if you're caught up in one. No silver bullet, but pretty good. If you're a manager or you want to slip something under your manager's door, I really liked PeopleWare. It's not about the Death March, per se, but more about how to handle a software engineer like a human being. Of course, some PHB's don't think this is a reasonable approach.

Re:Well, it can be done. But can it be done well?

[Wavicle]

An interesting footnote on this whole "hours of time coding" issue...

The world's largest privately held software company is a company called SAS in North Carolina. Their software is basically an environment for doing statistical analysis. Regression, multiple regression, correlation, wilcoxon rank tests, and a slew of other things I haven't got to yet. But the important part is, if you were going to do a study to figure out the "optimal" amount of time to work, and consider not just productivity from the programmer, but all sorts of correlated variables (will someone work 80 hours/week for 10 years? How much will it cost to recruit and train a newbie when someone burns out?) then you would probably use a program like SAS to analyze the data. This is a company that has plenty of computer science and statistics Ph.D.'s on staff.

Their conclusion? 35 hours per week. Keeps the productivity high, the turn over low, and the company growing at double digit rates nearly every year (or maybe it has been every year).

Something to think about during your next interview cycle.

Intern Workdays

[bclemmen]

Actually, there has finally been some research completed recently that concludes: "The rate of serious medical errors committed by first-year doctors in training (interns) in two intensive care units (ICUs) at a Boston hospital fell significantly when traditional 30-hour-in-a-row extended work shifts were eliminated and when interns' continuous work schedule was limited to 16 hours". Press release here: http://www.ahrq.gov/news/press/pr2004/16hrintpr.ht m

Re:Well, it can be done. But can it be done well?

[Sycraft-fu]

Well, then what to do depends on the situation at work. Here's a couple of possible paths to try, depending on what is accessable to you:

1) If you can get away with (as in no repercussions to you) not fixing his mistakes, don't do it. Make sure it's clearly documented who's mistakes they are, and leave him to flounder. It's likely that if it causes problems, management will eventually wake up to the fact that he's the problem. Just make sure you are covered and whon't be blamed for his faliures. If you will, it's not worth it.

2) Find out who the managers trust and have them help you out. There may not be anyone who's in a position where they are willing and able to help. but if there is, enlist their help. Explain the problem, and show it to them, and then ask them to bring it up with the managers. People are odd with trust and advice. You may be technicaly superior to give advice, but they'll take it from someone in another department that they personally trust.

3) If all else fails, fuck it, just ignore it. There are many stupidities where I work, the ones I can't control I just accept and ignore. Sounds like you like your job overall, so don't stress on it. Yes, I'm sure it means your team doesn't do things as efficiently and as high quality as possible, but really, it doesn't matter. Just live with it and do what you can.

Creativity and Sleep

[John Murdoch]

A long time ago I talked about this subject with my brother, at the time a pilot in the Strategic Air Command. I was working with a group of people who were acutely interested in precisely same question as the poster--is ther a point at which extra hours != additional useful code? As it happens, the question has been extensively studied, and answered, by the U.S. military.

There is a long-established relationship between the ability to handle abstraction (such as OOP) and the ability to do spatial reasoning. The U.S. Air Force, in the 1950s and 1960s, did a lot of research in the relationship between sleep deprivation and spatial reasoning--they were alarmed about the accident rate of aircrews after very long missions. If you're at the controls of a KC-10 tanker, a slight touch with your fingers will affect the rate at which the aircraft wheel bogies forty feet beneath you and a hundred feet back will descend to the ground. If you're sleepy and groggy, you're much more likely to misjudge your altitude or your rate of descent. Hit the runway a bit too hard, or a bit too early, and the landing gear can collapse--and you and your crew will disappear into a ball of flames.

The result? The Air Force instituted something called "mandatory crew rest"--you fly X hours, and you must get at least eight hours of sleep (in addition to debriefing, flight planning, etc.). No matter if there is a global crisis and you are rarin' to fly, if you haven't had your mandatory rest, you stay in your bunk until you do.

So what does that mean for us?
As I wrote above, there is a strong relationship between abstract reasoning and spatial reasoning. The U.S.A.F. has proved that sleep deprivation diminishes your ability to do spatial reasoning; ergo, sleep deprivation diminishes your ability to do abstract reasoning. Based on twenty-plus years in the business, that makes sense: time and again I've seen programmers try to pull all-nighters to finish up a project, only to fall further behind because they wrote gibberish all night long.

But wait, there's more...
Sleep deprivation isn't the only issue: dehydration will also affect your ability to do spatial reasoning (trivia fact: baseball batting averages are lower in the second half of a daytime doubleheader; because the players have been out in the hot sun, baking under dark-colored baseball caps. They get dehydrated, which limits their ability to hit a curveball.)

Bottom line:
Wanna be an effective project leader? Send people home at a reasonable time; provide bottled water or spring water; and discourage (or at least don't encourage) coffee or other caffeine-based sleep substitutes. Do not run a death march project in order to look macho; and be prepared to fend off the Guys in Ties who think a death march atmosphere is necessary.

Sigh--I'm drinking WAY too much coffee these days....

Re:Well, it can be done. But can it be done well?

[DarkMantle]

There are alot of texts out there with studies on what can save money for the company. This is how to grab thier attention. They like to see the all-mighty dollar.

For this topic I recommend This study, as well as this one they seemed to help my former boss understand. And for planning time I recommend Code Complete so you can show them that not "coding" right away actually is a good thing.

Re:I think that Microsoft is using the same strate

[RevAaron]

I think there is a very important distinction to make in this case: code head written by a speed freak is quite different from a non-addict with a mild dose of amphetamine as a coding/study aid.

Though code written by a speed freak is indeed quite fucked in the brain. Code written by stoners isn't horrible, though the overall system designs is usually either ingenius or downright retarded. If I had to pick some drug for a coder to be addicted to, I think I'd pick orally administered opiates- especially if the poor schmuck had to work 50-80+ hours a week. Opium has a long history of being used by people who did more work than they'd like to in a week, while staying sane and relatively healthy. Drunks code like shit- both alcoholics and a non-alkie coding whilst drunk. ...but what the hell is the point of thise post? I guess it's: if you're ever starting some sort of rehab work program for ex-software developers addicted to various drugs to go with opium. :P