In this article we\’ll talk about what debugging is, how to debug your code, and how you can get better at it.
What is Debugging?
Debugging is the process of detecting and removing existing and potential errors (also called ‘bugs’) in a software code that can cause it to behave unexpectedly or crash. To prevent incorrect operation of a software or system, debugging is used to find and resolve bugs or defects. When various subsystems or modules are tightly coupled, debugging becomes harder as any change in one module may cause more bugs to appear in another. Sometimes it takes more time to debug a program than to code it.
Why Should You Learn About Debugging?
Bugs and errors are so prone to happen in software development because it\’s such a conceptual and abstract activity.
As developers, we work with information. We organize it, move it, update it and edit it, send it places and then receive it again.
We work with information all the time, but not directly with it. Information isn\’t \”actually\” there within the computer, at least not in the format users think of it.
Within the computer, there\’re only electric pulses, that are then abstracted to 1s and 0s, and then again abstracted into whatever information we\’re working with.
To interact with and make use of computers, we use programming languages. These provide levels of abstraction from the actual tasks the computer is performing, and representations of the information we\’re managing.
Programming can be a very abstract activity, and it\’s really easy to quickly lose sight of what\’s the actual task the computer is performing, or what information we\’re acting upon in a certain line of code. And from there on, it\’s easy to give the wrong instructions to the computer and miss the target we\’re looking for.
An inside joke in the software development world is that devs normally spend 5 minutes writing code and 5 hours trying to understand why things don\’t work as they should.
How to Get in a Debugging Mindset
Pay Attention to Error Messages:
In almost every development environment, if your code fails, you will likely be shown an error message that (to some extent) explains why your code is failing.
This may seem like silly advice, but you might be surprised to see how many programmers don\’t read error messages carefully and just react to the bug with the first idea that comes to their mind.
Error messages are there for a reason, and this is to give us at least a first idea of where the problem is coming from and how to debug your code.
If the error message you get isn\’t clear to you, or you can\’t figure out why you\’re getting it, a good first step would be to Google it.
One of the many amazing things about coding is that the online community is huge. Almost surely there are tons of people already that have faced the same bug you\’re facing, and that has solved it and explained it so other people don\’t have to struggle with it, too.
When googling, a good idea is to be as detailed as possible in the search.
I\’ve also learned that removing things that are only particular to my code and not an error everyone would get, as the name of my function (\’mickTheBug\’), is important.
Another good idea is trying to use trusted and recent sources. Trusted means either official documentation or solutions that have been validated by others. Recent means solutions that have been implemented as recently as possible, because something that worked five years ago may not be the best way to solve the problem right now.
Official documentation always should be the first thing to check either when you\’re learning something new or dealing with an error. That is why it is important you know how to debug your code.
Official docs are typically the most complete and updated source of information for any given tool. It sometimes may feel tedious or overwhelming to go through so much technical information, but in the long run, I think it saves time.
The deal with official docs is sometimes they contain so much info and it\’s explained to such a detailed level that it\’s more confusing than explanatory.
Because of that, I think it\’s a good idea to always use more than one source for any particular topic, and \”hear different voices\” explain the same thing. Usually, only after reading the docs, a few articles, and watching a few youtube videos, do I feel I get a good understanding of the tool I\’m working with.
Explain Your Logic to Another Person or a Duck:
Programming can be an abstract activity, which makes it easy to lose sight of things, make wrong assumptions, and misinterpret the information we\’re working with.
A good solution to this is to go through your code line by line, reading it and explaining it out loud as you go. The rubber duck technique is a popular way of doing it, but you can choose your favorite pet or imaginary friend. =P
The idea is to force yourself to actually read your code instead of just assuming you know what it does. In this way, you can check the logic in your mind versus what is actually happening in your code.
Narrow Down Your Problem and Understand Where the Error is Generated:
As your codebase gets bigger, it will be hard to analyze every line of code in the search for your bug. So it\’s a good idea to divide and conquer, starting your search in the places that are most likely to generate the issue and how to debug your code.
Take a Break and Think about Something Else:
Programming is a very mental activity. So the way your brain is working at a certain moment or the way you\’re feeling will affect directly the way your code will look and your ability to solve problems in an effective way.
If you spend hours reading, repeating out loud the same lines of code, googling, going over Stack Overflow questions, and still your code fails, sooner or later you\’ll get frustrated and start putting pressure on yourself.
Here’s the of how to debug your code process:
1. Reproduce the problem.
2. Describe the bug. Try to get as much input from the user to get the exact reason.
3. Capture the program snapshot when the bug appears. Try to get all the variable values and states of the program at that time.
4. Analyse the snapshot based on the state and action. Based on that try to find the cause of the bug.
5. Fix the existing bug, but also check that any new