Modeling chopping onions: The importance of mise en place
app.hex.tech
app.hex.tech
I keep the quote at the top of my emacs config file.
Mise-en-place is the religion of all good line cooks. Do not fuck with a line cook’s ‘meez’ — meaning his setup, his carefully arranged supplies of sea salt, rough-cracked pepper, softened butter, cooking oil, wine, backups, and so on. As a cook, your station, and its condition, its state of readiness, is an extension of your nervous system... The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.”
-- Anthony Bourdain, from Kitchen Confidential.
Software is so flexible, yet we can't make UIs the way we want and are constantly subjected to the whims of designers and the buffets of fads. No way anyone becomes a master of using software because software apparently doesn't want that.
As ridiculous as it first sounds, VR will likely provide the technology for the way forward.
It's basically the same thing as 5S methodology in manufacturing. Doesn't make as much sense in a garage workshop, but when what you're doing is the pride of your craft and your day-in-day-out, your setup and tooling should be dialed enough that you almost never have to think about it.
I've always thought of the goal of mise being a sort of process fluidity rather than raw efficiency. Especially with tasks that can't be done simultaneously it's not going to shave much if any time off. But it still leads to less things to keep track of, fewer context switches, smoother transitions, fewer mistakes, more opportunity to notice and account for variations, etc.
You also have to remember that you have the skills and accompany judgement of a once-professional cook. You can cut the celery before the onions burn, but can you cut it before the garlic burns? Could a home cook without a professional background?
It's not that one of those options is "mise en place" and then others aren't. The answers depend on the person doing the cooking, and making that call is part of the mise process for the dish. Having a plan, basically.
Now, for qualifiers, I live in a full house so things aren't always where I left them (so simply removing searches is useful) and I do cooks both small (just my meal) and large (for the whole group or pre-cooking meals for the work week).
;;; init.el --- welcome to church
;; Well then get your shit together. Get it all together, and put
;; it in a backpack, all your shit, so it's together. And if you
;; gotta take it somewhere, take it somewhere. You know? Take it to
;; the shit store and sell it. Or put it in a shit museum, I don't
;; care what you do, you just gotta get it together.
;; Get your shit together.
-- Morty, from Rick and Morty
The other critical part of cooking (which IMO applies to other jobs, roles etc) is cleaning as you go - one of the first things taught in cooking school.
I personally hate cleaning up after I finish eating so I try and clean and put everything away before I sit down.
Cleaning as you go also reduces variability and total time spent. Cleaning naturally consumes short spans of otherwise-useless idle time between tasks. It also enables pipelining of multiple jobs. I also prefer to clean up before eating, and that usually takes just enough time for the meal to cool down to the right temperature if I was cleaning as I go.
> "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.
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.
In terms of project planning, a single cook using strict mise en place is Waterfall. When I cook, I aim for a more agile approach. Always cut onions into their own bowl first (for pretty much everything I cook). If the prep-time for the next ingredient(s) is long enough that I'd burn the onions, they go into a second bowl. But when I'm part-way through getting that second bowl prepped, I'll get the onions going. If I'm working on a new recipe, I'm more inclined to prepare further ahead, or I'll have a failed dish... but next time I make it, I'll have more confidence to multiplex cooking and prepping.
Mis-en-place at home cooking only works if you have a very, very detailed recipe. Just like waterfall — if you’re gonna just full steam ahead on a project you gotta know what you’re working towards. Any missing detail (forgot the garlic! Forgot to think about an edge case!) can derail the recipe/project.
Agile is more like a stir fry, you chop up some onions and throw them in, then see what else you got, all one step a time, and evolve and taste as you go.
How so? Just move the skillet from the heat and let the onions sit there for as long as it takes to chop the bell peppers. If anything, they will be more aromatic.
This is not a realistic assumption.
The one-line paragraph "Most of the time you're good! But you end up ruining 23.15% of your shakshukas. Whoops." requires no less than 3.1 kB of data, still 1.2 kB when gzipped.
Also, selecting text is impossible, and I am not sure if that is intended or just the browser giving up.
I wrote some python code that's generating those charts. You're right that's overkill for what it ended up being.
I initially played around with giving the reader the ability to set their onion chopping time and see how it played out. It was getting a little complicated for the point I was trying to make I think.
EDIT: I've added that in now, which helps make it a little more fun I think.
Wanted to take a second to address your comment about performance, lqet. All your points are absolutely fair - I personally apologize for some of those layers of divs and some of that JS as they're definitely my fault!
For context, Hex lets you write Python and SQL code in a notebook-esque format and then create apps from that to share across the web. So there's actually quite a breadth of functionality we need to support under the hood that adds to frontend complexity. We also revamped our whole app-building experience recently, so there's a couple straggling bugs (like the text selection one you mentioned, whoops!).
But I totally agree with you - thinking about all that JS makes me wince a little haha as we definitely care and want to improve frontend performance. We plan to make better use of code-splitting and lazy-loading of JS so that the frontend code for more complex apps is only pulled in if/when necessary. (We also want to work on building better tooling to make analysis of code-splitting effectiveness easier - we've found that a lot of existing webpack bundle analyzer tools don't provide enough visibility for our use cases. Maybe an open source project for us one day!) And we want to decrease over-the-wire data size and reduce necessary network calls so you can get a faster initial load. We're a small team, so can't make promises when exactly this will all happen, but hopefully with these changes and other improvements things will feel a bit snappier someday soon