This isn't advice on how to use a debugger - it's more of a holistic approach to debugging. I've been struggling with trying to debug really obscure issues but after watching some of my teammates figure out very edge case issues I know it's possible. Since then I've been trying to narrow down some things that help with figuring out problems.
- Reliably repro-ing is super helpful. Sometimes it's very difficult to (due to race conditions or the customer getting into situations I have no idea how they got there)
- Assumptions are bad (going into debugging convinced it's caused by some certain issue and dismissing other possibilities). Making this mistake means you waste valuable time going down the wrong rabbit hole. And very often, the root of the problem is extremely unexpected and something you never would've predicted.
- It pays to put in some investment up front to make things easier later on. Even if it takes an hour to set up automation or a template, it'll actually save a lot of time later down the road. Even writing an Autohotkey script to automate writing some text.
- Run repro cases with varying parameters to eliminate as many possibilities as possible (and make sure they can truly be eliminated). Keep track of these - I use excel for this. (This is why reliably repro-ing is very useful)
- Make a mind map to keep track of investigations. There are so many different pieces of information to keep in mind while trying to debug a problem and keeping the information you find out in a graph/map form helps you understand your investigations at a glance and keeps track of the relationships between your new pieces of knowledge, or helps you see them in the first place.
- Be aware of recent changes or current known issues in the product. Being aware of dates the bug started. In querying our logs I've started to include the build version as a vital piece of info which really helps if I notice a bug just started happening recently. In the ideal case you can narrow down the bug to the individual commit
- Gathering as much data as possible - logs, stack traces, telemetry, anywhere you can glean information from. Print statements outputting the values of all of your variables, and what you're going to do/what you just completed. The more concrete info, the better.
- Organize logs or categorize them to make easier to understand. I've taken to exporting our logs to excel and coloring rows by certain types of data or types of actions so I can easily determine what's happening
- Don't be in denial - if the program is consistently not working then it's a waste of time to convince yourself it's a transient error or an external software bug. Every extremely unlikely bug I've encountered that seemed impossible at the time ended up all having a good logical reason that I overlooked and I would've saved a lot of time in the past if I just accepted the fact my program has a bug and I have to look for the reason.
And of course, proficient use of the debugger and a comfortable knowledge of the code base helps as well.
