On Debugging

You want to peel back layers of weirdness.

Want to get notified about new posts? Join the mailing list and follow on X/Twitter.

I don’t know that there’s a way to distill debugging down to general principles.

The more you poke around and investigate, the better you understand the system, and the easier it is to diagnose bugs in the future.

And the most efficient way to poke around might be printing stuff out, it might be setting a breakpoint and checking the values of intermediate variables, it might be setting lots of breakpoints and stepping through the code one line at a time… it all depends.

The only general principle I can put my finger on is that you want to peel back layers of weirdness.

Like, go from “X is weird” to “X is weird because Y is weird and Y causes X.” And then “Y is weird because Z is weird and Z causes Y.”

You keep peeling back layers of weirdness and eventually you get to the root cause.

As you grind through this process of poking around, peeling back weirdness, and diagnosing bugs, hundreds or thousands of times, you just get a feeling for it.

Personally, even I feel a lot faster debugging now than a year ago.

So even after thousands of debugging repetitions, there’s still room for improvement for me as well.

It’s kind of like climbing a skill tree that goes up infinitely high.

The more reps you put in with bugs that you have to think hard about but end up figuring out, the better you get.

Want to get notified about new posts? Join the mailing list and follow on X/Twitter.