Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Mise En Place

buttondown.email

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Software Mise En Place

#61

Post by senjin »

There's a book by Dan Charnas called "Work Clean: The life-changing power of mise-en-place to organize your life, work, and mind" that does a great job of explaining the system of mise en place beyond just setup and precutting vegetables. My favorite takeaway that has actually helped my organization in practice has been to leave a project/code base in a clean state after working on it. Sounds obvious but writing checklists for tests, documentation, setup for the next person, etc. has been really helpful.

https://www.amazon.com/Work-Clean-life-changing-mise-en-plac...

Re: Software Mise En Place

#62

Post by wpietri »

chrisdbanks wrote: post #47
adhesive_wombat wrote: post #27

Earlier quoted context omitted.

This is the difference between a commercial kitchen and your own kitchen on a normal day. Strict mise en place applies to the former. In a commercial kitchen, you'd better have the peppers (say) chopped and ready so you can use them. Not only for a single serving of one dish, but for all plates you expect to make of any dish with chopped pepper in it. You cannot pipeline chopping the peppers with frying the onions wh…

I would suggest that it's never a good idea to be cooking several dishes at the same time in the world of software. Software and cooking are completely different in terms of the cost of making a mistake. A single bug in production can take more time to find and fix than the work in the first place. I can see that in a commercial kitchen that it makes sense to prepare all the ingredients before because you can do this…

That's a good point. In a commercial kitchen one can declare "bankruptcy" by throwing out a single dish (or perhaps a set of dishes if one component was bad and the badness wasn't detected before use). But in software, declaring "bankruptcy" is the dreaded ground-up rewrite. It's like burning the whole restaurant down and starting over.

I think another important difference is that software is much less predictable. Thanks to low/zero-cost replication, we spend much more time doing something novel than a commercial chef does. If a developer is doing the same thing over and over, that's a an opportunity to extract a service or a framework or a library. Whereas restaurants have much more predictable workloads, making it much safer to, say, chop 100 carrots than to write 100 classes in advance of need.

Re: Software Mise En Place

#63

Post by simulate-me »

stavros wrote: post #51
simulate-me wrote: post #50

Earlier quoted context omitted.

“Cooking onions is not down time” directly follows from “there’s no downtime in cooking.” If there is no downtime in cooking is true, then *cooking* onions cannot be downtime.

Indeed, and if the GP has said "there's no downtime in cooking", it would have been apt. "Cooking onions is not downtime" isn't an effective rebuttal of the general point of "I chop things during downtime, for example when cooking onions".

How is "there's no downtime in cooking" better than "Cooking onions is not downtime?" Both are assertions without backing evidence. For instance, it's possible for "Cooking onions is not downtime?" to be true (e.g. cooking onions requires active work) while "there's no downtime in cooking" is not true (e.g. cooking chicken broth involves downtime).

Re: Software Mise En Place

#64

Post by stavros »

simulate-me wrote: post #63
stavros wrote: post #51

Earlier quoted context omitted.

Indeed, and if the GP has said "there's no downtime in cooking", it would have been apt. "Cooking onions is not downtime" isn't an effective rebuttal of the general point of "I chop things during downtime, for example when cooking onions".

How is "there's no downtime in cooking" better than "Cooking onions is not downtime?" Both are assertions without backing evidence. For instance, it's possible for "Cooking onions is not downtime?" to be true (e.g. cooking onions requires active work) while "there's no downtime in cooking" is not true (e.g. cooking chicken broth involves downtime).

Because one is an effective counterargument if true, the other isn't, even if true. Hence, the former is a better counterargument.

Re: Software Mise En Place

#65

Post by tekno45 »

simonw wrote: post #39

I use the term "muse em place" for software development too. My version involves research, which I perform in GitHub issue comments. Any time I'm developing a feature there's usually a bunch of supporting research: how does the existing code work and where is it located? Are there any supporting open source packages I need to add? How do those work, and where is their documentation? Any good examples out there? I gat…

