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's real rate from the articles I could find

[Marxist Hacker 42]

$17/hr. That's what they expect to pay for artwork done in 80-110 hour weeks. On the plus side- that many hours means you're pulling down $100,000 a year....

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!

Pointy-Haired-Moron Mentality

[GuyverDH]

Unfortunately, the pointy-haired-bosses only see - 'more hours worked = faster product development = more product out sooner = fatter bonus at end of quarter'. They think "To hell with the peons that we're stepping on, breaking, squishing, ruining the lives of, as long as we get our bonuses".

Until they actually have to do something - say 1 minute of real work for every 1 hour of work that the rest of the employees have to work, they're going to continue to sit in their corner cubbies, dreaming up what they're going to purchase next with they're million dollar bonuses.

From experience

[roman_mir]

since I had to do this and not once either, sure, it's possible. It's not desirable over a long period of time, for example more than a month of this kind of stress and you start getting sick, you don't get enough sleep, you become very tired. It's not good in the long run. A week or two at 80 hours is doable without losing that much quality.

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

[metlin]

Yeah, but working does not necessarily equate to coding. You could be doing a whole lot of other things - designing, project management, documentation, testing and the like.

Most of that does not involve writing active code, and is equally time consuming, if not more.

I think in reality, it's more like writing 20 hours of documentation, 20 hours of software design, 10 hours of UI design and other issues - and maybe 30 hours of _actual_ coding that takes place.

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

[douthat]

in France ... we are the most productive people in the world

Sorry, Frenchmen are the 21st most productive people in the world.

Take care of the basics.

[fireboy1919]

The returns diminish if you don't get enough sleep and food.

Solution: Work while eating and sleeping. The second is a lot harder than the first, I'll admit, but if you're stuck on a problem, and you sleep on it, things sometimes look better.

With that strategy, I've been able to do a few 70 hour weeks without diminishing returns. 80 starts cutting into my sleep/food time, and I start getting diminishing returns.

However, I'm a big proponent of a social life. All work and no play makes Jack a mentally retarded boy.

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.

Re:Eat what you kill? How badly do you need to kil

[xenocide2]

Indeed. Another way to state that is "eat my own dogfood." What it means is that he's the end user for his software, and if it doesn't work, he knows about it. Joel from Joelonsoftware had a nice article on the subject and how it helps catch problems.

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.

Yes, I have written working code at 80 hours a wk.

[Justice8096]

This was done in two 36 hour days and one 4 hour day, for a couple of months (with partner-based coding too...)
The work is always brilliant, it works, it is incredible - but there are two problems:
1. You have to be at the same concentration level as I and my partner were at during the time we wrote it to understand the code. No one doing maintenence would be at that concentration level. This includes me.
2. The comments in the code were written at that same concentration level, and so they were too arcane to be useful - as an example, "the rising edge of the signal is needed, and the motif button press is at 270 degrees from it in the sequence in the clause, so rotate another 90 degrees by adding a not". Yes, this does describe what I did - but would it help anyone who is reading the comment?
So, I would say that you can do 80 hours a week on a one-time effort - but you will not be able to maintain it - even if you have code reviews, because everyone will be in the same charged state. For games that don't sell, this will work. For games that do sell, it will result in the need to do a complete rewrite every time a new feature is added that is not segregated to to a completely new part of the game (or website, or configuration tool, etc...).

Probably not programming 80 hours

[Anonymous Coward]

At my last game development job, when we were working 80 hour-weeks, most people would not actually work full-time during this time. We would spend many hours a day playing games, chatting, eating, browsing the web, or working on pet projects. Management did not reward productivity only hours spent at the company offices. You learn to cope with the stress by tuning off from work during work.

Re:I think that Microsoft is using the same strate

[DLR]

I done two stints for Microsoft as a temp, totalling just under 1 year. Yeah, they treat their people pretty well. I might add that this was on Help Desk, not development.

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.

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

[pipingguy]

If the code is well architected, then my return past 40 hours does not diminish so quickly. But chances are if they are asking you to work past 48 hours, your management lacks management abilities, and are askin you to make up for their shortcomings.

Something similar happens with piping design at times. For example, a big rush from management ("look busy") to do detail engineering before certified vendor drawings and specifications are received.

That isn't the half of it

[Anonymous Coward]

