Logging is incredibly useful in tracking down the cause of the bug. It can contain an exception, and the path leading to it. If the log contains an exception, be sure to start with the first exception in the log, since the first exception might have triggered other exceptions. Keep in mind that the first exception may have occurred a while ago, or even at application startup. Therefore try to get hold of as much of the log file as possible, not just an exception snippet. Once you found the first exception, look for the last caused by.

These days debuggers are quite powerful. It is worth your time to learn how to use them. Getting handy with them and using features like conditional breakpoints or break on exception will prove invaluable.

Instead of starting to debug at the application entrance point and hope you encounter the the problem, it is often more effective to start where the bug occurred and work your way up. You will be able to see the exact state and the path that got you there using the debugger.

Sherlock Holmes once said “When you have eliminated the impossible, whatever remains, however improbable, must be the truth.”. The same principle applies to debugging. When you start the bug hunt, the problem space can be quite big. In order to find the bug we need to reduce it. So we need to exclude possible causes. Is it a back-end problem or a front-end problem?, which components are involved? these kind of questions can help you pinpointing the location of the bug. Be aware that when you made the decision to exclude a component, you generally don’t look back. Keep looking at the facts, and reevaluate the decision when needed.

First review the code. Really try to learn what the code does, think about what input could cause errors in the code. Write a few unit tests to understand the code. Knowing what the code should do helps locating and finding the best solution for the bug.

In retrospect, most bugs you solved in your career were probably quite obvious and simple. This is true for most bugs. So be careful when you start thinking about magical causes when you are having a hard time finding the bug. Once there is consensus in a team about a possible cause that is not solvable by the team ("it’s probably faulty hardware"), the team will stop looking for a solution. Trust your own skill, if the thought up cause seems too magical, it probably is, keep on looking until you are sure.

This is probably the most important tip in this article. I noticed most bug hunting time is wasted trying to solve non-existing bugs. Once you formed a hypothesis about the possible cause of the bug, try to think of a way to prove it as well. It is okay to make a temporary hack just to check if you were right. Don’t start solving your hypothesis before you are sure that you are right.