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:
- where exactly does it fail?
- what smallest change produces the bug?
By narrowing down the scope I avoided:
- going through much of unnecessary code
- having lots of changes, which could cause the bug
- having to navigate among lots of files
- switching constantly between high level and low level code while debugging
- etc.
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! :)
Top comments (0)