Everyone Should Learn to Debug Without a Debugger
Monday, 11th June 2012, 22:42
I should admit this straight off the bat, I don't use a debugger for server side coding. It may not entirely be through choice, the options for Node.js are limited. You can use the built in --debug option and then node-inspector but it is very clunky and you'll spend half your time waiting for it to reconnect, or restarting it so it can reconnect.
But it's okay, because when I first learnt to program I never had a debugger then either. Not that BASIC perhaps needed one, heck you could say programs with it rarely got to the level of complexity that you couldn't figure out what was going on without a few carefully placed PRINT statements and some careful testing.
However when I moved into trying to figure out Z80 assembly language, oh my, that was a jump. At least when BASIC did something really bad, it threw an error, albeit a hard to always figure out one. When coding in machine code, if your code goes kaboom it can do it in a totally unexpected and random way, with garbage flying over the screen and anything you hadn't saved gone for good. In the good old days anyway.
Still, it's never too early an age to learn the all important edit, save, run cycle.
OMG a Debugger!
When I got into coding with C under MS-DOS, I think this was my first proper experience of a real debugger. Although a far cry from today, you couldn't exactly inspect variables easily, and it concentrated far more on the machine code your C had compiled into than the original C source itself, but it was a start.
I think at that point, I pretty much used one for years after that, until I started ASP web development anyway, at which point I went back to my roots and did it all off spamming Response.Write lines and goggling at error messages. Although when I got myself a GP32 and began coding for it, I really did go old school.
That thing took me right back to my Spectrum days, as whilst I did a fair bit of the development under Windows with a debugger, when it came to some things like hitting the sound hardware directly and playing with interrupt timers, the device itself was the only place to go.
And much like the olden days, when the code for the MP3 player I was making went kaboom, it did so with no error messages or warning. Sometimes I got a black screen, other times a horrible screeching noise. Working out what had gone wrong would take a while, and mainly consist of putting in pauses at certain points so you knew if it got somewhere or not safely.
But I Need My Debugger!
I'm not denying you it, but bear in mind it is just a tool and there will come times when you will have to live without it. Even in client side javascript there are things which behave differently if you use say Firebug, to not. Try debugging mousedown events with it and have fun constantly having to restart your browser because the window never got a mouseup as that ended up being sent to the Firebug window.
Services can be even more troublesome, as you step over code and the connecting software times out waiting for you to read everything.
I appreciate this might have come across a bit preachy, but never underestimate the power of spamming lines to a log, or flashing the screen on a portable device. Doing things this way can often make you appreciate the flow of your code and what went wrong with it much more than a debugger can.
Unless of course you are working on aeroplanes, in which case, please bloody use one!