Developers at every given point have to debug their code. This is to rid the project of 'bugs'. Are they bugs per se? obviously not! The term debugging came about in the 1940s when Admiral Grace Hopper at the time working on a Mark II computer found a moth stuck in a relay. As you've guessed, she termed it as 'debugging' the system. In mechanical engineering, Thomas Edison termed the technical difficulties and errors he encountered as 'bugs'. This was back in 1878. Guess we might never understand their full obsession with the word. However, any error in my code is a bug and I will be sure to debug it!
Debugging as we know it today largely involves identifying and solving errors in your software for optimal functioning.
How do Bugs Come Along?
Bugs in your project can be attributed to the following common reasons:
Unstructured code
This involves bad code practices such as failure to break down complex code into structured bits easier to recall and easier for team members to follow along. Being that we are human, this gives room for errors as it is difficult to follow alog as you develop your program.
Deprecated Syntaxes
At times, especially with frameworks, changes happen in code syntaxes and failure to appraise yourself with upgrades may have you using deprecated syntax in your project leading to bugs.
System Failures
System failures are not foreign to the programming world and they may have your project depicting undesired outcomes due to bugs
Technical Debt
Technical debt will always and surely build up leading to buggy code. Technical debt is far much worse in debugging as it involves a build-up of neglected best practices over long periods.
Best Practices Whilst Debugging your Code
Bugs will always happen, it's inevitable. To err is human, remember? With all the potentiality of bugs in our code, adopting best practices in debugging can save you tons of time that would otherwise be lost frantically 'yelling' at your computer.
Read the Documentation
Every programmer's famous saying is that 4 hours of debugging can save you 20 minutes of reading the documentation...Who does that? Certainly not you, not me either 😏. If documentation is available, use it to save you tons of time wasted doing things the wrong way. Time is money...or so they say..come on! Be that programmer who has documentation as his/her best friend.
What does the error message say?
A keen look at the logic behind your error messages goes a long way in solving bugs. An error message, in the case where there is one is the surest way in understanding your mistake and successfully guiding your debugging 'sprint'. If anything, it also gives you perspective on what to 'google'. Let's admit it, some errors, you just have to google, only to find you among thousands of devs with the same issue!
Keen follow-up of the code structure
To fully manage a bug, you should fully follow up on the particular code structure leading up to the error and fully analyze it. To successfully debug, you need to first understand what the code is meant to be doing and what it isn't. Breaking down the complexity of your project into smaller bits will help you narrow down to where the error originates from.
Avoid accruing further technical debt
As earlier noted, technical debt in itself leads to bugs in your code. Whilst debugging, a critical best practice is to avoid getting into more technical debt. Solving one bug should not lead you to accrue further errors that build up as technical debt in the long run. Be smart and make calculated moves.
Write readable code
In the case where you might have to debug code that happens to be badly written or named, writing readable code while at it is a best practice. We are assuming you didn't write this code, right?😄 If anything, this is not how you write your code 😉. If you happen to inherit a code base with unreadable code, make it your mission to properly name the variables, comment the code and make it delightful and lighter.
Take Breaks
Every time I am debugging I sometimes tend to forget the power of breaks. There is always this yielding sense of breakthrough that makes me think I will be solving this in the next 10 seconds. 10 seconds turn into hours, unfortunately. A 20 minutes break can surely save you 2 hours of debugging. Breaks work in keeping you rested and helping you see things from a different perspective. Don't underestimate the power of breaks in debugging. Else you'll end up smashing your laptop out of frustration. No? It happens 😂.
My Debugging Escapades
My encounter with debugging is not rosy. If anything, I don't think debugging can be any rosy. I have spent lots of time wondering what was wrong yet I omitted the most trivial of things from my code syntax. Bugs have had me question whether I belong in the programming world. However, I live for the sense of accomplishment that comes with solving bugs successfully and seeing your code run as expected. Nothing beats that feeling.
Conclusion
This article is my submission for Hashnode's debugging writeathon. Use the #DebuggingFeb to read more. I am stoked that you have read this far. What have been your encounters with bugs? Could you write about it? This writeathon runs till 12th March. #DebuggingFeb