How to Save Time While Debugging
To save time and energy, developers should use readily available resources, such as Google and their coworkers, to solve problems rather than reinventing the wheel.
Join the DZone community and get the full member experience.Join For Free
In this article from our small series for junior developers, we will focus on how to save time while debugging and what the best practices of senior developers are when fixing the errors.
The Stripe’s study from 2018 says that developers spend over 41% of their time on maintaining and debugging the code. Imagine, out of 20 working days in a month, a week and a half of time does not add value to the business. Let us give you some advice on how to lower this large chunk of time that could be spent on creating new features.
With a systematic debugging approach you can quickly find the part of the code that is not working, but the ultimate goal is to fix the error as fast as possible. The most straightforward way is to google; chances are that someone has already encountered the same problem. Googling first is not only faster than trying to repair something in your code, but it usually also provides a more detailed explanation. In fact, senior developers are googling all the time, so it’s definitely not something to be ashamed of. A lot of results will take you to public forums like Stack Overflow or GitHub Issues. Most of the time, you will find solutions to similar problems like yours, which should nudge you enough to be able to solve your own problem. However, if you still can’t find an answer don’t be scared to ask on a forum. The developer community is a very active one and many are willing to give you a hand when you are stuck. They have probably been in a similar situation in the past as well.
If you feel kind of tired from searching the whole internet, don’t hesitate to use the rubber duck technique. This is a proven method that forces you to look at the problem from a different perspective and that’s where the ducks come in. Just imagine your duck-mate as someone who has no clue about the problem and try to explain the issue to it one sentence at a time. Weirdly, saying it out loud also helps. You can also take this technique to the next level by buying a lot of ducks for your team, as shown in the picture below, and every time you need to ask, you can choose the best buddy based on your current problem.
There are also situations where you tried everything, you tried to google the problem, you asked many ducks and the solution still hasn’t come to your mind. Now would be the best time to ask your experienced colleagues. It is good practice to try to find the solution on your own rather than going straight to your colleagues. Not only do you show initiative, but you also can help narrow down the possibilities. For this, we recommend applying a 30-minute rule. In these 30 minutes, try to find the solution and if you cannot come up with one, then go and ask your team. They may know the answer right away because they have probably already solved the exact same problem. If not, then they can definitely point you in the right direction to figure the problem out. After all, two heads are better than one.
The above-mentioned techniques save time when you encounter an error; however, to truly decrease the time spent on debugging, you should preventively improve code quality on a regular basis. Here, we recommend taking advantage of tools that automatically analyze your code and alert you on major issues.
What we are trying to say with this article is, “Don’t reinvent the wheel!” Debugging is a natural part of development, and every developer can empathize with your frustration. However, with experience also comes speed and confidence in resolving issues and that is what differentiates seniors from juniors. So don’t lose your hopes, stick to the systematic debugging approach, hone your Googling skills, talk to a rubber duck, and do not be afraid to ask the community or your seniors. Debug smarter not harder — it can save you a lot of time.
Published at DZone with permission of Jiri Tichy. See the original article here.
Opinions expressed by DZone contributors are their own.