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

81–85 of 85 posts

Re: Software Mise En Place

#81

Post by orbifold »

TheCoelacanth wrote: post #68
WJW wrote: post #54

Earlier quoted context omitted.

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.

High end restaurants measure everything both quantities, time and temperature extremely precisely and have strict quality control for the ingredients they use in order to ensure a consistent experience.

Re: Software Mise En Place

#82

Post by wunderlust »

wpietri wrote: post #59
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…

Yeah, I understand the term via Anthony Bourdain and his book Kitchen Confidential. I think his description of it also leads to some good software analogies: 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, a…

I’ve worked in kitchens, and this characterization favors my experience much more closely than does the author’s. In a kitchen, mistakes are costly; imagine that you have one chance to compile your code, and if it doesn’t compile, then you lose that code. In fact, I’d go almost as far to say that cooking (in a professional kitchen, where mise en place really matters) and software development are about as different as any two disciplines you can imagine - cats and dogs. The element of time, the cost & consequences of mistakes, the discipline of routine, and the nature of problem solving couldn’t be more dissimilar in these two practices. In fact, they seem different in almost every way, and I’m struggling to find a reasonable common methodology or strategic principle.

Re: Software Mise En Place

#83

Post by cehrlich »

exdsq wrote: post #58
cehrlich wrote: post #11

Earlier quoted context omitted.

I tend to prefer the approach of fetch A wash A fetch B wash B in terms of being easier to read. Of course sometimes there are performance benefits to firing off all the requests right at the start. Anyway I definitely agree that not separating the core logic out from the data fetching/cleaning is a bad idea.

The issue is if you need A, B, and C to do a task and your function fails if it doesn’t retrieve it, won’t it waste time cleaning ingredients for a dish you can’t make? I don’t think it’s less readable than carrot = fetch carrot onion = fetch onion celery = fetch celery clean(carrot) clean(onion) clean(celery) cook(carrot, onion, celery)

This is absolutely true. But if cleaning your data takes barely any compute and only fails less than 1% of the time, it’s splitting hairs.

The way I think about it is, how would I write it if performance didn’t matter? And then from that point I think about what compromises I can make that improve performance at the expense of something else (readability, etc)

Disclaimer: I’m not trying to argue that my preference is _better_.

Re: Software Mise En Place

#84

Post by exdsq »

cehrlich wrote: post #83
exdsq wrote: post #58

Earlier quoted context omitted.

The issue is if you need A, B, and C to do a task and your function fails if it doesn’t retrieve it, won’t it waste time cleaning ingredients for a dish you can’t make? I don’t think it’s less readable than carrot = fetch carrot onion = fetch onion celery = fetch celery clean(carrot) clean(onion) clean(celery) cook(carrot, onion, celery)

This is absolutely true. But if cleaning your data takes barely any compute and only fails less than 1% of the time, it’s splitting hairs. The way I think about it is, how would I write it if performance didn’t matter? And then from that point I think about what compromises I can make that improve performance at the expense of something else (readability, etc) Disclaimer: I’m not trying to argue that my preference is…

Yeah that's fair! This is one of those times when coding is similar to writing and mostly personal aesthetics.

Re: Software Mise En Place

#85

Post by wpietri »

zumu wrote: post #77
wpietri wrote: post #59

Earlier quoted context omitted.

Yeah, I understand the term via Anthony Bourdain and his book Kitchen Confidential. I think his description of it also leads to some good software analogies: 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, a…

Not a former cook, but a former barista, and this resonates with me deeply. The same underlying emotion that drove me to continually wipe down my station is the same that drives me to be fastidious about minutiae in my code bases. I'll have to check this book out!

This is definitely not representative of the book. But I loved it, as do many others, so I doubt you'll find your time wasted.
Post reply on HN