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:

Try to create a reliable replication of the debug
Create a minimal demonstration of the bug
Read error messages carefully
Use a debugger

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.

“Debugging for Mid Coders” by Raemon

LessWrong (30+ Karma)