Double Buffered

A Programmer’s View of Game Design, Development, and Culture

Coding on the Edge: How To Survive

Posted by Ben Zeigler on August 18, 2009

In the theoretical “well run company” there will never be a situation where you, the programmer, will have to write incredibly critical code under extreme time pressure. These companies are either extremely boring or quickly go out of business. In today’s exciting world of Online Game Development, this is inevitable and is known as “launch”. Now, not everyone will have to engage in this practice  but anyone working on infrastructure or performance will find themselves suddenly under heavy demand a few weeks before any big update. I suggest running away. If you’re better at programming then you are at running away (I’m very bad at running away) here’s some advice that may help you out when you have to write 5,000 lines of mission critical code in 2 days:

  1. Channel the Rage: The reason you have to work 70 hours this week is inevitably because someone screwed up. It could be you, a coworker, or a third party, but the cause is going to be a mix of forseeable and unforseeable mistakes. Feel free to note your theories on the personal failings that brought you here, but until things are actually working there’s really no point in complaining to anyone about it. There is no way to keep track of all the possible issues involved with an online game, so missing something critical just means you are human. Whatever anger you feel about the cause of the situation, you want to focus it towards the code itself and not who wrote it. Anger is a pretty good short-term motivator
  2. Focus Your Efforts: Programmers already have a hard time dealing with distractions and interruptions, but during a crisis this gets even harder. When there are 5 critical things going wrong at once, the natural inclination is to try and work on all 5 at once. However, this just means you’ll fail to fix 5 critical issues. Try to pick a problem that you think matches well with your skill set and coordinate with other programmers to get the rest managed or delayed. Departmental divisions and work politics should be basically discarded at this point, because no (sane) person will complain about your rudeness while the world is on fire.
  3. Enforce Breaks: When you have a lot of work to be done in a short period of time, you need to be careful to give your brain some time to relax. The relaxation time between hard crunching is often when you realize the insight that can save you 6 hours of horrible manual debugging. I like to code/debug for 3 hours or so at a time during crunch, and it’s hard to beat video games for breaktime. Also, you NEED to get at least some sleep. Never work on less than 6 hours of sleep, the amount of bugs you add when tired will cost you far more time then you gain by skipping sleep
  4. Assume You Are Stupid: I generally like to design for ease of debugging, but this is absolutely critical during crisis.  When you write code under pressure the odds of you making a mistake are higher, and your code should be structured with this in mind. Whenever you add in a new feature make it run-time switchable at the expense of code simplicity. Add in all the logging you can think of. All forms of cleverness should be strictly banned. I’m not normally into code review or pair programming, but when you’re tired you NEED someone else’s eyes on your code. One of you will figure out the part you screwed up.

Finally, there has to be a point where the crisis Ends. If a company tries to make you crunch for more than a month at a time, you’re at a company that doesn’t either doesn’t understand how programmers work, or is completely incompetent at scheduling. It can definitely be exciting and rewarding to put in long hours and accomplish the impossible, but you WILL burn out. But, hey, I guess some people like the burning out part?

Advertisements

One Response to “Coding on the Edge: How To Survive”

  1. Noah said

    The only thing I would add is “Try things”. If it won’t make the problem worse, get possible fixes up sooner rather than later. The extra data points are often invaluable.

Sorry, the comment form is closed at this time.

 
%d bloggers like this: