TheDarkTrumpet.com

For pretty much my entire professional career, I’ve been stuck doing pretty much debugging. While others have been given the opportunity to create and all, I’ve been more trying to fix messes people create. This gave me maybe a bit more of a conservative approach to programming than my peers…but that’s for another blog entry perhaps. What I want to descrive here is what I’ve learned in the years I’ve been stuck trying to fix code.

First of all, I want to say that programming is hard – but debugging stuff is harder. There are tricks – but the first and most important trick is leave your laziness at the door, you won’t survive debugging much unless you do so.

So the tips:

/Don’t be afraid to get your hands dirty/: You can learn a whole lot by breaking something and then repairing it. This doesn’t mean go about breaking code on a production system, but if you have your own sandbox that isn’t gonna be hurt screwing up – just mess around. The more you screw up stuff, the better you’ll learn.

/Don’t be afraid to take time in figuring stuff out/: Really when you’re debugging, don’t expect that the solution will be totally obvious or that you’ll get it done right away. Some issues I’ve worked with have taken near a week or so + of a little work every day to finally accomplish fixing. You’re unlikely to be timed on how fast you can squash bugs – and you’ll reduce your stress level a whole lot by just chillin and spending a bit of time here and there.

/Keep a notepad nearby/: I can’t begin to emphasize how important this is. Your notepad is basically your breadcrumbs. You need to jot down notes, flow charts, variables where they are at various stages of the program, and so on. Your notepad should be your #1 tool, it’s way more imporatant than any technological tool you feel you need to accomplish the task.

/Know how to follow the electronic breadcrumbs/: var_dumps, echos, prints, puts, and so on – these are your keys to where things are going. Some languages/frameworks have really good debuggers, but again you’re relying on tools. Sometimes the best thing you can do is just output something where it’s visible and take a look at it.

/Be sure to read the entire problem reported/: A lot of times I’ve found that if I skip over a bit of a ticket, I waste more time in the long run because I thought I knew better or may have read it already. This reminds me of an activity when I was a kid. On the top of the page it said to read everything before beginning – and like many impatient people (which was most of my class), I started right away. The last question was to skip the first 20 steps and do the first and last two. I felt like an idiot, and as you can tell, this lesson has stuck with me for a long long time.

/Know your resources/: Generally speaking, I hate asking people for help. I’m probably polar opposite of everyone else in the office in this regard (and perhaps in other regards too), but I prefer to rely on myself. With that in mind, I do a great deal of research on my own before I go about asking anyone anything. While you may not want to go as far as I, don’t make the human next to you or in your office your first go-to for the answer. Do some research, spend some time looking it up. Then, if you go up to the person for help in the end at least the person will be impressed by the research you attempted to try beforehand. This is just like math, know your resources and really try at problems before having the teacher give you the answer. With this in mind, google is probably your favorite friend. You’ll never know what you get out of it.

/Remember balance/: Balance in everything in life is important, and it’s no different here. Bug squashing all day long is enough to drive anyone senile (or at least make someone really on edge). Try to mix in some stuff in the day – such as tools to make one’s life easier, or innovate a bit more here and there, maybe refactor something, or document something.

In the end, really all this comes down to as few of tools as possible to get the job done and you getting in the engine and working on it. Remember that if you’re debugging something, your job is unlikely to be making things perfect. Try to get the engine working, and be happy with that. Perfection in this world is pretty much impossible to obtain.

I hope this helps some people.