I noticed the pattern the first time a curry went wrong in a way I couldn’t explain, and caught myself doing the exact thing I do when a service misbehaves in production: stop touching things, and go find out what actually happened before trying anything else. That’s not a metaphor I’m reaching for to make a cooking post fit an engineering blog — it’s the actual sequence of thoughts, in the actual order, and it’s worth writing down because the process generalizes further than I expected.
The process, as I actually use it
Read the whole thing before touching anything. Skimming a recipe for the ingredient list and starting to cook is the kitchen equivalent of reading the first ten lines of a diff and running it. You’ll find out what step 7 needed from step 2 exactly when it’s too late to have done step 2 differently — the dough that needed to rest an hour, the pan that needed to be cold when the batter went in. Reading fully first isn’t slower in any way that matters; skipping it is slower on the runs where it costs you the whole dish.
Form a hypothesis about what each step is doing, not just what it says to do. “Rest the dough for 30 minutes” and “let the gluten relax so it doesn’t shrink back when you roll it” are different instructions to follow, even though a recipe usually only gives you the first one. Once you know the second one, you know what’s actually being verified — dough that springs back is dough that needed more time, not dough where you did something wrong you can’t identify.
Change one variable at a time. The instinct when something’s not working is to adjust everything — more heat, more time, more salt, all at once. That’s exactly how you end up not knowing which change fixed it, or worse, which two changes cancelled each other out. This is the same discipline as bisecting a bug: isolate one variable, observe, then move to the next.
When it breaks, isolate which step broke it — don’t restart from scratch. A sauce that split didn’t fail as a sauce, it failed at one specific moment, usually a temperature or an addition rate. Finding that moment is the same move as finding which commit introduced a regression: work backward from the observed failure to the specific point where behavior diverged from what you expected, instead of throwing out the whole attempt and hoping the next one goes better by luck.
Write down what you’d do differently. Not a full recipe rewrite — one line. “Needed five more minutes at lower heat” is enough to make the second attempt an iteration instead of a repeat of the first one’s mistake. The engineering version of this is a one-line note in a postmortem or a commit message; the value is identical, and it’s the step I skip most often in the kitchen specifically because there’s no code review forcing me to write it down.
Two dishes that taught me this the hard way
A laminated dough I rushed through, once, because I’d skimmed past “rest between folds, minimum 30 minutes, longer if your kitchen runs warm” and treated it as a suggestion. The butter melted into the dough instead of staying in distinct layers, and what came out of the oven was dense and greasy instead of flaky — not a disaster, just clearly not the thing the recipe was describing. Reading it fully first would have told me the resting step wasn’t padding, it was the mechanism the entire texture depended on.
A curry where I added everything at once instead of building it in the order given, on the theory that it would all cook together anyway. It technically did. It also came out with raw-tasting spices and a sauce that never came together into one texture, because the order wasn’t arbitrary — it was building flavor in a sequence I’d erased by collapsing it. Same failure as changing five variables in one deploy: something’s wrong, and now there are five candidate causes instead of one.
Why this isn’t really a metaphor
I don’t think cooking taught me to debug, or debugging taught me to cook. I think there’s one underlying process for working through anything you don’t yet fully understand — read the whole thing before acting on any part of it, understand why each step exists rather than just what it says, change one thing at a time so you can attribute the result correctly, and when it breaks, find the specific point of divergence instead of starting over. Code and cooking are just two of the places I happen to run that process regularly enough to notice it’s the same one both times.