Before I kept a log, my stock was flat. I’d made it a dozen times, tweaked it a little each round, and it never got much better: more roasted vegetables one week, a splash more vinegar the next, none of it adding up to anything. The problem wasn’t the stock. It was that I couldn’t remember what I’d already tried, so every batch was really just the first batch again, wearing a different hat.
The Food Log is where I fixed that. It’s an engineering log for the kitchen, the same thing I used to keep on paper for real engineering work: a running record of tests, research, half-formed ideas, and the TODOs that don’t belong anywhere else yet. Before it existed as a section of this site, it was a stack of notebooks. The format changed; the job didn’t.
That cooking gets an engineering log isn’t an accident. Cookery has always looked a lot like software design to me: tactical skills worth honing for their own sake, planning and execution that take years to master, and a whole way of thinking about how food works that feels like ontology and architecture. Problems that look like engineering deserve an engineering tool.
Stateless is the whole point
A good engineering log is stateless in a specific sense: you should be able to walk away from a problem entirely, forget everything you were holding in your head, and come back weeks later and pick up exactly where you left off. Not from memory, from the log. What did I try? What worked, what didn’t, what was I about to try next?
Cooking has the same problem engineering does: you don’t work on any one thing continuously. A stock gets tested once a month, if that. A sauce might sit untouched for a season while you’re busy with something else. Without a log, every return trip starts from zero, because “I feel like the fennel was too much last time” is not information, it’s a vague impression that erodes a little more each time you reach for it.
The log is where I put whatever I’m circling before it becomes a recipe: a dish I want to research, a technique I don’t understand yet and need to read up on, a version of something that’s close but not right. When I’m starting a new recipe I don’t just start cooking; I do the research first, the way How to find great recipes describes, and that research and its notes land in that month’s log entry, not in my head.
Iterating needs a fixed point
Here’s the part that isn’t obvious until you’ve done it the slow way: iteration only works if you’re iterating from something known. Not a memory of a dish, not a rough sense of “more like this, less like that”, but an actual version, written down, with real quantities, that you can point to and say: this one, exactly this one, is what I’m changing next.
That’s what the stock was missing. I was iterating from a feeling instead of a recipe, so nothing accumulated. Once I started writing down the actual version I’d made, what was in it, what I thought was wrong with it, the next attempt had something to push against. The rigour of writing it down forced me to be specific about what I thought was missing, instead of leaving it as a vague dissatisfaction I’d carry to the next attempt and probably forget half of anyway.
Sampling, testing, adjusting
The way I actually develop a recipe: sample three or four existing versions, side by side, the way How to find great recipes talks about running a batch through the diary. Then draft something in the log, mixing what I like from each. Then test it. Then adjust, in the log, against that draft, not from scratch.
Pizza sauce and dough are the clearest example I’ve got. Pizzeria pizza sauce says outright that it’s still evolving, and it’s right: what’s on this site now is a few log entries and a few kitchen tests past where Pizza dough started, itself built from memory of doughs I’d had in restaurants and then tested against that memory until the ratios held up. Neither of those got good in one attempt. They got good because each attempt was written down clearly enough that the next one could actually build on it instead of re-litigating it.
Log notes and recipe notes aren’t the same thing
I keep both, and they do different jobs. The log is scratch space: bendy, informal, allowed to be wrong, allowed to trail off into a half-finished thought I pick up again next month. A ## Notes section on a published recipe is not that. Those notes are the things worth keeping, the ones that survived contact with an actual reader following the recipe, not just me thinking out loud while I cooked.
If I only kept notes in the recipe itself, I’d lose the scratch work: the dead ends, the version that was almost right, the ingredient I ruled out for a reason I’d otherwise forget by the next attempt. If I only kept the log, the finished recipes would never get the clean, tested version a reader actually needs; they’d stay drafts forever. Both matter. The log is where a recipe gets made. The recipe is where it gets kept.
The takeaway
If a dish of yours has stalled, plateaued at “fine” for a few attempts running, the fix probably isn’t a better palate or a cleverer tweak. It’s a record. Write down what you actually made, not what you meant to make, and what you think is wrong with it, before you try again. The next attempt needs a fixed point to push off from, or it’s not iteration, it’s just repetition with extra steps.