in Project management

All Work No Play, Makes Jack a Dull Game Developer (Part 2)

“Wanted: Young, skinny, wirey fellows not over 18. Must be expert riders willing to risk death daily. Orphans preferred. Wages $25 per week.” Pony Express advertisement, 1860.

That would be a funny anachronism if it weren’t still so true. OK, so game companies are not asking potential candidates to risk death every day, but they surely are asking them to give up their lives to the company.

I really wish I had saved some of the truly horrible job listings that I have seen over the last few years to contrast it to the Pony Express one. Instead, the “best” one I was able to find on short notice was one with the following requirements:

“Be a self-starting, hard working individual capable of maintaining focus within a rigorous, deadline-driven production schedule. Have a passion for games.”

In itself, there’s nothing really wrong with those requirements. Heck, I consider myself to be a good fit based on that description. Unfortunately, this is more what the job listing is really looking for:

“Be a self-starting, hard working individual capable of maintaining focus in the face of massive crunch time and unrealistic milestones, and able to pull through with massive heroic efforts. Have a passion for games and nothing else, so you won’t mind spending all your time at the office. Not over 25. Singles preferred.”

In this second part I argue that long hours in game development are not only something that could be avoided, but that they’re actually detrimental to the project.

Are long hours inevitable?

I want to start by debunking fourth myths:

Myth #1: There are lots of young kids out there willing to take our jobs.

That’s very true. However, most of those “kids” have no idea what the job is really about (hint, we’re not playing games all day long), and they’re hopelessly underqualified. So if a company decides to replace its staff with lots of young, inexperienced developers right out of college, well, that’s their choice. I doubt they’ll manage to create a decent game, and they surely won’t be able to make a second game with the same staff after burning everybody out. Ironically, this comes after the announcement that EA made in response to ea_spouse’s blog that they were planning to do 75% of their hires from developers straight out of college.

The modern version of this myth is offshore development. In some circles it has become quite a paranoia. It hasn’t hit us hard in the games industry yet, although art is the area seeing most jobs going abroad. I don’t want to get into an offshore debate here, but suffice to say that the jobs easiest to replace are those that can be done fairly mechanically, which are in turn the ones that can be done best during major crunch without a clear head.

Myth #2: If you’re getting paid enough, you should be willing to work any amount of time.

So maybe this one is actually true. If someone is willing to pay me enough in one year that so that I don’t need to worry about money for the rest of my life, then sure, they can have my undivided attention 24/7 for a full 365 days. No questions asked. Most of the time though, we’re just talking about a few measly tens of thousands of dollars extra. Good money to be sure, but it doesn’t even come close to the value of spending time with my family, being outdoors, or just doing different activities.

So no, getting paid a good amount doesn’t entitle the company to my full devotion.

Myth #3: If the company pays for overtime, then everything is OK.

