Debugging is fixing bugs, i.e., errors in the code written. It is one of the tasks a developer finds themselves in for hours while working on a project. Sometimes, it seems like a breeze to fix the bug; other times, correcting it takes a herculean effort. These bugs come in various categories: behavioral or logical, syntactical, run time, etc. One of the categories, called heisenbug, is one of the most difficult to debug. It takes hours to days to get a sense of it.
During the past three years in D10X as a developer, I have faced bugs working on different projects. Therefore, I would like to share my experience in debugging bugs. Bugs are introduced in codebases because of a need to understand the requirements(logic) or how the tools you use function. One common ground I found post-analysis of my debugging journey is that I fixed the logic by filling gaps in knowledge.
Over the years, we have built a debugging workflow at D10X.
- Ask a teammate if fixing a bug takes more than two hours.
- If the teammate cannot fix it in 30 minutes, ask a senior developer
- If a senior cannot make sense of it. Gather a team and discuss the probable causes
- If everything fails, ask our technical manager (Nitin Bhide) to help us resolve it.
In the initial two hours, a developer has learned how to reproduce the bug in the developer environment, read the error stack trace, googled at least the error’s meaning, and read the documentation or source code about the tools involved in the bug. Also, sometimes, it requires one to go through the issue board of the frameworks used by their project.
When these fail, then the senior members are introduced into the picture. Regardless of their main project, a senior developer helps resolve errors from a different project. This often involves debugging a code you have little idea about and may be written in a programming language you are unfamiliar with. These limitations have always helped us find a solution to the issue. Why do you ask? Because we debug logic and behavior, not the source code or the programming language it is written in. Logic and behavior are decided and can be implemented using any programming language. Thus, our approach is first debugging logic rather than the language’s peculiarities.
The D10X engineers treat errors as flawed logic rather than the erroneous implementation of programming languages. This has enabled us to work in multiple programming languages across different projects. As a result, we can comfortably switch language stacks and frameworks. In addition, we have learned to read the source code of the frameworks and interpret the manuals to write better-than-average quality code amongst our peers.
This thinking has helped people grow as programmers exponentially in a given time frame. A D10X team member grows as a programmer overall, making them adaptable and open to various interpretations.