I’m sure you’ve heard the term before, in scenes from Hollywood films or mentioned by the techies of the internet: “Debugging” - but what does this term actually mean, and why do people who work with computers seem to be doing it so often?
Are they bad at their jobs?
Don’t they have hobbies?
Today, I am inviting you into our little cave of darkness to share a few not-so-secret secrets about the mystical process of debugging a system or a code, and explain why you should give the person you know who’s currently debugging a pat on the back because they could probably use some support right now.
Once you have your first “draft” completed, you will begin debugging. Debugging is the process of getting your code from where it is to where you want it to be. I remember back in grad school, I had this reoccurring dream: I would be swimming through the darkness of my code, endlessly searching for the bug of a misplaced comma living somewhere between my meticulously crafted lines. I’d search endlessly and always woke up before I could find it. The funniest part about this whole experience was that when I shared it with one of my professors, she laughed and told me that she nearly had the exact same dream – and strangely, so did my coding peers when I brought it up. Apparently, debugging in your sleep when writing an intense piece is about as normal as eating meals at your desk, which was absolutely news to me at the time.
When you’re writing code, there is usually a very specific goal in mind. You go in with a plan and purpose – you begin to see the necessary components, linking mechanisms, inputs and outputs; the works. At a certain point, speaking a coding language becomes very natural and your fluency enables you to write almost without thinking. In some cases, the style and design of the product becomes so much a part of you that you barely need to plan it out, just turn on your favourite coding playlist and let your fingers do their thing. You begin weaving a code, lines and spheres of structure that communicate and build towards a beautiful finished product. And at some point, you are ready to see if it works.
And most of the time, it does not.
This is normal.
There are a few different stages to debugging code, and everyone does it a little differently. The way you search for errors and optimize also greatly depends on the style of project you’re working on, and the place you choose to write your code. Essentially, debugging is the process of looking for errors. Some key guiding components of debugging include Function, Efficiency, Effectiveness, and Validity.
At a very surface level, here are some key practices that can be included within the debugging process:
Function: When you are debugging for function, you are simply trying to run your code to see if it works. This is crucial, for obvious reasons, and can be lengthier in time if you are hand-scripting a code. Some programs enable you to debug in stages by debugging individual functions or modules throughout. In other programs, the debugging process includes the entire code running altogether. Coders can comment out parts to test individual sections if needed by putting a “#” before lines – this technique is also used to make notes in the code, explaining function and process. Your code will return “Error” messages when something isn’t working – these are both extremely helpful and headache-inducing.
Efficiency: When you are debugging for efficiency, you are checking to make sure your code is running at the right speed to meet your goals – without sacrificing quality. Once you get your code to run, it is important to note how much computational power it requires and to make modifications to ensure it runs smoothly with as little stress to your system as possible. If you are a neat-freak like myself, this also includes cleaning comments and clearing unused portions, and renaming version codes. Efficiency also means being able to share your code with others, access versions and changes, and know your code inside and out using comments – even if you haven’t seen it in a while!
Effectiveness: When you debug for effectiveness, you are searching to prove and demonstrate that your code is completing the task to the absolute highest degree of certainty. This can include many trials and challenges to put your new program through; such as tweaking and modifying sections, and plenty of statistics. It’s making sure that the working gears you created fit together properly, doing what they are supposed to be doing, that your math is adding up correctly, and so on. You want it to work and work very well – if one component is off, you cannot trust the result or outcome, so you test each function and component in the way it needs.
Validity: This one is special and can have two stages depending on what type of system you are creating. When you are validating your code, you are looking to ensure that it functions to the best of its ability across conditions over time. Especially with A.I., you’re not influencing or modifying the code in each iteration – you’re ensuring that it is functioning as it should autonomously (training wheels are off!). In terms of architecture, if you are following one, validation is required to ensure that you are not breaking any laws or rules of what you are modeling – it must be valid in its representation of what you are modeling, and function according to the principles of the subject in all ways (and any way that differs must be made explicit and be addressed).
Much like editing a document, different styles of projects require different editing processes and strategies to make sure the program is running as it should in the best possible way. The points outlined are my main tried-and-true stages of debugging, which are very common across coders. I am absolutely sure that others may have their own terms, methods, and ways of going about this, but the goals are consistent. I find it helps to recognize that coding, like writing, is truly an art form; therefore, each person has their own style and flow.
So, hopefully, now you have a bit more insight into the wild, frustrating, fun, tedious, challenging, rewarding world of debugging. Now you can understand just how much your friends and colleagues put into ensuring that a code functions as it was intended to. It is not just out of care and love for the creation to be flawless, but out of necessity for a functional and accurate program.
And trust me when I say, it’s not just about the comma.