Here is a list 7 simple debugging practices I picked up as a tutor. I hope they are as useful for you as they were for my tutorees.

Start with a Running Program

The first thing you should do when you start with any project is a “Hello World”. The level of complexity can vary with how you do this (e.g. starting with a template), but the idea is the same: have something running. It is much easier to debug when you have a running program because you can get feedback in the form of print statements.

But what if the program doesn’t even compile? I’m glad you asked.

Comment till it Works

Let’s say you started coding for a bit, changing things here and there, but all of a sudden your program won’t compile. It’s giving you some strange error on line 127, which is odd because your code is only 50 lines long. You start looking around to find the bug but you can’t seem to spot it. You can’t add print statements because the program won’t run, so what do you do?

Start commenting out your code. Begin from the bottom and work your way up, continually re-running it to see if you caught the bug. If you did step 1 right and started with a running program, there must be some point that you introduced a bug. Now it’s time to dig it out. I like to employ a Binary Search to hunt down the defect but use whatever technique that floats your boat.

Sometimes the commenting gets pretty extensive. You might even have to go all the way to your main function before it begins to work. If at this point your code still isn’t compiling, then you have an IT problem and that is something you’re gonna have to figure out on your own. I would suggest you start over with a new (running) project and copy your code over one bit at a time.

Alright, you’ve narrowed down the bug. What’s next?

Read the Damn Error

I know, I’m guilty of this too. So often we just glaze over the novel on the console, but unless you’re coding in C or C++, most compilers have rather helpful messages that will help you identify the error. You might even get lucky and the compiler will give you suggestions on how to fix it. Just don’t dismiss that jumble of words for nonsense, unless of course it’s C/C++.

More often than not, the bug will have an error code that you can google to get a specific fix. If that doesn’t work still try to read the error! Even if you don’t quite understand what the compiler is saying to you, you’ll start to recognize what errors are tied to which bugs. That way, in the future, you can fix your code without having to google it.

Great! So you’re code is running now! What about your run-time errors?

Print, but do so Intelligently

Printing is a great way to debug. Given there are better methods such as using a debugger, but at this point and time it’s important that you get comfortable with printing. Now it’s tempting to print every value you come across so you can keep track of it all, but that’s a recipe for confusion. Just as important as getting the value is making sure it’s the value you’re looking for. Too often I have found myself with 10 or so printed value that I couldn’t quite remember what they were each for. Label your outputs, your 5 seconds future self will thank you for it. So will your 30 minute future self: they’ll be working on another section of code and will realize the printed value is from a statement you should have deleted.

Print to your hearts content, but remember to label an equal amount.

Sanity Checks

Never fully trust your code. How many times have you said “Well my variable should be * ...” but you still get an error? I’ve learned very quickly in my life that the word ‘should’ is very dangerous and needs to be handled with military grade dicipline. Even when the value is staring you right in the face, make sure it’s the right one at the right time. You can do this by (intelligently) using print statements to verify your values. This goes for functions too. It’s good practice to throw a print stub at the beginning of each function to make sure it’s being run. I usually just put the functions name, but again, do whatever floats your boat.

Just remember, every time you say ‘should’, do a sanity check.

Talk to a Rubber Ducky

Once you have made enough sanity checks, it’s time to talk to your therapist. Given a coding buddy is better at helping than an inanimate object, but they’re probably working on their own project at the moment and (let’s face it) what you need isn’t another programmer, but a friend.

Rubber duckies are excellent buddies. They don’t talk back to you, they’re always smiling, and they don’t drop out last minute on your group project. Your rubber ducky is here to help, here is how you can use it:

1. Talk to the rubber ducky.
2. Explain what you’re doing. Tell them how you did it.
3. Go through each line of code you’re having trouble with while explaining what you’re doing.
4. Realize that you didn’t make the right function call.
5. Correct the error.
6. Thank your rubber ducky and then continue coding.

Look, I get it. We all get lonely sometimes, and there is no shame in talking it out with your fellow bathtub companion. You’ll realize you have more in common than you thought and that you make a great coding team. One, a brilliant coder, the other, the perfect confidant.

Never be ashamed to talk to your rubber ducky.

Walk Away

Well, I guess it’s come to this moment. You’re at the end of your rope unsure as to why the code isn’t working. You have tried everything and yet you still don’t seem to be making any progress. When you’re at this point, the best thing you can do is walk away for a bit. Your brain is an amazing machine, it can work on problems without you even realizing it. If you just take a breather and focus on something else, your subconscious will keep spinning on the primary task at hand. After a few minutes, give or take an hour, come back to your code and give it another go. You’ll be surprised how useful a fresh perspective is.

Your subconscious is a powerful tool. Let it do it’s job.

Final Thoughts

I hope you can tell I’ve pulled my own hair out many times because I failed to follow these practices, but now I’m a better coder because I learned from my mistakes. Eventually the more you code, the better you’ll get at spotting these bugs before they happen. You’ll also employ better debugging practices such as TDD (Test Driven Development) for quicker, more efficient programming. However, the most important thing you can do now is be patient and keep coding, you’ll get there eventually.

Cheers