Really?
I bet most of us here could go on for a while about the customization that we've made and just have to have.
So the precise example is a bit off, pretend it's a steak. Done.
I optimize my cooking for time. I'll make a chili. I have a crock pot that can be put directly on the burner. So I can throw in the onions and get them caramelized while I chop the peppers. After them I add the herbs, then meat, then take it off the burner and put it in the crockpot heater, and leave it for the next morning, at which point I have ten days of chili. And it taste real fucking good to me.
My desktop, keybindings, automation, etc, sure: mise-en-place. Because I am a software engineer not a chef.
That's really the point I was failing to make: mise-en-place has its time and its place.
If all you see the article as is info on cooking, I'm of the opinion that you're missing the point.
The last line of the article points this out - mise-en-place is about optimizing for consistency/efficiency in $THING_YOU_CARE_ABOUT
Because software is just about following repeatable recipes to produce identical results, day after day after day?
I agree that having one tools organized is a good idea. I disagree with the rest of it. Specifically I don't think cooking is a useful analogy, because it is the antithesis of software development.
> "While you're a home chef, you are really particular about your shakshuka."
So the dish isn't ruined by most practical measures, but it's ruined according to the person making it. And maybe they don't want it to be more aromatic.
So regardless if it's a reasonable assumption or not, we can agree that sometimes we run into problems in even simple things that cause things to run over. And those overruns can cause catastrophic failures in other parts of a project.
And the way to prevent those simple problems from causing overruns, is to prepare that work beforehand.