aidas | Aug. 23, 2023
tl;dr: In the beginning of debugging, deliberately narrow down the scope as much as possible.
Got some slimy bug the other day. Spent a couple of hours trying to track it down, but it still was slipping through my radar.
Tried to go through the code step by step.
Run it step by step.
Was tracking the variables and how they change.
Nasty bug still had a place to hide in the lands of code.
Then an idea came to my mind:
maybe narrowing down the scope would remove unnecessary overhead?
I was going through the code anew, answering questions such as:
By narrowing down the scope I avoided:
The bug got no more caves to hide in.
In minutes I spotted a trivial typo I made.
All tests finally passed.
This evolved into the technique I call a deliberate bug localization.
Another example I’ve applied it to involves tracking down the failing environment: does the code work locally? in a container? on the server? etc.
Once the environment is identified, then I could check what’s the actual difference between the environments (maybe some libs are missing, different versions of dependencies, etc.)
Less heuristics + more strategy = getting things done.
Hope that helps!
In case anyone has experience with this or other thoughts, I’m happy to hear them! :)