I cook steak about once a week. Thick-cut scotch fillet, usually, from the butcher on the corner who knows my name and knows I like them cut at least three centimetres thick. Salt, pepper, screaming-hot cast iron, four minutes a side, then off the pan and onto a warm plate with a loose tent of foil.
Then the hard part. Nothing. Five minutes of doing absolutely nothing while the steak rests.
The first fifty or so times I cooked steak, I skipped this step. Impatient. Hungry. Convinced that the steak was done and the time between pan and plate was wasted time. I’d cut into it immediately and watch the juices flood onto the board, a pool of flavour and moisture escaping the meat because I couldn’t wait five minutes.
It took an embarrassingly long time to learn that the five minutes of nothing is the most important part of cooking the steak.
What resting actually does
When a steak cooks, the heat drives moisture from the outer layers toward the centre. The muscle fibres on the outside contract and squeeze liquid inward. By the time you take it off the pan, the steak is thermally unbalanced, the outer layers are dry and tight, the centre is a pressurised pool of juice, and the whole thing is too hot and too stressed to eat well.
Resting lets the temperature equalise. The carry-over heat continues cooking the inside gently while the outside cools slightly. The muscle fibres relax. The juices, which were concentrated in the centre under pressure, redistribute throughout the meat. When you finally cut into a properly rested steak, the juices stay in the meat, in your mouth, not on the board.
The resting doesn’t look like anything is happening. The steak sits there. You can’t see the juices moving. You can’t see the fibres relaxing. From the outside, it looks like a steak sitting on a plate doing nothing. Everything important is happening inside, invisibly, and it requires you to leave it alone.
The carry-over cook
There’s another thing happening during the rest that matters: carry-over cooking. The steak is still cooking after you take it off the heat. Residual heat in the outer layers continues to move inward, raising the internal temperature by three to five degrees. A steak pulled off the pan at 52 degrees will rest to 55 or 56. If you cook it to your target temperature on the pan, it will be overcooked by the time you eat it.
Good cooks learn to pull the steak off early and trust the carry-over. The steak isn’t done when you stop cooking it. It’s done five minutes later. The skill is in the anticipation, knowing when to stop, not because the thing is finished, but because the thing will finish itself if you give it space.
This is the part that took me the longest to learn, in the kitchen and everywhere else.
Doing nothing is a skill
I am not good at doing nothing. Most people I work with aren’t either. We’re wired for action, doing, fixing, improving, iterating. Idle hands feel wrong. If the steak is on the plate and I’m standing in the kitchen, I want to be doing something. Checking it. Prodding it. Adjusting the foil. Making a sauce I don’t need. Anything except standing there trusting the process.
This is exactly the instinct that makes people over-engineer software.
A feature ships. It works. The tests pass. The users can do the thing they need to do. And instead of letting it rest, letting the team absorb the change, letting the documentation settle, letting the users find their own relationship with the new capability, someone opens a follow-up ticket. “We could refactor the handler to be more generic.” “The error messages could be more descriptive.” “What if we added a bulk-upload option?”
These aren’t bad ideas. They’re carry-over ideas, the residual heat of having been deep in a problem, still thinking about it, seeing the things you could improve now that the hard part is done. But acting on them immediately is the equivalent of cutting into the steak before it’s rested. You lose something in the rush. The team hasn’t finished absorbing the last change. The users haven’t finished discovering the edges of what you just built. The codebase hasn’t finished settling, the reviews are still landing, the deployment is still being monitored, the thing is still warm.
Rest the feature. Let the carry-over happen. The code you wrote will continue to do work after you stop touching it, people will read it, build on it, integrate it into their mental model of the system. That process takes time, and it goes better when you’re not simultaneously changing the thing they’re trying to understand.
Gold plating and the urge to improve
There’s a name for the failure to rest: gold plating. Adding polish, features, and improvements beyond what was needed or asked for, because the work doesn’t feel done until it feels perfect.
Gold plating is seductive because it feels like care. It feels like craftsmanship. You’re not being lazy, you’re going the extra mile. The error messages should be perfect. The API should handle edge cases that probably won’t happen. The loading spinner should be exactly the correct shade of the brand colour. Each individual improvement is small and defensible. In aggregate, they’re a week of work that nobody needed, on a feature that was already good enough.
“Good enough” is not a phrase that comes naturally to people who care about their craft. It sounds like settling. It sounds like mediocrity. But in software, “good enough” is almost always the correct target for a first release, because you don’t know what “great” looks like until real users have used the “good enough” version and told you what’s actually missing.
I’ve shipped features I was embarrassed by, rough edges, placeholder text, error messages that said “something went wrong” without saying what. I’ve also shipped features I spent an extra week polishing. The rough features taught me more, because users told me what they actually needed, which was never what I would have guessed. The polished features taught me nothing, because the polish addressed my anxieties, not the users’ needs.
The steak doesn’t need garnish. It needs salt, heat, and rest. Everything else is for the cook’s ego, not the dinner guest’s plate.
The carry-over cook of a codebase
The carry-over cooking metaphor goes deeper than individual features.
When you merge a pull request, the work doesn’t stop. The code enters the codebase and begins a slow process of integration that happens mostly without your involvement. Other developers read it. They form opinions about the patterns you used. They adopt those patterns, or they don’t, in their own work. The code becomes a precedent, whether you intended it to or not.
This carry-over is invisible but powerful. A well-structured service module, merged and left alone, will quietly influence how the next three services get built. The team absorbs the pattern, adapts it, improves on it. The original code was the heat; the carry-over is the learning. You don’t need to stand over the team explaining the pattern. If the code is clear, the pattern teaches itself.
The reverse is also true. A poorly-structured module, merged and left alone, will quietly establish a bad pattern as normal. The carry-over works in both directions. This is why the quality of the code you merge matters, not because bad code is a moral failing, but because code teaches by example, and the teaching continues long after you’ve moved on to the next ticket.
The implication is that the moment of merging is not the moment of greatest impact. The moment of greatest impact is three weeks later, when someone reads your code while building something new and decides to follow the same pattern. You’re not in the room. The code is doing the work. The carry-over is cooking.
When to go back to the pan
Resting doesn’t mean ignoring. A rested steak is ready to serve. It doesn’t sit on the plate forever.
There comes a point, after the team has absorbed the change, after the users have had time to use it, after the carry-over cook is done, when you do go back. You check whether the feature works as expected in the real world. You read the support tickets. You look at the usage data. You ask the users. And then, with the benefit of rest and real-world feedback, you decide what to improve.
This is different from gold plating. Gold plating is improving based on your imagination of what users will need. Going back after the rest is improving based on evidence of what users actually need. The first is ego. The second is craft.
The discipline is in the gap. Between shipping and improving, there needs to be a rest, a period of deliberate not-touching where you let the work do its work. The length of the rest depends on the change. A small bug fix needs a day. A major new feature needs a sprint. A large architectural change might need a month before you know whether it’s working.
The carry-over will tell you what to do next, if you’re patient enough to listen.
The plate
My steak routine has a coda that took years to develop. After five minutes, I take off the foil. I slice against the grain, another thing that took too many steaks to learn, the difference between a tender slice and a chewy one. I put it on a warm plate. I pour any resting juices over the top.
The plate is simple. Steak, whatever greens are in season, maybe some roasted potatoes if I planned ahead. Nothing fancy. The quality is in the protein and the rest, not in the arrangement. The meal is ready because I waited, not because I added more.
I think about this every time I’m tempted to add one more thing to a feature before shipping. The feature is on the plate. It’s ready. The juices are in the meat, not on the board, because I stopped at the right time. Ship it. Rest it. Serve it.
The hardest part of cooking a steak is doing nothing. The hardest part of shipping software is the same. Both skills take years to learn and a lifetime to practise. Both reward patience more than intensity. Both produce better results when you trust the process and leave the thing alone.
The carry-over will finish the job. It always does. You just have to let it.