im actually really liking this. Thank you.

Re: Software Mise En Place

#66

Post by Mikeb85 »

wpietri wrote: post #62
chrisdbanks wrote: post #47

Earlier quoted context omitted.

I would suggest that it's never a good idea to be cooking several dishes at the same time in the world of software. Software and cooking are completely different in terms of the cost of making a mistake. A single bug in production can take more time to find and fix than the work in the first place. I can see that in a commercial kitchen that it makes sense to prepare all the ingredients before because you can do this…

That's a good point. In a commercial kitchen one can declare "bankruptcy" by throwing out a single dish (or perhaps a set of dishes if one component was bad and the badness wasn't detected before use). But in software, declaring "bankruptcy" is the dreaded ground-up rewrite. It's like burning the whole restaurant down and starting over. I think another important difference is that software is much less predictable. T…

Dunno, throwing out one dish is more like deleting one file. The whole codebase being the restaurant.

Re: Software Mise En Place

#67

Post by Mikeb85 »

willis936 wrote: post #28
stavros wrote: post #25

Earlier quoted context omitted.

I believe the OP says exactly that he doesn't make it in the course of other work, but during downtime, which is overall faster.

Frying onions is not downtime.

It kind of is, versus an active task like chopping.

Re: Software Mise En Place

#68

Post by TheCoelacanth »

WJW wrote: post #54
pydry wrote: post #13

Earlier quoted context omitted.

>In cooking, you usually know the recipe and have experience before preparing it for many people. In programming, you often explore and create, trying out new things that you didn't know before. Im pretty sure that experimentation equally well to cooking.

There is experimentation in cooking, but not usually in restaurants while serving actual customers. That is the time for just making the recipes you practiced. There is very little reason to write out (say) the same algorithm a hundred times because you have a hundred different users who need it, but a cook can't just ctrl-C ctrl-V a dish.

I think that's the case for for lower-end restaurants, but for high-end restaurants, they are going to be tweaking things as they go. Ingredients are never perfectly interchangeable because they have to be grown or raised in real-world conditions that vary from one farm to the next or one season to the next.

Re: Software Mise En Place

#69

Post by zeroonetwothree »

shaded-enmity wrote: post #60
chrisdbanks wrote: post #15

For me, "Mise en place", has nothing to do with chopping everything beforehand and in fact that is completely different from how I cook and develop software. Chopping everything at the start seems like it takes longer. I think Mise en place can mean different things to different people. The way I was taught it was to have everything "in place" before you start. Literally you gather all the ingredients in one place (o…

This all depends how much product are you expected to produce. Your "don't chop things beforehand" works if you're cooking for 1 or 2, but if you need to cook for 4+ you absolutely need to plan your steps and prepare your ingredients so that you merely combine them. This is evermore important if you want to have some sufficiently consistent level of quality, which I suppose is implied.

I cook for four (my family) and always just pipeline everything. Sometimes I make up to 4 dishes at once. This feels a lot faster to me. So at least for that number I don’t agree.

Re: Software Mise En Place

#70

Post by simonw »

exdsq wrote: post #56
simonw wrote: post #39

I use the term "muse em place" for software development too. My version involves research, which I perform in GitHub issue comments. Any time I'm developing a feature there's usually a bunch of supporting research: how does the existing code work and where is it located? Are there any supporting open source packages I need to add? How do those work, and where is their documentation? Any good examples out there? I gat…

Do you have any example issues of more complex problems you’ve worked on, to show it in more detail? I like the premise of the idea - especially in remote-first teams it’s a great way to share information, just wondering what it ends up looking like :)

Here's one from this morning: https://github.com/simonw/datasette/issues/1718

This one is a bit more involved: https://github.com/simonw/shot-scraper/issues/18

There are a few good examples linked to at the very bottom of https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/

Post reply on HN