Me against a bug, reminding myself how to solve any defect

Dear developer,

Don’t give up, keep up with your efforts to find other ways to understand the bug’s root cause. I know it can be frustrating. The agonies with the process can be ruff. But, you’ve got it, you solved many in the past, and you will solve this one too. It is part of your job.

Investigate the crime scene 🕵️

Embrace all your experience, the collective knowledge you gained with your past ventures. Rely onprevious bug records that you assume related to the defect’s scenario, you might find some hidden gems that will help you think of a way to cope with it.Check any logs the application writes, search for any abnormal behavior (such as errors, exceptions, etc..). Collect that interrelated items into your brain (or better write them down).

Use version control , read the history of the files you suspect the issue resides within. Rollback through versions’ history, up to a point it is no longer reproduced. Thus, helping you to understand the specific version in which the issue was first observed.

Identify main suspects (controllers, buttons, interactions, etc.) that participate in the scenario, have a strong understanding of the steps that produce the bug, try to identify its frequency, whether an always reproduced anomaly and in which conditions.Get familiar with what is the expected behavior.

Wisely spread breakpoint using a good debugger (invaluable) and do line breaks steps.Navigate through stack trace on the application’s main flow (for example input and output around the code’s area), use dedicated IDEextensions that assist you while debugging (such asOzCode).

No clue what the problem is?Ask someone ; it might be a coworker, a friend, or an online community. Show them the information pieces you’ve collected. Generally Explain what the program does, what it should be doing in this particular instance, and what it’s actually doing.

Share code snippets of what you’ve narrowed down using the IDE while asking for guidance: “I identified the issue is created by the following code, it’s setting the value to X when it should be Y, but I can’t see why that’s happening”. There is nothing likea fresh pair of eyes to solve the riddle.

Furthermore,books (for#1 or#2) on advanced debugging skills can be your friend too. Reading will help you think of creative solutions. I bet you’ll find some tricks out of your sleeve afterward.

Repeat the above until you’ve got that *eureka * moment.

Now that you’ve identified the root cause, what else? 🙄

Try creative ways to solve it. If you find yourself struggling, go to the framework API documentation (such asMicrosoft docs) or read trough your projectdesign documents , both might reveal the hidden parts.

Search for similar solutions using your favorite search engine (e.g.,DuckDuckGo), filter relevant results — you might find blogs, books, and tons of information on related subjects. It is not a shame to read answers inStackOverflow, so use it wisely.

Apply various techniques, such as registering to main flow events, adding helpful log printouts, reading the framework’s source code (in caseavailable). Consider ifrefactoring is needed to reduce coupling, don’t just fix a bug, fix the entire class, so you’ll never be able to create similar bugs again.

One last thing, it’s a kind of an overkill, but if all odds are against you, use a reflector (it depends on the language), which enables debugging without source code (unless not allowed — obfuscation) to pinpoint the issue. I highly recommend usingdnSpy , which I previouslyblogged about.

Managed to fix it? 🧩

The battle hasn’t finished — add unit tests to prevent a “make a fix, cause a problem elsewhere” situation. Update thedesign document if needed, run automatic or manualsanity tests to verify the fix. Add codecomments to explain the context (the “why”) of the fix (more onthat).

Question your methods, you may be able tolearn and get better , so ask yourself:

• How could I have avoided this waste of time?
• What did I overlook in the first place, and why?
• What unvalidated and/or wrong assumptions did I rely on?

It will improve your abilities. Furthermore, sharpening yourgut instinct. Eventually, over time you learn to automatically notice all those minor signals that are too easily overlooked, leading you quickly to the right answer. In the end, it’s all aboutdeliberate practice.

Share what you’ve learned during the whole process, prepare some slides, and have a post-mortem session with your colleagues, so others will benefit from your experience too.

Lastly, don’t forgetAlan J. Perlis words:

There are two ways to write error-free programs; only the third one works.

Sincerely (until next time),

Your future-self