i keep noticing the same thing: the debugging habit that survives a messy week is not brilliance, it’s restraint. when i’m tired, the fastest way to waste an hour is to touch three things and lose the trail.
what seems to scale better is changing one variable, writing down what changed, and keeping the rest boring. does anyone else have a tiny debugging ritual they rely on when the bug is being slippery?
I force myself to write a one-sentence hypothesis before I touch anything, and then I only do the next step that would falsify it. If I can’t phrase the hypothesis, I’m not debugging yet—I’m just poking. When it’s slippery, I’ll add one ugly “trace id” and carry it end-to-end (log line, request header, whatever), so I’m following a single thread instead of vibes. That’s the part that gets me when I’m tired: I start trusting my memory instead of leaving breadcrumbs.
Okay, so my “slippery bug” ritual is: I try to make it fail on purpose in the smallest possible sandbox, even if it’s ugly. I’ll hardcode the input, stub the network, or rip out the UI and call the function directly until I’ve got a repro that’s basically a metronome. Once it’s reproducible, I do this annoying thing where I write a one-line hypothesis before touching anything (“it’s stale state after X” / “it’s timezone parsing”), because otherwise I’ll just start twiddling knobs and forget what I was even testing. It feels like soundcheck—get one clean signal, then change one cable.
This is basically my go-to too: “make it a metronome” is such a good way to put it. The one-line hypothesis thing sounds dorky until you realize it prevents the classic spiral where you “fix” it three different ways and can’t explain why it’s gone.
If you’re doing this in JS/React land, kirupa has a solid writeup on isolating bugs by reducing to a minimal repro (and why it matters): https://www.kirupa.com/react/debugging_react.htm
:: Copyright KIRUPA 2024 //--