I believe debugging is a little bit like a craft. What I mean is that like any crafts, it requires both some basic knowledge and practice to get good at it. Practice is key. And because it’s a complex process, it’s difficult to give a basic set of rules to help you have a better start. But let’s try with generic helpful ones!
A few tips (not rules, rather like guides) could indeed help in practicing your next debugging sessions in the right direction. I’ll list only 2, which are the main 2 ones I believe are the most important in my experience.
Let’s explain this a little bit. Debugging a system is not so much in finding what’s going wrong, but why and how it went wrong. In order to do that you ask your system questions, get answers, check if they match your expectations, and proceed. Step by step, you hopefully narrow down the set of hypothesis until there’s only one explanation left explaining the unexpected behaviour.
Getting answers back from the systems is easy: breakpoints (or logs) when it’s a small piece of code, but also metrics, stack traces, ... depending on if it’s a single piece of software or something distributed. But usually, it’s the easiest part.
The tricky part - the one where I keep seeing lots of good engineers waste a lot of time - is being able to ask the right questions to the system. Asking the right questions makes it much faster to narrow down the problem. And that’s where those 2 tips come in. You need to refrain yourself to add logs, put tons of breakpoints. But first, think of where you should put them to get a meaningful piece of information which will confirm or not one hypothesis. (That’s the stop and think part, leaving your hands off the keyboard) And in order to formulate a relevant hypothesis, you need to have a good mental model of the system. This might seems obvious, but we see so many times people wasting their time troubleshooting the wrong part of the code, because they didn’t correctly understood what they saw in the logs (or elsewhere), because their mental model was incomplete.
To recap:
Hope this helps