I struggled with learning to debug code for a long time. Exercises for learning debugging tended focus on small, toy examples that didn't grapple with the complexity of real codebases. I would read advice on the internet like:
I'd often be starting from a situation where the bug only happens sometimes and I have no idea when, the error log is about some unrelated library I was using and had nothing to do with what the bug would turn out to be. Getting to a point where it was even clear what exactly the symptoms were was a giant opaque question-mark for me.
I didn't improve much at debugging until I got generally serious about rationality training. Debugging is a nice in-between difficulty between "toy [...]
---
Outline:
(02:40) Be willing to patiently walk up the stack trace (but, watch out for red-herrings and gotchas)
(03:09) Gotcha #1: X does not exist, cant read X, X is undefined, etc, are often downstream symptoms, rather than the bug itself.
(03:55) Gotcha #2: Notice abstraction boundaries, and irrelevant abstractions.
(06:54) Binary Search
(09:36) Notice confusion, and check assumptions.
(09:41) Also, look at your data, not just your code
(11:39) Things I dont know
The original text contained 1 footnote which was omitted from this narration.
---
First published:
August 16th, 2025
Source:
https://www.lesswrong.com/posts/zvisSDFPLWofyFxEQ/debugging-for-mid-coders
---
Narrated by TYPE III AUDIO.