Paying for overtime might be a good start, not because of the money (see myth #2), but because it would discourage companies from applying crunch time at the drop of a hat. Maybe they would start looking into alternatives (cutting features, delaying the release, changing design, etc).

But the point is, even if all the extra time is payed for, it won’t make people any more productive or make them do better-quality work. It’ll just make it so some of them don’t complaint so much. In the end though, most people would agree that receiving a lot of money and not having time to spend it is no way to live. It might be an OK short-term situation, but certainly not something to keep up indefinitely.

Myth #4: We’re doing games because we love it, so we have to put up with any hours.

It’s true that most people are working in the games industry because they love what they do. Game development has been my hobby for as long as I can remember, and I’m currently as close to my dream job as I’m ever going to get. That doesn’t mean it’s not a job though. We’re professionals working for a company and getting paid to do a specific job. In the same way, I love cycling but it doesn’t mean I want to do it 12 hours a day every day (going out with the club on an hilly 80-mile Saturday ride is plenty, thank you 🙂

At the same time, it doesn’t mean that we’re counting the minutes before we can punch out at 5PM. Sometimes what we’re doing is fascinating and we want to spend some extra time. As long as people are still rested and motivated, that’s great.

So I claim that there’s nothing different about the games industry that makes long hours inevitable. The only remaining, and most important, question is whether long hours are actually useful and help ship a better product.

Are long hours useful?

I’m convinced that developing the technology for a game is like running a marathon. I really think that the analogy carries very far. Notice also that I qualified it as applying to the development of the technology, not the game as a whole. Design and art have some of that touchy-feely creative mystique that can be very bursty. Heck, some of the best art in the history of humankind has been done while under the heavy influence of drugs and totally altered psychological states. So for all I know sleep deprivation actually helps. I’m going to limit myself to talking about technology development, which is what I’m familiar with.

Just like in a marathon, you start out a project knowing that you have to accomplish something (ship a game), in a rough timeframe (2-3 years, or whatever the plan is). It’s true that in game development there are more unknowns and changes along the way (although there can be quite a few in a marathon as well—unexpected hills, cramps, dehydration, etc), but the same general principle applies.

The way game development seems to work is by snoozing through the initial gunshot. Instead of settling into an early even pace, we just doze off at the start line or do some stretching. Then, after a while, we start to leisurely walk down the course. We don’t worry because we’ve promised that we’ll hit the first timed spot by minute 30. As the clock rolls around to minute 25, we realize that we aren’t going to make it there by the time we promised at this pace, so we sprint for a couple of miles and manage to make it there in quite a heroic sprint. Mission accomplished for the moment. We sit down. Take a break. After all, we worked very hard. Then we repeat the same cycle, but each time less walking and more sprinting. Soon we start not meeting the times we wanted. Eventually, we’re faced with a situation that in order to complete the race in the time we wanted, we would have to sprint like hell for the rest of the course. So we actually go ahead and try it (knowing perfectly well that we’ve never been able to sprint like that for an extended period of time). Of course, we get really tired. We need to stop. We move back our estimates. We try it again. Eventually, if we’re lucky, we manage to make it to the finish line. Much later than we had hoped for, but we’re extremely proud of how much effort we put into it. “I gave it 120% percent in the last 5 miles, man!”

OK, enough of that story. The point is that the best marathons are run at a very constant pace. People who go too slow (or too hard) early on end up paying for it in the end.

Edit: This is actually funny in an embarrasing kind of way. I had originally linked some great plots of Marathon running times that were supposed to support my theory of a steady pace winning at the end. Unfortunately, I read them backwards and they really were not helping any 🙂 I chuck that one to the runner not being a top-level athlete.

The following plot instead shows the times of some of the top positions in the 2004 Boston Marathon. It’s a much better example that the previous one because the data applies to top athletes and over the same course and the same day. The most important thing to notice is how constant the paces are. They’re almost perfectly linear for runners 1, 8, and 15. Runner 21 on the other hand, is a good example of someone who was trying to push it too hard at the beginning and paid for it at the end. We’re still talking about world-class runners, so the differences are minimal, but it illustrates the point nicely.


Fine. So “crunch time” doesn’t work for marathons, but what about for games? Does the snooze-and-sprint schedule pay off in game development?

From personal experience, I have to say the answer is absolutely not. I can totally feel how productivity starts dropping for me after 35-40 hours of work per week. There’s still some value in working about 60 hours because I will get more work done than in just 40 hours, but only about 10-20% more because the amount of work completed doesn’t scale linearly. After about 80-100 hours, productivity doesn’t just get slower, but it actually starts going down. Mistakes, bad decisions, and lousy quality quickly overwhelm any benefits from the extra hours.

So, is working 60-hour weeks best from a company point of view? Not really. If I try to keep the same schedule a second week in a row, productivity is much lower, and it drops off much more quickly. By the third week, we’re already in negative productivity territory after about 40-50 hours. The insane schedule from previous weeks takes its toll really quickly and it’s clearly felt. This is a rough plot of productivity vs. work hours. Keep in mind that I pulled the numbers out of thin air and they’re just based on personal experience.


We also need to consider other consequences apart from pure productivity gains. We’re not machines (I’m not anyway). The third week in a row of crunch I’m basically working at half efficiency, and I really dislike that. I can’t think clearly. I see myself doing sloppy work. I just want to get done with stuff. All those things don’t make me any happier to have to spend countless hours at the office and take a big bite out of morale.

Am I alone feeling this way? Apparently not. Plenty of other people seem to agree. It seems pretty well documented that productivity plummets very quickly after a certain amount of hours. This quote from the c2 Wiki summarizes it all for me:

The story that brought work hours home to me was one Ward tells. The C++ team was working nights and weekends, the Smalltalk team went home (tired) at 5 and rested all weekend. Management wasn’t happy with the results of either team, and pressured the Smalltalkers to work more hours. Ward’s response, “We would if it would help.”

Similar conclusions were reached in studies quoted in Tom DeMarco’s classic Peopleware and Slack books.

When I can work around 40 hours per week, I come in every day to work energized and looking forward to the day. I get tons accomplished. And when I get home, I actually spend quite a bit of time learning about related topics, working on different projects, or just letting my mind wander and do free associations. I tend to have most creative breakthroughs when I’m relaxing and doing something unrelated to work: riding my bike, showering, or even falling asleep (never go to bed without a notebook on the nightstand!). None of that happens as soon as the work hours start to increase. It might be a very small short-term gain, but a large long-term loss.

In conclusion, a short, focused, period of crunch time to reach a particular goal is probably fine and can be used to good effect. Anything longer than a week or two, and it starts having very negative consequences. In any case, you also need to make sure people get good rest afterwards, otherwise they won’t be able to go back to working at full efficiency.

Some people will argue that a two-week crunch every so often is good for the morale. I disagree with that. Who is going to be more proud of what they accomplished, the team who crunched for two weeks, or the one who didn’t have to do any crunch at all and met the same goals?

How to avoid long hours?

All this should be completely common sense, but I’ll reiterate here anyway.

  • Don’t assume long hours are inevitable. Do what you can to avoid them.
  • Don’t waste time. Don’t re-write things you don’t have to. Don’t spend half the day talking by the coffee machine. Don’t play Call of Duty for 3 hours at lunch.
  • Don’t procrastinate. An hour of work now is just as precious and valuable as an hour before going gold. Do what you have to do now.
  • Prioritize your tasks (or get your manager/boss/designer to prioritize them for you). Be ready to drop the least essential tasks if you start running out of time.
  • Work with a sense of urgency. Large amount of pressure are no good and they tend to paralyze people or make them work in fear and make mistakes. On the other hand, no pressure at all tends to encourage people to take detours, and spend forever to get something perfect (as opposed to good enough to do what it needs to do). A small amount of pressure is perfect to keep the pace up.
  • Use agile development. It’s a great way to keep re-prioritizing your goals and hit moving targets.
  • Work hard for 40 hours. Play hard by going home at the end of the day. Maintain a sustainable pace.


The most important thing to keep in mind is not to do something you’re not happy with. Game development is a fascinating activity, but it doesn’t mean you have to give up the rest of your life to it. Anybody should be able to work in games and keep a reasonable life outside of work. If things are not reasonable at your company, bring up the subject and try to change it. Show them this article or some of the links mentioned here. If all fails, there are other companies out there that would be happy to have you.

  1. Slack

    Nice to know that someone in the in the game industry cares about the development process and ‘peopleware’. Noel Llopis got a good blog called ‘Games from Within’.

Comments are closed.