Patience - A key weapon when busting bugs in someone else's code

At some point of time in your career as a software engineer/programmer/developer, you would have come across a situation where you were required to fix bugs or add a feature to an existing code base. Over the past few of months, I have been regularly in such situations as I help develop the newer and slick version of babajob.

A thing which I have noticed over the past few months is my general frustration at how things were implemented previously by different people at different points of time. The real frustration happens when I have to try and resolve bugs which occur because of trying to integrate certain portions of the old pieces with the new one. For this I have to understand  -

1. What feature was the previous developer trying to implement?
2. How was he/she trying to implement it?

If you are able to figure out the second question, figuring out the first one becomes easier as well. But trying to understand how the features were implemented has been a frustrating experience. And once I did understand how it was implemented, it lead to more frustration because I have never come across such implementations before and I always wondered why couldn't this be simply done the way most ASP.NET developers would do it? After all, what is the point of using ASP.NET if your new/edit forms are in .htm pages with javascript which is not jquery or even the retired Microsoft Ajax library. And worst of all, the javascript is not there for ajax calls, but to actually submit the form to a different aspx page!

Of course, over the course of time I have come to realize that the intention in many cases was merely to avoid duplication of code between the web and mobile interfaces. But this could have been achieved in a better manner, a direction in which we are headed slowly but surely.

Coming back to the title of the post, it is very easy to get frustrated by what you perceive as short-comings in the previous implementation. But getting frustrated is unproductive. It makes you lose your focus and concentration from finishing the task at hand and instead shifts your focus to the deficiencies of the previous implementation. As a result, you end up spending more time debugging because you have lost the focus and are unable to spot bugs which you would have had if you were in a calm and focused state of mind.

The best thing in such cases is to just get up and take a 2 min break, drink a glass of water, take a deep breath and try and bring your focus back to what you wanted to achieve.  Be patient and don't get flustered easily.

Posted via email from Random thoughts about tech and entrepreneurship