over the years i've learnt the hard way that it's not possible to go through opiate withdrawal and debug Java at the same time. (trust me on this one.) interestingly, i've been seeing quite a few students who can't use a debugger at all - even the shockingly intuitive NetBeans onboard one - and i gotta admit, when you first see it, you're gonna be weirded out if you're not a programmer.
of course, having coded in hospital, on sedatives, with cannulae in both arms, for a good few weeks of my programming lifetime so far, i got a fair amount of sympathy for the kiddies i see trying to wade through their 5000+ lines of Java one by one, trying to find "the bit that won't work". and being the friendly campus opiate addict that i am, i decided to shoulder-surf my way around the lab for a while last week instead of doing my own work, in the hopes of finding out what they were commonly fucking up.
before i get going, don't get no wrong ideas here. i have no problem with people fucking up - i do it myself all the time, and as it's often been stressed over at Coding Horror, everybody fucks up. with that in mind, i found out they were pretty much all doing the same thing.
nobody was debugging their half-finished code. nobody had written either JUnit tests, or little test classes with souts to the console (System.out.println, that is); the main route seemed to be
1. write (usually quite good) code for the entire programobviously, this isn't exactly the most efficient way to be doing your shit. it's stressful, and more's the problem, it's a total waste of your precious lab hours. it's actually simple to avoid: you just have to run the program after every method, or group of interdependent methods.
3. notice bugs, attempt to debug whole program (5+ classes) at once
4. realise sheer monstrosity of task, give up, go for milkshake.
that means, your cycle is code method, compile, test, debug, code method. if you gotta write biddy little classes to test your functions, go for it. the time you'll spend writing those is nothing compared to the stress you'd experience trying to work out all the bugs in a program when nothing's been tested, nothing is guaranteed to work and anything could be the problem.
that is, a debugger isn't no exterminator. it's not a flamethrower for removing a huge infestation of glitches, it's a pinpoint laser for picking them off one by one as they arrive; you just gotta keep looking for them, as you go, constantly.
(taking out kitchen roaches with a DVD-burning laser)