How not to debug your programs
From my experience in teaching programming, one of the biggest hurdles to overcome is debugging. It’s one thing to remember syntax of a for loop or a if..else, it’s a different thing entirely to know what to do when a program won’t run.
While teaching beginners, I observe some really curious behavior when they encounter errors — and not all of them helpful. Here I will list out some of them, so that you can better avoid them.
NOT READING THE ERROR MESSAGE
Knowing that you have failed can be rather painful; we can get by in our life by ignoring our mistakes, however this is not an option with the impartial computer. Not matter how we deny, plead or cajole, the computer demands perfect syntax and grammar from us like an impartial deity.
This is why I find it strange when my programming students immediately switch back to their editor to look at their code when an error message pops up. I know that it feels like a slap in the face, however the error message is there to give us clue as to where the problem is. Not reading error messages is like refusing to look at your bills; even if you shove the unopened envelopes to the bottom of the pile, they still exist.
BEING FIXATED ON THE LINE THAT THE ERROR OCCURS
Another common pitfall is to be too fixated on the line of code that the compiler or program reports the error to be. I have this experience before — the compiler is helpfully pointing out which line it had failed on, but I read it and I started cursing because that line of code looked perfect to me.
Usually, this means the error is somewhere else. Yeah, but why then did the program reports that the error is on that line then? Well, just because the program won’t execute that line doesn’t mean that line is the culprit.
For instance, forgetting to include a semicolon on the line before the reported line could cause the compiler to freak out on the wrong line. This is especially true in languages where you can include other files (C, C++ and PHP, to name a few).
COMING UP WITH CONSPIRACY THEORIES
I have came across programmers making staggering leaps of logic when their code won’t work, and I not just talking about complete beginners at the craft. Something stopped working and while they don’t blame aliens or secret weather machines, they will blame the library that they have just included, the most recent changes they made to the code, the changes they just made to the database schema…and the implausible it’s just won’t work so it must be a bug with the compiler.
While it is true that I have came across bugs that were fixed with a reboot of the computer, that is usually not the case. The reason is: there are many reasons for a program to fail. Until we actually read the error message and deduce what it is really about, all theories are just what they are at the initial stage — wild guesses.
Conspiracy theories costed me hours when one of my software started mysteriously sending email twice to customers, and well, people are generally not happy to receive duplicate emails. At first I jumped to the conclusion that my code is malfunctioning — despite it working perfectly fine for weeks. I began to think of race conditions, caching issues, CRON not functioning as it should, and so on till it finally struck me. I had loaded live data in a test server, and the scheduler was live on that as well.
CAUSATION FALLACY
I am referring specifically to the “after this, therefore, because of this” fallacy (or post hoc, ergo propter hoc). It can be described as: “Y happens after I did X, so X causes Y”.
While in many cases the last recent modification could have caused a bug, this line of thinking doesn’t always hold water. The latest modification could have caused different branching in existing code, made use of an erroneous state variable set by elsewhere in the program, or when external data is involved, erroneous or outdated data.
Another common variant of this problem is when the coder neglected to test his code for a while (or did a minimal test), and promptly blame the bug on the last immediate change he made. Cue endless hours of teeth gnashing.
NOT BEING FAMILIAR WITH ERRORS
Textbooks, tutorials and online video courses rarely show you error messages or what could go wrong. A lesson on Udemy or Youtube is edited to near perfection, with the instructor seemingly having a photographic memory of every API call and programming construct. While it helps to impart how to do things, it doesn’t help when your own programs are falling apart.
As a lecturer and tutor, I show my students the rough edges of programming. I am just as human as they are, and I make mistakes from time to time. Yet those mistakes are golden opportunities to show them what is the proper way to deal with errors, and to interpret and understand what they mean. It’s always helpful to have a mentor who had spent endless hours trying to find out what went wrong with his program (and actually solved it!).
So far I have talked about what not to do when encountering errors in your program. Stay tuned for the next article in this series where I share some of my favorite debugging techniques.
I conduct programming coaching and lessons in Singapore. To find out what I do, go to my page at Jumpstart Coding.
