One of the difficulties I have in writing blogs for a coding school is that I never know whether I will be read by a newcomer who is just beginning to dip his/her toes into coding, or by a senior developer handy with seven programming languages (heck, maybe even one of our graduates).
That question became especially pressing for me last week, when I decided to write a blog on how to get rid of bugs: should I put together tips for the beginner, or for the expert?
Ultimately, the most sensible thing seemed to do both. Thus, today’s blog will be addressed to beginners, and will offer suggestions that may seem obvious to the more experienced programmer. Next week, we will cover advice that is less intuitive, yet general enough that it should be helpful at least to the intermediate programmer, if not the truly advanced.
With no further adue then – how do we manage bugs?
First things first: error messages
At first, you are going to hate error messages. Trust me though, in time you will come to love them. Your IDE giving you an error message is the equivalent of a videogame putting a directional arrow in a dungeon: it won’t get you out of trouble by itself, but it’s going to point you in the right direction.
Even if the error message itself isn’t particularly clear on what went wrong, you can copy-paste it into Google to start getting answers – or at least, you can use it as a starting point. If your error message reveals that your code is unable to store a certain value for whatever reason, then skip trying to ‘solve the bug’, and ask Google directly how to store that type of value in the conditions you are working with. An error message is a clue, weak or strong. So use it.
Backtrack to the source
If the bug does not manifest itself via an error message, then it’s time to get surgical. Usually, a solid 70-90% of the work of debugging is really about finding out where things are going wrong. Sometimes fixing the bug will require you to rethink a chunky part of your logic, but more often the solution will be trivial once you’ve simply figured out where to look.
Finding the bug is a two-stage process. Firstly, look for the symptom: if you’re getting an unexpected or unwanted output, then go directly to the line of code responsible for generating that output; if your system crashes, activate your debugger, and let it run until the crash grinds it to a halt at the line of code where this is happening.
Right, you’ve found the point where things get critical – now look for the cause. The part of the code where the symptom occurs is not necessarily where the bug itself is. The Stack Trace in your debugger will let you investigate the specific history that led to the error. Examine that history, starting from either the most recent operation or the one that looks most pertinent to your error. That’s grind, true, but it’s normally enough to unearth the true origin of the problem, and from there, figure out the fix.
When all else fails, get help
In some fields of work (and life), getting help should be the first thing to do. When debugging, it should always be the last. It is possible to turn to Stack Overflow or support forums for help, or, when the going really gets tough, even to the vendor of your operating system.
But the condition for getting help is that you must be able to describe what your problem is accurately, clearly and in depth. If all you can bring up is ‘my welcome animation on the homepage isn’t running’, then rest assured that nobody is going to be able (much less willing) to solve the problem for you.
Do your best to fix the bug by yourself, and use everything you learn from that process to come forward with a precise, step-by-step report of what is going wrong and where. Only then will you start getting answers.
Bonus tip: Talk it out
Asking for help should come after your personal research – but that doesn’t mean the research itself must be conducted in isolation. Get a colleague to sit down with you, and explain to them what the problem is and how you’re trying to solve it. Even if they have no useful suggestions, simply being able to step out of your mind for a second can do wonders in terms of seeing the issue with fresh eyes. If a colleague is not available, talk to a non-developer friend. Or, get hold of your good old rubber duck. Getting your work done before asking for help is something different than getting all of your work done alone.
This completes our debugging tips for the beginner, as covered also in our courses. Join us next week as we dive into something more sophisticated, and a lot more counter-intuitive!