Slashdot Mirror
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?"
I called in Well today because I went in to work on Saturday. I never would have considered that at my old job but I'm finally starting to realise that if I restrict myself to 40 hour weeks I get a lot more done and I have more time to take care of important things like household chores and family stuff.
I've coded, on average, 70 hours a week, for the last six years. This has been on my own project, which is coming along nicely (after about a dozen complete rewrites, language changes, and overhauls).
I don't think I could accomplish this on someone else's code, however. If you love the project you're working on -- if you really believe in it, you can push yourself past the limits of a 50 hour work week. If it's just a job to you, then that motivation isn't there.
But then again, as my signature says, caffeine can help. Not in the long term, but I think people could definitely exceed 80 hours of worthwhile coding in a week if they were consuming lots of caffeine. It really is a wonder drug.
EA doesn't deserve all this criticism. We live in a free market, if those coders don't like their 80 hour weeks, they should quit.
Maybe I should apply at EA.
+ Donald Gunth
+ Email: dgunth@quicktek.net
"Caffeine is the greatest lubricant ever created." -ESR
If you have tenure, you don't have to kill in order to eat. If the professor you're working for has tenure, he doesn't need you to kill in order to eat.
The reason people work 80+ hour weeks is because if the project doesn't ship on a certain date (and this is particularly prevalent in the games industry, in which payment is often contingent upon meeting milestones), they don't eat.
"OK, so why not set the milestones a little more properly -- so that you're not forced into such a situation to begin with?", I hear you cry.
If you're a game studio, and you demand sane milestones, the publishing house won't sign the contract. And that means you don't even get into the buffet line, let alone eat.
In academic terms: Nobody has tenure. And unless he was willing to sign his firstborn away as part of a contract that guarantees delivery of either a Nobel prize or a $500M IPO out of your research within six months, your professor doesn't even get to apply for the grant money.
Yes, it's possible to work for 80 hrs a week, or even more. However, you need to define "work" here. Would you define reading/replying to emails as work? Would you define attending meetings as work? Believe me, these small numbers add up to take away a sizeable portion of your workday and your energy.
/. as time wasted. It's also an integral part of the process of coding. Hence, i do claim that one can "work" for 80 arse a weak.
If you're talking about pure coding, IMHO, coding is not a tap that can be turned on and off at will. One needs to "get into the flow" to get some real coding done, and this doesn't happen easily (at least for me). I'll often spend hours tinkering around with stuff, browsing some site, but won't for the death of me, be able to finish writing a simple class or stored procedure. Maybe, i'll keep getting stuck, maybe i'll be too distracted, maybe i'll decide to read some documentation instead. Then, suddenly, everything will start happening smoothly and i'll complete a day's work in a couple of hours.
I don't know if it works the same way for others, but i really feel that one cannot just keep coding continuously all day. At the same time, i will also not consider the interstitial time spent tinkering around and writing comments in
This is absolutely true. The lead programmer on my current project works at least 60 hours every week (and has for years) and more than that about half of the time. He's in at 6:30am and usually leaves around 6:30 or 7:00pm and he NEVER takes lunch breaks. Towards the end of the week, any problem that he "solves" quickly usually requires at least a day or more to re-fix later on. Unfortunately, his seniority makes him almost untouchable when reporting problems like this to senior management who see him as "dedicated and just as productive as everyone else". What they don't seem to notice is that he needs to work about 25-30% more hours per week than the rest of the staff just to produce adequate (not great) code.
Does anyone have any recommendations on how to present something like this to management in a convincing manner?
Does EA sprinkle magic pixie dust on their serfs to get around this problem
From the NY Times article, it sounds like EA uses coercive techniques and naive young employees. My own response is that I won't buy another game from EA until they reform the way they treat their employees, and I encourage others to adopt the same policy.
My attitude on this isn't just sympathy for EA employees. It's enlightened self-interest. At 35, I'm apparently too old to get a job with EA at any salary, let alone a fair one working under fair conditions. I choose not to support such companies.
Prior to my current position I was a Cost/Schedule Engineer with a construction firm. There have been numerous studies on labor productivity versus hours per week worked and they all point to an optimum long term weekly rate of around 50 hours in the building trades.
For short term gains (read: less than two weeks), 60 or 72 hours can give you a boost, but after abour 3 weeks you actually would have been farther along chugging at 50 hours per week than at 72. After a week or two of 72 hour weeks productivity is in the toilet.
Also, safety problems increase, attendance problems arise, etc. etc.
No construction site in the world would consider working those hours long term since it is so counterproductive.
> Are these rational working conditions?
Of course not, which is why here in the EU it's against the law to be employed for more than 48 hours per week. No-one benefits from longer working hours: employers suffer diminishing returns and employees turn in to square-eyed antisocial nutters.
(A partial exception is Britain, where employees can work more than 48 hours, but only if they "volunteer" to do so.)
Young coders can be more focussed with fewer distractions. Older coders tend to take on more job responsibilities. Constant little interrupts cause great losses in productivity - it can take me up to 20 minutes to get back in to the flow even after a 5 minute interruption to help somebody else.. Younger people also tend to have fewer out of work distractions. The people going to EA are often very keen and willing to sacrifice their personal lives for work. I remember those days back in the .com boom when I was only 21 ;)
I've also found that as I get older (almost 30) that I have harder time sleeping. If I work until the wee hours it's harder for me to make up the next night by sleeping for long enough (I managed to sleep for a whole 7 hours the other day - I was so impressed!). If I work too late of an evening then I have trouble sleeping that night, which also needs to be made up later in the week. I still like to binge drink like I'm 18 again at the weekends so I don't catch up then either.
I think going a 40 to 50 work week is hardest. Anything beyond 50-55 hours and people start substituting their social lives by socializing at work. I feel sorry for those with families working that hard. In my experience every 2-3 hours extra work after that is only equivalent to an hour of 40-hour-a-week work. And yes, errors go up, things get forgotten, process goes by the way-side and there's always something that comes back and bites your further down the road. You end up constantly in a reactive fighting fires mode.
I did it a few times... but not for long. It depends on the level of involvement you have on the project and how interested you are to that project.
:)
Without counting programming blitz at home, so far, my worst cases were:
- 60 hours for 3 weeks, followed by a 4-day blitz of 12+ hours per day.
- 2 weeks to do a 3 months project (2 weeks at 12+ hours per day, last days "till you drop, wake up and start again")
- 2.5 days non-stop.
The first example meant a buggy software. We had to code for months under pressure (at 40hr/wk) and had to implement new features and correct bugs for 3 weeks with overtime blitz and finally we had to finalize things under horrible pressure for a few days while the client was actually waiting on the line. The project was ambitious, the idea was good but it was too late for too little.
The second example, I was required to create a software from scratch, with a semi-specific design. After thinking about it a few hours, I immersed myself in code, taking time to auto-demote myself to a coder level and put a "do not disturb under death penalty" sign around my neck. People knew it was hard, I knew it was hard. I was under my own things and after hectic days of coding, I released a somehow bug-free software. Very minor tweaks and nudges had to be done for the final version, mostly due to interfacing with other people's work.
The third example, something slipped management's mind and I had to rush a new feature. The feature was made. I was happy.
In all these examples, only the first one was a disaster, mainly because we were pressed to do something for a very long time, giving our 120% for weeks, followed by giving yet again our 150% for a few weeks, followed by giving a 200% for days. One has only so many percentages in reserve.
The lesson here is how much sustained work I was able to give, at comparable quality. A programmer is somehow like an artist: if he is given time to contemplate his canvas first and at various times during the project, he is able to create something much better than someone who just go heads on and resurface when it's done.
Dammit, people, the reason the PHBs can get away with this sh1t is that they know that even if you have the self-respect to refuse they can easily replace you with someone that doesn't value self and family enough to say no.
I know that folks in the US have been trained from birth to believe that worker solidarity = communism = ultimate evil, but those whose comments can be summed up as "stop yer whining and get back to work" miss the damn point. I want to work to live, not live to work. When there are enough workers willing to whore themselves out, it makes it impossible for the non-whores to expect fair treatment.
If the developer community would stop putting up with it, the PHBs wouldn't be able to require it anymore.
Two words: Unionize coders.
I know many of you out there will hate that suggestion, but it's a tool workers have to stop runaway PHB's. Here are the difficulties:
* Defining who is a "coder", because any union contract would immediately have management trying to make employees not part of that contract.
* It's got to be international, so that our colleagues in New Delhi are on the same side as we are.
* Getting people to join.
If we can organize ourselves to produce desktop suites, surely we can organize ourselves to give us more money and time.
I am officially gone from
I remember one major coding crunch at the small software company I used to work for: We were preparing a significant set of enhancements to our core product, while at the same time working on bringing to market a major new product. The two projects shared giant chunks of code and logic, so it wasn't completely off the wall, but it was still clear that we were going to have an awfully long, hard slog ahead of us.
As a kind of non-overtime overtime incentive pay, management set up a deal to pay a bonus at the end of the project, based on hours worked above a certain point, with all kinds of complicated sliding averages and whatnot. My office-mate and I crunched the numbers, and realized that in order to get any appreciable bonus at the end of the project, we would basically have to commit to 60 hour weeks for the indefinite future.
Well, you know, neither of us were exactly in our twenties any more. I had a wife and a brand new house and a 45 minute each way (non rush hour) commute; and while I still felt spry and nimble, I no longer felt immortal and god-like, even with the help of Mountain Dew and m&ms. I was in my mid-to-upper thirties. I decided that, while I was still capable of working arbitrarily many hours in a week for short bursts during an emergency, there was no way that my health would stand up to 55 to 60 hour work weeks every week, indefinitely. Both my office-mate and I decided not to bother signing up for the bonus program.
<irony> (A couple of years later, I fell ill with a chronic and incurable medical condition which has left me essentially unable to perform any work at all; so I suppose I needn't have bothered being so careful).</irony>
In fact, much to management's chagrin, only one member of our small programming staff -- call him "X" -- actually decided to commit to their schedule.
Determined to get a decent bonus for his troubles, X threw himself into it, working 60 and 65 hour weeks. In the meantime, my office-mate and I upped our hours, too, but to a lesser extent: 55 hours one week, 52 the next; and so forth.
The weeks wore on, and we inched along towards our various goals. X was doing his usual fine work, but he was looking more and more haggard (we were all a bit worse for wear, actually). His code got a little sloppier at times.
And then one morning, he committed a bunch of working code to the wrong place, and instantly wiped out about 20% of our company's source code repository.
Did we have backups? Yes, we had backups; but still, it took three or four of us much of the day to both restore everything and to verify that everything was correct. The final tally was, roughly, at least one full man-day flushed down the drain in fifteen seconds due to nothing more than pure exhaustion.
Eventually, the crush passed, of course. It is probably a coincidence that X left the company shortly thereafter, although he came back a year later or so. He's a very good programmer, but some of the code he wrote during that crunch -- especially later on -- was, shall we say, sub-optimal.
We were the company that coined the term Internet Time. How did we do it, by sleeping at the office and working close to 120 hours a week. Was it healthy? No. Was it smart? Probably not. Did we produce a good product? You tell me. We wrote Netscape Navigator 1.0 in less than 6 months time. (Please don't confuse it with Navigator 3 & 4, which was a very different team) But there was a catch. We had all written a browser before. We were not trying to dream up a new product completely from scratch. We had a good idea from the start of what we wanted to build. Those set of circumstances don't happen very often. If I was tasked with building a new product that had never been attempted before, I would never try and work that many hours. Good design does not coexist well with exhaustion. There are plenty of other reasons not to work crazy hours as well, one of them is "having a life"... :lou
Heh. Been there too, man. I was an electrician working on the Hard Rock Hotel in Las Vegas during the two weeks before it opened. We were still pulling wire the night before the grand opening, and we'd been working 16 to 20 hours a day all that last week, and many of us worked 36 hours straight the last two days. I tell 'ya, we were making really bad mistakes left and right. One thing about electrical errors, they're a lot easier to find than programming bugs. You just look for the smoke coming out of the fluorescent ballasts and then check which circuit got piped into the 277V panel instead of the 120V one. The only good part was getting paid triple-time at union scale.
If a job's not worth doing, it's not worth doing right.
Hey, this is really interesting information. Not to sound contrarian, but do you have a source for this? Online would be nice, but I'm willing to purchase it if need be. It would go a long way toward silencing some dumbasses that I know.
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.
Something to think about when libertarians/conservatives claim Europe is hopelessly behind in competitiveness. We get the same amount done AND we have much more pleasant lives.
Being bitter is drinking poison and hoping someone else will die
Oddly enough, I went throgh a period where I found coding after a couple of drinks or joints actually helped produce better code.
It was during a period where (modesty aside) I was maturing from "someone who could program well"[1] to a "good programmer"[2]. I've always been unusually aware of my own thought processes (as I suspect many programmers/hackers/martial artists/meditators/etc are), and I've noticed that good programmers all seem to go through a stage where they stop programming with their left-brain[3] and start more right-brain-thinking[4].
During this time I discovered that, as long as I already understood the problem fully, a couple of drinks (or joints) seemed to help me internalise the "rules" of a language, and spend more time on the actual creative side of programming - solving tasks without spending the whole time thinking about syntax or grammar.
Of course, some of the code was still pretty squirrely (what a wonderful word), but I do remember on several occasions waking up in the morning, running over my code again to check for bugs, and actually being blown away by how elegant some bits were - I hadn't thought I was capable of writing code like that at that point in my education. I remember one time finding a solution to a problem in linear time that I hadn't even realised sober could be done in less than exponential time, and it quite freaked me out for a while afterwards.
Even now (several years and several languages afterwards), I find coming back to a problem after a drink or toke can sometimes help you see "alternative" ways of solving it, often wildly different to how you'd normally go about it...
Fotonotes:Everything in moderation, including moderation itself