A letter to the lonely developer
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 on previous 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 IDE extensions that assist you while debugging (such as OzCode).
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 like a 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 as Microsoft docs) or read trough your project design 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 in StackOverflow, 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 case available). Consider if refactoring 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 using dnSpy, which I previously blogged 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 the design document if needed, run automatic or manual sanity tests to verify the fix. Add code comments to explain the context (the “why”) of the fix (more on that).
Question your methods, you may be able to learn 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 your gut 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 about deliberate 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 forget Alan J. Perlis words:
There are two ways to write error-free programs; only the third one works.
Sincerely (until next time),
Your future-self
