Doing It On Paper

Work has been going well these days, but I've decided to take a break from the standard progress report and tell one of my lessons learned stories.

In school programming courses (high school or college), students are often forced to look at programs, trace, the flow of execution and write the programs output. This seems like a trivial unimportant exercise while you're doing it, but the skill can come in handy. This happened to me last year when I was coding Genesis SEED, my teams 3D multi-player IGF entry last year. The game has 5 basic modes: single player, multi-player server, multi-player client(with client-side prediction), peer-to-peer host, and basic peer. It was a year ago and I don't remember what the actual problem was, but basically the game worked in some modes but not in all. I figured that I made a mistake and somewhere something was missing. I must have forgotten a step somewhere. That's why I made the following:



I found that rummaging through papers while I was looking for something else. I thought it'd be cool to show to everyone. By tracing out the code I was able to find out what was missing. I didn't even have to do it for every mode. This is just one example of paper to the rescue. Sometimes when we debug, we want to quickly get into things and start changing code, but often what we really need to do is sit down and write it out on paper and examine it.