Below is a quote from Anthony Bourdain's book "Kitchen Confidential"
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.”
Line cooking in a restaurant is very different than cooking at home. Mis-en-place is usually not efficient for the home cook. The example cited by Jeff W is contrived. I've cooked at least hundreds if not thousands of onions at home and in restaurants and in almost every case I was chopping carrots or celery or peppers while those onions were cooking and never once did I have a failure due to timing.
I don't know. I've found mis-en-place to be a great help when cooking at home and I've never worked as a cook in a restaurant or caterer. It helps with timing and it is also just nice to feel like the cook itself is simply "going downhill."
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).
I was a line cook for over a decade too and cook a lot at home obviously. Mise just looks different at home but it still happens. I still get out my cutting board and hone my knife before I start peeling the carrots you know.
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.
It's quite a nice reminder at the top of an emacs config.
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 have never heard of mis-en-place but I have always done it in my home cooking in order to have a better flow. Chop, then move on from chopping to the next thing; the next thing; don’t bounce back and forth.
It’s just how my brain functions best. I would hate to be sautéing onions and in the back of my mind be “gotta chop the peppers in 2 minutes shit”. Plus I like to clean when I have downtime, so if I have two minutes I’ll wash my cutting boards and stuff.
I feel this way about UIs that are never stable enough and not configurable enough for us rubes to be trusted laying it out how we want.
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.
Because there's the constant struggle of making something so complicated that nobody wants to actually configure it and use it. So you have two options: sensible defaults and hiding things away, or just avoiding customization outright. And the second is always cheaper (for commercial products).
It's a failure of the UI and windowing frameworks to enable this level of programmable personalization. Designers chasing fads are just the opportunists that fill the gaps left by Apple's rigid design ethos, Microsoft's random gyrations, and Linux's ever-delayed Year of the Desktop.
As ridiculous as it first sounds, VR will likely provide the technology for the way forward.
Mise En Place is very helpful as anyone who begins to practice it can attest.
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.
Both principles indeed apply to all sorts of jobs!
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.
I have a strong desire to refactor code as I read it. I tend to avoid this behavior because (a) most codebases are in need of so much cleanup, and (b) I like to keep commits small and topical. Perhaps I should re-evaluate how I weight these factors.
I spent a few years working in a kitchen, and those are the two items I took away myself - before I start cooking I clear out the dish rack, and then I have a sink full of soap and water and most of the chopping is done before I even turn on the stove-top.
For all of those people complaining about "the 3 minute mark", not only are you arguing the metaphor, but you're leaving out context.
> "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.
Do software people really find it strange that people want to have all their tools and workspace set up in a particular way in advance and it makes them more efficient?
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.
Do you really find it strange that some software people just think of food as calories? As fuel? And that slightly "overcooked" bell peppers just isn't a good reason to optimize for taste, when it is just as reasonable to optimize for time?
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.
Sure. Like I worked at a company that spent months on design docs and design reviews. Like that? Everything was nicely set up. It was great. Super effective.
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.
This is an allegory for AOT vs JIT compilation. AOT decreases jitter. JIT reduces startup latency (counting AOT compilation time).
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.
> You think you can outsmart the recipe and chop the peppers while the onions are cooking. [...] The bell peppers need to make it into the skillet by the 3 minute mark after the onions are in or else the dish is ruined.
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 an amazing website. While it looks very minimalistc, every paragraph is in 11 nested divs and a final <p>, all with arcane IDs, classnames, and individual styling. Nearly 5 MB of JavaScript are required. Google Lighthouse only reports preliminary scores because it times out.
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.
Happened to see this thread on HN, (and disclaimer I'm an engineer at Hex) very cool project jwithington!
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
FWIW on iOS 12.4 it doesn't do anything and just renders immediately as a white page. On iOS 13.5 it takes longer but then gives me an error message "something went wrong / try again" which I presume is from the page (not the browser). On iOS 14.0~b1 it took a while to think (showing an awkward loading progress indicator that I am used to only seeing from Google's ridiculous blogging platform) but then loaded the page! Only, I can't scroll... well, vertically :/ I awkwardly CAN scroll horizontally (though only by a bit). Reader view, "of course", doesn't work, because this website is too "awesome" to allow that. I am now waiting for an iOS 15+ device to charge in the hope I might be able to... actually, I don't remember what the article was supposed to be about anymore? Onions or something? (edit: OK, so iOS 15.1 was finally able to render the content, with vertical scrolling!)
That's interesting. It's a data workspace platform called Hex. It's really something more like a Jupyter Notebook than a simple webpage.
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.
This is not a simple website, looks like it's served on a platform called Hex. While this particular page is light on content, the platform seems optimized for more complex usecases.
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.