Mise en place is systems thinking

People hear "chef who codes" and assume the kitchen part is colour — an origin story to make the technical part more interesting. It isn't. The kitchen is where I learned the actual engineering.

Mise en place is dependency resolution

Before service, you set your station. Every component you'll need, prepped, portioned, within reach, in the order you'll reach for it.

What you're really doing is resolving a dependency graph under a deadline. You work backwards from the dishes on the menu, decompose them into components, identify what's shared between them, and batch the shared work. You cache aggressively — the sauce that takes four hours is made once, in the morning, for the whole night.

And critically: you do this before the load arrives, because the one thing you cannot do at eight o'clock is think.

The systems version is identical. Anything you can precompute, precompute. Anything you can hoist out of the hot path, hoist. The measure of a good station is how little decision-making it requires when it's full.

Recipe scaling is linear algebra

Scale a recipe from 4 covers to 250 and you find out fast that it isn't multiplication. Salt scales linearly. Heat doesn't. Reduction time doesn't. Bread doesn't rise proportionally to how much dough you made.

You learn, viscerally, that a system's behaviour at 10x is not its behaviour at 1x with bigger numbers. Some things scale linearly, some scale by surface area, some hit a hard ceiling and change character entirely. A stockpot at four times the volume takes far longer than four times as long to come to temperature, because you scaled the mass and not the burner.

Every engineer eventually learns this about databases. I learned it about béchamel first.

Inventory is resource allocation

Ordering is forecasting under uncertainty with a spoilage penalty. Order too little and you're 86'ing dishes on a Friday. Order too much and you're throwing money in the bin on Monday.

There's no clean answer, only a posture: hold buffer proportional to volatility, not proportional to volume. The item that sells steadily needs less headroom than the item that sells erratically, even if the erratic one sells less overall.

That's queue sizing. That's connection pooling. That's how much slack you leave in a rate limiter.

The part that actually transfers

None of the above is why I think the kitchen made me a better builder, though.

It's this: a kitchen is a system that cannot go down, run by people who are tired, under a load you don't control. You can't pause service to refactor. You can't tell the dining room to come back Tuesday. Whatever you built has to work with the staff you actually have, at eleven o'clock, on the fourth double in a row.

That constraint produces a specific kind of design taste. You stop being impressed by systems that are clever and start being impressed by systems that degrade well. You learn that the most important property of a process is whether someone can pick it up mid-stream after someone else drops it.

I build agent systems the same way now. Not as pipelines, where every stage assumes the last one succeeded, but as stations — with hierarchy, with explicit handoffs, with the ability to improvise when the plan breaks. Because the plan breaks.

That's not a metaphor I reached for afterwards. It's just where the design came from.