[...]
For those of you who are in the midst of development crisis, I’d like to share some burnout recovery tips – having periodically gone through this process.
1. You should have natural absences as a part of the development cycle. Given its duration for roguelikes, these are likely to be long: holidays, weddings, child birth. I have fond memories of sitting in an Internet cafe in Ios, Greece, next to the pool, trying to debug an edit file preventing someone from winning the game, while I was ‘on holiday’ when I first travelled to Europe. The fact I was working on the game during a self-imposed absence was a good sign that I was still fresh and enthusiastic.
2. Be sure to have one or more trusted lieutenants to shepherd bug fixing during your time away. Development is a meritocracy rather than a democracy: but that doesn’t stop you from involving others as spokespeople, bug triage, and as a support network. Some of these people don’t have to even understand what you’re doing – a trusting partner, friend or bemused work colleague is still enough to provide a measure of respite, if not respect, for what you’re trying to achieve.
3. Your brain doesn’t exist in a vacuum – no matter what the mind/body dualists say. You need to step away from the keyboard and remain physically active. I swim, lift weights, walk – and you’ll end up thinking about what you can do in the next coding session while you work out. Make sure your computer isn’t too far from where you exercise to take advantage of that post-workout inspiration.
4. Program when you’re interested in programming. Don’t feel like you have to do anything. Although discipline is important – you need to actually write code after all, this is supposed to be an enjoyable hobby, not work. I have never found setting a target useful – work on what interests you now, and what you need to do will sort itself out some other time.
5. There is nothing worse than sitting down whilst tired and trying to code: the bugs per line of code goes up, way up (And forget drunk programming – although that’s where more than a few design decisions have been made).
6. Don’t measure yourself by your failures. And don’t dwell on them.
7. Get used to the natural rhythms of how you work. Listen to your body – learn when to snack, when to load up on the caffeine and do an all night session, and when to just sit there and churn out documentation, or even play the game.
8. Contribute to something related to your project, but which you’re not directly responsible. Even though I set up the procedural wiki, I only treat it like a part time exercise and let some of the other contributors do more of the heavy lifting. That way, I can still feel like I’m being productive while I’m not working on Unangband.
9. Don’t spend too much time talking to other people about what you’re planning on doing it, and just do it. Unfortunately, when it comes to computer programming, a problem shared is a problem doubled (see the Mythical Man Month) – ultimately you’re the only one responsible for how well you do. That’s not to say communication isn’t important: a good indication of whether an idea is feasible is whether you can explain it clearly. But you can do this explanation asynchronously: by documenting or blogging the idea instead.
10. The only way you can solve a problem is by exploring the problem space with code. This may mean writing sub-optimal code now, instead of designing for later, that ends up in the code base. Don’t worry. As long as you get the user interface right, you can always come back to it, and cause code regressions at a later date.
You’ll notice that most of the above recommendations are preventative in nature, and most are just practical programming advice, instead of specific burnout busters. Prevention is the best way to delay the onset of burnout, but you'll ultimately still suffer its effects. But provided you accept the natural process of ups and downs while developing, you’ll see that this state is just one end of a continuum, one which you can recover from, despite what you may think at the time.
[..]
.