DEBUGGING at D10X

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, it takes a herculean effort to correct it. 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 lack of understanding of the requirements(logic) or how 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 workflow of debugging at D10X. 

1. Ask a teammate if it takes more than two hours to fix a bug.

2. If the teammate cannot fix it in 30 minutes, ask a senior developer

3. If a senior cannot make sense of it. Gather a team and discuss the probable causes
   

4. 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. A senior developer, regardless of their main project, helps resolve errors from a different project. This often involves debugging a code you have little idea about, as well as it may be written in a programming language you are unfamiliar with. These limitations have rarely hindered us from giving 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 languages 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 way of 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.