For most inexperienced software developers, the prime focus is on building things. They don’t put much focus on debugging as they should when the reality is that they’ll be debugging more than building new things. So, when encountered with a bug, they don’t really know how to approach it especially with the doer/builder mindset they have. In this post, I want to go over 7 tips on how you can become better at debugging.
1. Mindset Shift
As a developer, you’re often thinking with a doer mindset. That is you’re always asking “how to do/build …” type of questions. However, when the code is not working as expected you’ll need to shift the way you’re thinking to an investigative mindset. You’ll need to start asking “why is … happening” to try to identify the cause.
2. Check and Research Error Messages
From my experience, the best type of bugs to encounter are the ones that the computer tells you what is wrong. Yet so many inexperienced developers choose to ignore those messages and try to figure out what the problem is themselves. So, before you start going into detective mode make sure there are no error messages for your code. If there is then resolve them or do additional research in order to resolve them. Get into a habit of reading error messages because they can really save you time and headache. Besides, those error messages are made to stand out for a reason.
3. Use a Debugging Tool
When you’re new to software development, printing out messages to the console might feel like the natural way to troubleshoot a bug. While the method still has its place, it is better to get into a habit of using a debugging tool that is made for the purpose of debugging code. When you’re printing out statements to the console, it doesn’t provide you with the entire picture. It only shows what you want and if your assumption is incorrect then it doesn’t help you figure out the issue.
While with a debugging tool, you can set a breakpoint (this would be probably where you put a console print) and when the code reaches that point you can see everything happening. With that capability, you can see all the values and even step through the code step-by-step. As you can probably imagine, this would make things so much easier.
4. Try to Zoom in to the Issue
In your code, each component should be responsible for certain tasks so when a bug occurs you shouldn’t need to trace through all the code. Identify which component the bug is coming from and dig deeper from there. As a result, you’ve taken something big and broken it down into smaller pieces. You’ll find the smaller the pieces the easier time you’ll have to identify where the problem is.
5. Take a Break
When trying to figure out a bug, it is important for you to take breaks. Just like with coding, it is mentally exhausting so you’re brain can only do so much active thinking in a day. Once you reach your limit, it is time to take a break from it and do something else. This doesn’t mean you’re not trying to solve the problem; instead, you’re letting your mind work on it in the background. Remember that one time when you’re walking, eating, or wake up and you just have an answer to the problem you were trying to solve? That’s your mind working on the problem in the background.
6. Review the Logic
Computers are dumb and do exactly what you tell it to do. So, if something is wrong, it is very likely to be the logic of the code. Be sure to review the logic of your code. Ideally with a fresh mind because you’ll catch things that you would miss if the logic is still fresh in your head. Somehow your brain is filling in the gap for you even when something is missing so you don’t realize it is missing.
7. Make Frequent Commits for Working Code
I’m going to assume you’re using version control of some sort. When you have a working solution regardless of how small the code changes are you should make a commit. This is because you’re commit is like a save point for you to start over from there. If you try to go from start to finish without a save point when something goes wrong you’ll have a tough time. How would you know at what point the code was not behaving correctly? You’ll need to trace it down from the very start and that’s just a pain you could have easily avoided.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with debugging? What are your strategies for debugging software?
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.