Humans are natural pattern matching machines.  Evolution of this ability enabled us to better survive on the plains of africa, and lack of it is what makes non-primates suck so hard at sudoku.  Of course our drive to look for patterns even where there are none also has its dark side.   It enables the deluded beliefs of the religious, got me addicted to Rubicon before the show was cancelled, adds fuel to the fire of conspiracy theories, and has caused me to see patterns in the way people use debuggers that may or may not actually be there.


“Thats a nice score for a girl”

debugger usage: stage 1


Almost without exception, all the beginner programmers I’ve known universally have no interest in debuggers.  After talking to many of them, it turns out they all had a few complaints in common.  Because UNIX is what is taught in college, people’s first introduction to the debugger tends to be GDB which can be a little overwhelming for people not used to it.  Combine this with the fact that the programs people tend to make towards the beginning are easily debugged by sprinkling printfs around, there isn’t much motivation to bother learning how to use a debugger.  Finally, and this is particularly shocking, they were never taught about debuggers in school and just didn’t understand what they do or why they are useful.


Why it’s dangerous: The primary danger is that while you can debug very simple programs using printf, you’re being incredibly shortsighted and not learning a skill that will become absolutely essential once you start working on larger games and more complicated problems.  Also, adding printfs as you discover problems forces you to recompile, makes your program run slow, and just plain doesn’t work for many problems.  Finally, printf is buggy or unavailable on some systems, and its a really annoying way to debug multithreaded programs.


Advice: do yourself a favor and learn to use a debugger.  Any one will do, you just have to learn the basic concepts and how to use it to track down various types of issues.  As an additional bonus, since many schools don’t teach debugger usage, knowing how to use one is a huge plus when applying for a job.

debugger usage: stage 2


So the student finally gets around to figuring debuggers out and they get a taste of the power that comes with them.  Sure your program /looked/ like it was functioning correctly before but now you can know for sure! You can set breakpoints, step over every line, into every function, and check the value of each result.  You can set hardware breakpoints to find memory stomps, view the data in regions of memory, check asm and registers to follow optimized code, and all kinds of other great things.  With all that information available, the stage 2 debugger user never wants to run unattached ever again.  It gives them a very nice sense of security that eventually becomes a crutch.


Why it’s dangerous: With some people, this debugger dependence can cause them to become lazy with their logic, and a bit careless.  While before, you had to really think about what you were doing because you couldn’t check every result, now you can write any old code that kinda looks correct-ish, single step until something goes wrong, edit, recompile, and debug again.  Putting aside the obvious danger of believing that haphazard logic is correct just because it worked that one time you stepped into your function, this is a huge time drain.  It takes a tremendous amount of time to copy your elf to the target, start up the debugger, reset the target, load back into game, get to the point where you hit your breakpoint, and check all the results.  It’s even slower if you don’t know how to debug optimized builds and therefore are forced to always run in debug.  Some problems either can’t be debugged with a debugger, only occur when you run unattached, or maybe there isn’t even a debugger yet for that new platform you’re working on.  When faced with issues like these, many stage 2 debugger users tend to throw up his hands and give up.


Advice: Some problems require debuggers, but if you are firing up the debugger to find some problem in gameplay logic that you could have easily figured out by eyeballing the code, you’re Doing It Wrong.  Also, don’t depend on debuggers too heavily because there will come a day where you won’t be able to use one to get you out of that mess you’re in.

debugger usage: stage 3 (logic renaissance)


Confession: I have spent most of my life as stage 2 user, and debugger addict.  I didn’t use it as a substitute for carefully writing code, but I pretty much never ran unattached.  I could debug anything, even final builds, so there was no reason for me not to run unattached.  I didn’t even know there were people that ran unattached until I came to Q-Games.  I noticed my boss never ran in the debugger so one day I asked him about it.


me: “why are you not running attached”

boss: “because it’s slow”

me: “but how can you be sure it works?!”

boss: “I look at the screen and if it looks right, it works”

me: *blinks Zorak-style*


Now mind you my boss is a graphics guy so he really can tell if something is working by looking at the screen, but that didn’t stop me from calling him insane.   It took me a year or so but eventually I figured out he was right.  A good majority of problems can be found (or avoided in the first place) just by using your brain instead of a debugger.  Stage 3 debugging is really all about knowing when to reason something out and when to turn to the debugger.  Sometimes, even problems the debugger was designed to find (like DMA errors) are more easily and quickly found just by taking what you know about the problem and working backwards.


Why it’s dangerous: there is nothing particularly dangerous about relying on your own powers of reason, or only using a tool when its needed, but don’t let it swing too far in the opposite direction.  I know a few people who refuse to fire up the debugger because they think they should be able to figure out any problem without it.  Ego is the main danger here.


Advice: there are a lot of stage 1 and 2 n00bs out there that could really benefit from your experience.  Take the time to show them a few tricks and help the generation that grew up without the Spectrum, Amiga, Micro, and C64 suck just a little bit less.