I am a practicing surgeon, and I can tell you that 12 hour days would be considered a vacation by residents, at least residents from my era (I was a resident in the late '80s).

During my residency, I was expected to be at the hospital by 6 AM. On my "off" days, I generally left at around 8 PM. On my "on" days, I worked all night, continuing into the next day, again leaving in the evening. Depending on my monthly assignment, I was on call either every other night or every third night. I generally got one day completely off every two months. My work week was rarely less than 100 hours and was sometimes as much as 140 hours.

Current regulations impose a weekly maximum of 80 hours for residents, which has been very difficult to comply with while providing continuous coverage for patients.

I'm not kidding.

David Bruce, M.D.

Tampa General Hospital and LifeLink Health Care Institute

Re:That isn't the half of it

[ajna]

As a medical student myself, I am selfishly glad that the ACGME has adopted an 80 hour week recommendation, as there seems to be evidence that shifts of even 12+ hours are detrimental to patient care. (Note that the link is for nursing. Current recommendations for medical residents have a 30-hour-straight limit).

On the other hand, you are entirely correct that certain specialty residency programs have been having trouble meeting the 80 hour guideline. Indeed, residents feel pressured to lie about work hours, since their program losing accredidation would hurt their own prospects as well.

Finally, please note that even 80 hour recommendations have officially been extended to 88 hours for some programs, such as many neurosurgery residencies. Imagine if your boss explicitly told a theoretical programming/IT governing body that 80 hours a week, averaged over 4 weeks, simply wasn't enough time. I hope this gives pause to those who love to complain about long hours spent programming.

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?

[calibanDNS]

Well, in reality I've noticed that most of his work on Thursdays and especially Fridays is very buggy. Also, he rarely has to fix his own bugs. He tends to introduce bugs into other people's code by refusing to step back and understand the whole system when he's in a rush to get work done. Then, the bug appears to have been caused by the developer who normally maintains that section so that developer ends up fixing it. I don't feel that it's worth me and several other developers giving up one day a week just to fix the bugs that this guy can generate in two days. He's reducing several people's productivity, not just his own.

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

I think you are missing it

[Sycraft-fu]

I think what he means is that his code is for his own use, to further his research. If it's fast, stable and easy to maintain, it amkes things easier. If it's a peice of shit that gives incorrect results, it makes things harder.

Also good researchers actually care about the shit they are researching. They want to learn more abut whatever it is they are studying.

His point is that in the commercial world, others have to deal with your mistakes. You fuck soemthing up, the end user deals with the problem. In research you deal with it. YOu fuck something up and the data is wrong, you've only screwed yourself.

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

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

[Wavicle]

Here's a link google turned up, I dunno how reliable you consider the source though.

Programmers disease

[DarkDust]

This is something that I noticed very early in my life (while I was still at school) and avoided ever since. A friend of my father, who is a journalist at a major german computer magazine for about fifteen years or so, once told me that (almost) every job has one or more typical diseases.

He said that the typical programmer diseases are too much stress, pains from sitting around all day in a wrong stance (? sorry, I'm not a native english speaker) and gaining fat from too few sports ;-)

I've been able to avoid the first and the last but suffer from sitting in a wrong position ;-) Granted, it's sometimes very hard to avoid the stress, especially when the project is in the ending phase and the release date is nearing. But apart from that there is few need for stress. I've seen on my coworkers that very often people impose stress on themselves or let their bosses impose stress on them. And most of the time this stress is unnecessary and can be avoided.

(This is why I never wanted to be a games programmer although I'd really like to write games: that industry was too much stress ten years ago and it seems that it got worse)

I think that if the work is imposing too much stress on you, you really should think about looking for another employer. I know very well that this sounds so much easier than it is, and that some people don't have the opportunity to change employer easily. But there are times when one has to ask oneself: what's more important ? My health or my great payment ? Wouldn't a job that's not as well payed but is more fun/healthier be a better deal ?

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

[fishbot]

Does anyone have any recommendations on how to present something like this to management in a convincing manner?

Resign.

Quite right. After being forced into 80 hour weeks and treated like scum ("I don't give a f*ck about the f*cking employees" is an actual quote from the MD) I quit. They responded with a nice 60% raise and a promise that it would all be better.

Didn't trust 'em as far as I could comfortably spit out a rat, but I had a cunning plan. I took the monster raise and worked it for 6 months to see what happened.

After 6 months, things were actually worse. I quit again and went to work somewhere much nicer, using the rather inflated salary to negotiate a very healthy starting rate at the new job.

I doubt that they will ever learn why I was so p*ssed at them, but that's just not my problem any more. They're already reaching the point where reputation precedes them and people turn down job offers based on that. They can't last much longer without a serious change in attitude.