A beginners Guide to debugging

For my passionate bug hunting developers to be, here are basic strategies and principles for a less stressful experience.

Inevitable

Has any author ever written a perfect story ? Has there ever been a speech you’ve written without a revision and small adjustments before the final release? It is definitely not impossible but just in the same way that writing can require a revision, most programming demands debugging. As you continue in your day to day life of programming, bugs are simply inevitable. They say through trials and tribulations opportunities to confront our own understanding occur. It may not always feel great but whether you have a hate or love relationship with debugging its a fundamental skill that everyone works on. There is no one method to debug but there are many tools and strategies effective for debugging.

Before touching on these tools and strategies we should briefly touch on unit testing.

Writing Test

In a perfect world, a perfect functional app that has no issues with its maintainability or the user experience would have its bugs caught before they are even committed. The amount of time you would save if you did not have to debug would ideally be used to write tests if this were the case. Tests allow. us to make assertions about the shape of our data and expected output for our functions and components, before they become a problem. Testing is much more elegant than printing or console.logging that would be all over my app in hopes of revealing the issues themselves. Of course, that requires learning how to test, testing however is not the only option available.

Reading our Errors

If we haven’t written tests or our coverage on debugging simply hasn't touched on it there is no issue. Our encounter with a bug isn’t like a deer in a headlight predicament. Although it may definitely come as a shock since no bugs are usually created on purpose, when we encounter a bug we are likely to be confronted by a helpful message, showing us the errors of our ways. The message can be vague, but it provides some direction. Error messages can come in cryptic one- liners which can be the computer equivalent of a should shrug. Start by looking at the very top, the first problem(bug) encountered will always be noted there. It can be vague but it would surely provide a file and line number; which at least gives us direction on where to start.

tYpOs

I could never recall how many issues i have created for myself when programming in a rush or simply hitting a key i did not mean to hit at all. Before reaching out to our best friend Google i suggest checking the indicated file and line number for typos. A missing period or comma, mismatched quotes, a closing or opening bracket, a variable or function misspelling, there are so many ways to be off by a single character. Anyone with experience programming has done at least one of these and just thinking back its simply a part of the learning experience. Grammatical errors should be ruled out for the cause of your bugs right from the beginning, before moving on and spending hours questioning your sanity and basic logic just find that missing semicolon.

Google It

Google has become a great asset, resource and friend. Google is the number one search engine and that goes without reason, it is the mountain you can climb but never move. A beginners, chances of our problem having never been encountered are pretty low. Learning from those who have experienced and overcome the same issues is wise. By plugging the error into google you will likely find another humans source to having encountered the exact same issue as you. Stack Overflow, Github, blogs and similar issues will come up one after the other. Don’t be vague. Ask google your exact problems, it may not always reply with a perfect answer but you’ll gain momentum. A bit of research goes a long way to point you in the correct direction.

Making your own assertions

We are humans and we are not perfect. More often than not , errors can be the result of bad assumptions about the shape of our data. This can be especially true when pulling data form an external API or passing it down via callbacks or React props. When dealing with external API’s a mighty and worthy tool id recommend is Postman. It helps you see and familiarize yourself with the data and the way it is structured. I can’t recall how many times i assumed the correct data and only the data i wanted and needed should and would be pulled when making the request, just to see nothing that i expected.

Debugger

It may go by many name’s by its goal is the same, to help us find, crush and debug our applications. If our input are what we expected but our outputs are not, a slower approach can be a more ideal. Byebug for Ruby, pdb for python, and known as debugger in JavaScript , there should be some utility available for setting up breaking point in our code. The breaking points run the code and freeze it at a particular point. We can then take a peek at the inner workings of our functions, try different approaches and continue running it afterwards.

Check your logic

As i mentioned we are human and we do make mistakes. Although we take time and plan before beginning our logic could truly be flawed, what works on paper may not work. Sometimes in order to see a problem with our logic, we need to hear ourselves explain it out loud. Talking through our thought process and receiving another persons feedback can make strides in your approach. A friend, a colleague, an inanimate object they are all top notch listeners. Even stackOverflow and the communities created can be a great source.

“If debugging is the process of removing software bugs, programming must be the process of putting them in.” — Edsger Dijkstra

I love this quote because i never truly realized how much i agreed with it until i began writing apps on my own. Although the process is not always ideal, debugging a bug can be one of the greatest feelings ever. It’s a part of the learning curve and what builds us up. Good Luck and i hope we continue to help one another truly.