22 ms·

Software Mise En Place

188 points by BerislavLopac 5y ago

thanatos519 5y ago
Is there a French term for "clean as you go" which is IMHO also an essential part of cooking (and baking)? I like to have the kitchen already clean by the time the food is ready. "Clean as you go" is apparently much harder with software. :)
- jpm_sd 5y ago
  Usually by the time I've finished making a meal, the sink is full of technical debt
  - exdsq 5y ago
    I’m the same but thankfully my house has a rule of whoever doesn’t cook cleans. So tech debt isn’t too bad!
- gryn 5y ago
  - "au fur et à mesure" - graduellement - progressivement - petit à petit -------- side note: for some reason I find the use french words, terms, and expressions in English (and there are a lot, in a strict technical sense almost every french word is a valid English word) somewhat annoying because they usually diverge with time in ways that are important enough to change meaning but not enough for the sense to be inferred just from local context alone. given how prevalent anglicisms are in french this make for more confusing and verbose conversations. -------- Ex: "mise en place" just mean setup, so image two french software engineers talking about software "setup", one that has in his mind the meaning/philosophy meant here and the other using the more generic meaning.
xcambar 5y ago
To relate the practice of software engineering to cooking is very fruitful. At least when it comes to a ssmall-ish feature. For larger systems, the typical aechitecture/urbanism analogy is probably more suitable. Nevertheless, I will reuse it in my teams.
elcapitan 5y ago
> You don’t start prepping one vegetable while another is already cooking. I actually do that all the time - different ingredients have different densities and different cooking times, so it makes total sense to start cooking the harder ones while cutting the softer ones (e.g. when making a Minestrone soup). Or you want an onion/garlic/tomato base to break down before inserting other ingredients that should only cook shortly and retain their texture.
- kaapipo 5y ago
  This so much. If I'm cooking at the end of a long workday, in my 2 m² kitchen, I won't give a fuck about mise en place
  - douglee650 5y ago
    excellence is a habit; mise en place for at home utilitarian cooking is an approach, not a workflow
- jimmygrapes 5y ago
  The thing with that is you need to know what takes longer, and how long that longer is, beforehand. That comes from experience mostly. You will certainly screw it up several times before you get a feel for it.
  - elcapitan 5y ago
    You will also screw it up if you don't do it like this, because if you cook the soft things first, they will mush while the other parts are still hard. Cooking is always experience and tasting while doing it. And it can vary a lot based on ingredients of the day. It's not really that hard to get it right though, just by touching it it's easy to see that a zucchini will cook faster than fennel.
    - pm215 5y ago
      Generally the recipe will tell you to cook the fennel first, though, and will give timings so you can get it right. The problem with prep-on-demand is that if you start cooking the fennel and then are unable to prep the zucchini fast enough to add it at the right time then you're stuffed. If you prep everything in advance then the worst that happens is you stand around with nothing to do for 5 minutes until the time to add the zucchini arrives -- so for an inexperienced cook it's more reliable and less stressful.
sendfoods 5y ago
Seeing two of my passions combined make me unreasonably happy!
uniqueuid 5y ago
There's one place where the analogy breaks down IMO: 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. Mise en place suggests that you know exactly what ingredients and tools you'll need and what to do with them. Perhaps a woodworking workshop is a better analogy for the creative process: You're trying out a lot, taking scrap pieces as dummy items to test on, create scaffolding and helper items to get where you want. But afterwards, you clean up the bench and service the tools. To me, this kind of "explosion first, prune afterwards" process seems more natural/common?
- LichenStone 5y ago
  I've been getting into the early stages of developing a game concept, from the position of a near complete novice. My idea is very vague but I know enough of the elements to be able to break it down into numerous atomised technical challenges to be overcome, little things like making something move and emit a sound. So far this approach seems to be working really well, I'm not getting overwhelmed or bogged down by trying to 'vertical slice' anything, and keeping the end goal very loosely defined means I can easily adopt new gameplay ideas as I come across them in the process of tinkering with the available tools and their interactions. Once I've figured out all the individual challenges I can begin in earnest to craft the whole.
- pydry 5y ago
  >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.
  - qubidt 5y ago
    Sure, but the ratio is way different. I frequently cook the exact recipe the exact same way as I've done before, but I'd struggle to think of a reason to rewrite the exact same implementation of the same program.
  - 5y ago
roflc0ptic 5y ago
I’ve recently started working on a non-trivially distributed system and boy this rings true for me! We’ve got limited facility for integration testing, so I’ve become increasingly fanatical about testing every piece I can in each component. Every bug I catch locally is a bug I don’t have to surface out in the cluster, and the feedback loop is much tighter. “Test first” still feels like a bridge to far to me (my programming is usually more exploratory than that), but with the mis en place framework it’s easier to see why people might like it so much.
praptak 5y ago
I kind of like to think code itself could use this analogy. If a piece of code combines data from three systems, then maybe first fetch it from each one (maybe in parallel), then "wash" it (check preconditions, normalize, etc.) Then you hopefully have data which is ready for doing the core work without the code being muddled with fetching missing stuff and cleaning it. I can obviously find counterexamples when it is not so easy but I think I can also find functions which unnecessarily mix fetching stuff, checking it and the core logic.
- cehrlich 5y ago
  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.
  - exdsq 5y ago
    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)
    - cehrlich 5y ago
      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_.
      - exdsq 5y ago
        Yeah that's fair! This is one of those times when coding is similar to writing and mostly personal aesthetics.
sudhirj 5y ago
My mise en place is very similar to the authors - set up whatever I need to get fast and clear feedback before anything. If it’s a web service, set up a hello world / health check to auto-deploy with migrations if applicable, after automatically running the build. If it’s a library, set up a build and CI, and any version bumping and release scripts, docs autogeneration. Basically set yourself up for success and handle a lot of the non-project related heavy lifting. That makes a great foundation off which to launch and iterate quickly.
- makapuf 5y ago
  I also when I setup an api like to create a zero API (with hardcoded answers) and deploy it to production if possible. That makes sure that flows are opened, everyone is clear with ci, ... then code the tests and the functions. That may raise earlier integration issues that will happen.
  - bstpierre 5y ago
    Similarly, I sometimes generate dummy output up front. It’s especially handy when multiple teams are going to be processing some pipeline.
karmeliet 5y ago
Mise en place is a useful mental model for everyday activities, but I don't think the author gave a good example in the post. I don't think intensity or difficulty is the key differentiator between preparation and the actual work. To me, it's mainly about separating tedious and repetitive tasks from the ones that require attention and creativity. Prep work means that you perform something that you have done many-many times before and it feels automatic. Prep can be also harder and more intense in many ways than the actual work itself.
- douglee650 5y ago
  I mean, author also claims to "know more about my city’s best grocery stores than its best restaurants" … so there's that
chrisdbanks 5y ago
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 (on a metal tray) before you start cooking. This has three main benefits: 1) you make sure you have everything you need; 2) you don't forget to add anything as you go because at the end your tray should be empty; 3) you don't mess up timings by searching for something while you're cooking that you can't find; Thus I use Mise en place, but I don't chop everything at the start. I chop the onion and then start cooking it, and then chop the other ingredients. Chopping everything else upfront would make the process slower. Similarly in software development I often save simple tasks for when I need mental relief from a hard task. Working on a simple task can often give you the space you need for your brain to solve the hard task it's working on in the background. Doing all the simple tasks up front does not seem to me like a good approach to cooking or software development, but making sure you know what all the ingredients are and have them all ready, does.
- pm215 5y ago
  I do tend to cook like this, but that's because I'm an inexperienced cook :-) I don't trust my ability to complete a prep task in the bounded amount of time you have once you've actually started cooking, so unless the time available is clearly long and the prep task trivial I tend to do most to all of the prep in advance. You're absolutely right that it takes longer in wall clock time but I find it less stressful, and that's valuable to me.
  - IanCal 5y ago
    This is good sensible planning, and it can shift as you get more experienced. You'll recognise orders that make sense (I know I need the oven preheated so start that now, then chop / I have a wait before this step and just need to chop the mushrooms which I know only take me X so I'll do that then).
- karmeliet 5y ago
langsoul-com 5y ago
Isn't this just waterfall? Prep the shit outa everything requirement and design wise, then make it in sequential fashion?
- TuringTest 5y ago
  > Isn't this just waterfall? I don't think so, because the article is talking about prepping up the tools and infrastructure needed for the project, not the requirements and design needed for the program's business logic.
- mkl95 5y ago
  It is also agile done wrong by companies that don't understand how iteration works.
- sparcpile 5y ago
  The author re-worded iterative development where you start with a skeleton and slowly build out. Their example was to build out a simple build pipeline with stub projects that are replaced over time. The Practice of Programming(Kernighan and Pike 1999) https://www.cs.princeton.edu/~bwk/tpop.webpage/ https://www.cs.princeton.edu/~bwk/tpop.webpage/ goes into much better details of the iterative development that is actually being done by the author. If you know the overall design of your program, you build out the skeleton with everything stubbed out. As you iterate through development, those stubs are fleshed out into fully working components. The analogy of mise-in-enplace works if you have a ready for reusable components (COTS, FOSS, or personal) that you quickly pull off the shelf and combine into the larger product. Mise means having everything ready to go; you have your set of reusable components and subsystems that you can quickly pull together to make a new product.
bibackdas 5y ago
ChrisMarshallNY 5y ago
That’s a useful analogy. One of the things that I like to do, is create multiple reusable, standalone repos of tools that can be integrated into larger, aggregate, projects. Works a charm. That’s sort of a mise en place. But the trap is that we can spend so much time on prep and infrastructure, that we don’t have time for the project, itself. I’ve done that. There was an SNL character (Phil Hartman played it), called “The Anal-Retentive Chef.” The gist was, that he often spent so much time on prep, that he couldn’t make the meal.
simonw 5y ago
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 gather all of this research in issue comments - sometimes working on my mobile phone. Once that's all gathered, the actual coding work (on my laptop) often takes significantly less time then the research did. Wrote a bit about my process here: https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/ https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/
- exdsq 5y ago
  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 :)
  - simonw 5y ago
    Here's one from this morning: https://github.com/simonw/datasette/issues/1718 https://github.com/simonw/datasette/issues/1718 This one is a bit more involved: https://github.com/simonw/shot-scraper/issues/18 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/ https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/
- tekno45 5y ago
  im actually really liking this. Thank you.
seanwilson 5y ago
> Just one problem with this: I’ve never used GitHub actions before. So I had to figure that out, along with setting up proper S3 credentials and getting my site to build. ... > What does mise in place tell me? Separate the tasks. Find a way to prep just the action file, then just the credentials, then the idiosyncrasies of my projects. After that I can integrate the pipeline with the documentation proper. The problem I find is that unless you've done something very similar before (and recently, because services and APIs are always in flux), what can happen is you complete a few tasks, then on a later task you find some gotcha that means your original approach isn't going to work, so you come up with a workaround which requires you to redo/change the earlier tasks. Development whack-a-mole. So what I tend to do is take the riskiest task first, do just enough to convince myself it can be finished, then move on to the next task etc. and then iterate back around filling in the gaps until I'm done. By the way, I recently did some GitHub Action automation and it was super frustrating. There's no official way to run/test this locally (there's https://github.com/nektos/act https://github.com/nektos/act which doesn't replicate a lot of features) so you end up editing-saving-pushing-waiting-diagnosing (e.g. even just for basic syntax errors) in this painfully slow feedback loop until it eventually works and hope it doesn't break later. I'd rather just stick to the simplest single script I can come up with than use GitHub Action features because of this.
- vinceguidry 5y ago
  I didn't think there could be anything worse than Harness. Then I got asked to build and maintain GitHub Actions CI pipelines. Never again.
  - seanwilson 5y ago
    I'm sure I got a GitHub Action syntax error for writing 'main' instead "main" for a conditional check that the local "act" tool didn't pick up, the development feedback loop was infuriating... How are people able to piece together such complex GitHub Actions? Does GitHub have to deal with this internally as well or they just haven't gotten around to releasing dev tools yet?
lbayes 5y ago
This is how (and at least partly, why) I often work in a TDD style. The test environment is the isolated place where I can quickly stand up individual parts and then later, assemble them into larger chunks of value.
senjin 5y ago
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-place-organize/dp/1623365929/ref=sr_1_4 https://www.amazon.com/Work-Clean-life-changing-mise-en-plac...
- alasdair_ 5y ago
  I deliberately leave a project in a broken state when I am done for the day (e.g. a broken test) if I am coming back to it tomorrow. The reason is that it’s very easy to get started again - the test is broken, so the next task is to fix the test.
- paulcole 5y ago
  Yes, this is an excellent book. About 1/3 of the people where I work read it. The difference between those who did and those who didn’t is stark. A good “add-on” read to this is Essentialism. I felt like it complemented Working Clean very well. https://www.amazon.com/Essentialism-Disciplined-Pursuit-Greg-McKeown/dp/0804137382 https://www.amazon.com/Essentialism-Disciplined-Pursuit-Greg...
tmnvix 5y ago
I sometimes remind myself of the principle 'mise en place' when I need that little bit of motivation to get started on something (trusting that once I've invested a few minutes I'll carry on). It involves 'getting out all the tools' - the local development server, opening up my notes, a terminal window running the virtual environment, etc. An equally important part though is clearing away the things I won't be using.

188 points by BerislavLopac 5y ago

Is there a French term for "clean as you go" which is IMHO also an essential part of cooking (and baking)? I like to have the kitchen already clean by the time the food is ready. "Clean as you go" is apparently much harder with software. :)

jpm_sd 5y ago
Usually by the time I've finished making a meal, the sink is full of technical debt
- exdsq 5y ago
  I’m the same but thankfully my house has a rule of whoever doesn’t cook cleans. So tech debt isn’t too bad!
gryn 5y ago
- "au fur et à mesure" - graduellement - progressivement - petit à petit -------- side note: for some reason I find the use french words, terms, and expressions in English (and there are a lot, in a strict technical sense almost every french word is a valid English word) somewhat annoying because they usually diverge with time in ways that are important enough to change meaning but not enough for the sense to be inferred just from local context alone. given how prevalent anglicisms are in french this make for more confusing and verbose conversations. -------- Ex: "mise en place" just mean setup, so image two french software engineers talking about software "setup", one that has in his mind the meaning/philosophy meant here and the other using the more generic meaning.

xcambar 5y ago

To relate the practice of software engineering to cooking is very fruitful. At least when it comes to a ssmall-ish feature. For larger systems, the typical aechitecture/urbanism analogy is probably more suitable. Nevertheless, I will reuse it in my teams.

elcapitan 5y ago

> You don’t start prepping one vegetable while another is already cooking. I actually do that all the time - different ingredients have different densities and different cooking times, so it makes total sense to start cooking the harder ones while cutting the softer ones (e.g. when making a Minestrone soup). Or you want an onion/garlic/tomato base to break down before inserting other ingredients that should only cook shortly and retain their texture.

kaapipo 5y ago
This so much. If I'm cooking at the end of a long workday, in my 2 m² kitchen, I won't give a fuck about mise en place
- douglee650 5y ago
  excellence is a habit; mise en place for at home utilitarian cooking is an approach, not a workflow
jimmygrapes 5y ago
The thing with that is you need to know what takes longer, and how long that longer is, beforehand. That comes from experience mostly. You will certainly screw it up several times before you get a feel for it.
- elcapitan 5y ago
  You will also screw it up if you don't do it like this, because if you cook the soft things first, they will mush while the other parts are still hard. Cooking is always experience and tasting while doing it. And it can vary a lot based on ingredients of the day. It's not really that hard to get it right though, just by touching it it's easy to see that a zucchini will cook faster than fennel.
  - pm215 5y ago
    Generally the recipe will tell you to cook the fennel first, though, and will give timings so you can get it right. The problem with prep-on-demand is that if you start cooking the fennel and then are unable to prep the zucchini fast enough to add it at the right time then you're stuffed. If you prep everything in advance then the worst that happens is you stand around with nothing to do for 5 minutes until the time to add the zucchini arrives -- so for an inexperienced cook it's more reliable and less stressful.

sendfoods 5y ago

Seeing two of my passions combined make me unreasonably happy!

uniqueuid 5y ago

There's one place where the analogy breaks down IMO: 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. Mise en place suggests that you know exactly what ingredients and tools you'll need and what to do with them. Perhaps a woodworking workshop is a better analogy for the creative process: You're trying out a lot, taking scrap pieces as dummy items to test on, create scaffolding and helper items to get where you want. But afterwards, you clean up the bench and service the tools. To me, this kind of "explosion first, prune afterwards" process seems more natural/common?

LichenStone 5y ago
I've been getting into the early stages of developing a game concept, from the position of a near complete novice. My idea is very vague but I know enough of the elements to be able to break it down into numerous atomised technical challenges to be overcome, little things like making something move and emit a sound. So far this approach seems to be working really well, I'm not getting overwhelmed or bogged down by trying to 'vertical slice' anything, and keeping the end goal very loosely defined means I can easily adopt new gameplay ideas as I come across them in the process of tinkering with the available tools and their interactions. Once I've figured out all the individual challenges I can begin in earnest to craft the whole.
pydry 5y ago
>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.
- qubidt 5y ago
  Sure, but the ratio is way different. I frequently cook the exact recipe the exact same way as I've done before, but I'd struggle to think of a reason to rewrite the exact same implementation of the same program.
- 5y ago

roflc0ptic 5y ago

I’ve recently started working on a non-trivially distributed system and boy this rings true for me! We’ve got limited facility for integration testing, so I’ve become increasingly fanatical about testing every piece I can in each component. Every bug I catch locally is a bug I don’t have to surface out in the cluster, and the feedback loop is much tighter. “Test first” still feels like a bridge to far to me (my programming is usually more exploratory than that), but with the mis en place framework it’s easier to see why people might like it so much.

praptak 5y ago

I kind of like to think code itself could use this analogy. If a piece of code combines data from three systems, then maybe first fetch it from each one (maybe in parallel), then "wash" it (check preconditions, normalize, etc.) Then you hopefully have data which is ready for doing the core work without the code being muddled with fetching missing stuff and cleaning it. I can obviously find counterexamples when it is not so easy but I think I can also find functions which unnecessarily mix fetching stuff, checking it and the core logic.

cehrlich 5y ago
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.
- exdsq 5y ago
  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)
  - cehrlich 5y ago
    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_.
    - exdsq 5y ago
      Yeah that's fair! This is one of those times when coding is similar to writing and mostly personal aesthetics.

sudhirj 5y ago

My mise en place is very similar to the authors - set up whatever I need to get fast and clear feedback before anything. If it’s a web service, set up a hello world / health check to auto-deploy with migrations if applicable, after automatically running the build. If it’s a library, set up a build and CI, and any version bumping and release scripts, docs autogeneration. Basically set yourself up for success and handle a lot of the non-project related heavy lifting. That makes a great foundation off which to launch and iterate quickly.

makapuf 5y ago
I also when I setup an api like to create a zero API (with hardcoded answers) and deploy it to production if possible. That makes sure that flows are opened, everyone is clear with ci, ... then code the tests and the functions. That may raise earlier integration issues that will happen.
- bstpierre 5y ago
  Similarly, I sometimes generate dummy output up front. It’s especially handy when multiple teams are going to be processing some pipeline.

karmeliet 5y ago

Mise en place is a useful mental model for everyday activities, but I don't think the author gave a good example in the post. I don't think intensity or difficulty is the key differentiator between preparation and the actual work. To me, it's mainly about separating tedious and repetitive tasks from the ones that require attention and creativity. Prep work means that you perform something that you have done many-many times before and it feels automatic. Prep can be also harder and more intense in many ways than the actual work itself.

douglee650 5y ago
I mean, author also claims to "know more about my city’s best grocery stores than its best restaurants" … so there's that

chrisdbanks 5y ago

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 (on a metal tray) before you start cooking. This has three main benefits: 1) you make sure you have everything you need; 2) you don't forget to add anything as you go because at the end your tray should be empty; 3) you don't mess up timings by searching for something while you're cooking that you can't find; Thus I use Mise en place, but I don't chop everything at the start. I chop the onion and then start cooking it, and then chop the other ingredients. Chopping everything else upfront would make the process slower. Similarly in software development I often save simple tasks for when I need mental relief from a hard task. Working on a simple task can often give you the space you need for your brain to solve the hard task it's working on in the background. Doing all the simple tasks up front does not seem to me like a good approach to cooking or software development, but making sure you know what all the ingredients are and have them all ready, does.

pm215 5y ago
I do tend to cook like this, but that's because I'm an inexperienced cook :-) I don't trust my ability to complete a prep task in the bounded amount of time you have once you've actually started cooking, so unless the time available is clearly long and the prep task trivial I tend to do most to all of the prep in advance. You're absolutely right that it takes longer in wall clock time but I find it less stressful, and that's valuable to me.
- IanCal 5y ago
  This is good sensible planning, and it can shift as you get more experienced. You'll recognise orders that make sense (I know I need the oven preheated so start that now, then chop / I have a wait before this step and just need to chop the mushrooms which I know only take me X so I'll do that then).
karmeliet 5y ago

langsoul-com 5y ago

Isn't this just waterfall? Prep the shit outa everything requirement and design wise, then make it in sequential fashion?

TuringTest 5y ago
> Isn't this just waterfall? I don't think so, because the article is talking about prepping up the tools and infrastructure needed for the project, not the requirements and design needed for the program's business logic.
mkl95 5y ago
It is also agile done wrong by companies that don't understand how iteration works.
sparcpile 5y ago
The author re-worded iterative development where you start with a skeleton and slowly build out. Their example was to build out a simple build pipeline with stub projects that are replaced over time. The Practice of Programming(Kernighan and Pike 1999) https://www.cs.princeton.edu/~bwk/tpop.webpage/ https://www.cs.princeton.edu/~bwk/tpop.webpage/ goes into much better details of the iterative development that is actually being done by the author. If you know the overall design of your program, you build out the skeleton with everything stubbed out. As you iterate through development, those stubs are fleshed out into fully working components. The analogy of mise-in-enplace works if you have a ready for reusable components (COTS, FOSS, or personal) that you quickly pull off the shelf and combine into the larger product. Mise means having everything ready to go; you have your set of reusable components and subsystems that you can quickly pull together to make a new product.

bibackdas 5y ago

ChrisMarshallNY 5y ago

That’s a useful analogy. One of the things that I like to do, is create multiple reusable, standalone repos of tools that can be integrated into larger, aggregate, projects. Works a charm. That’s sort of a mise en place. But the trap is that we can spend so much time on prep and infrastructure, that we don’t have time for the project, itself. I’ve done that. There was an SNL character (Phil Hartman played it), called “The Anal-Retentive Chef.” The gist was, that he often spent so much time on prep, that he couldn’t make the meal.

simonw 5y ago

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 gather all of this research in issue comments - sometimes working on my mobile phone. Once that's all gathered, the actual coding work (on my laptop) often takes significantly less time then the research did. Wrote a bit about my process here: https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/ https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/

exdsq 5y ago
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 :)
- simonw 5y ago
  Here's one from this morning: https://github.com/simonw/datasette/issues/1718 https://github.com/simonw/datasette/issues/1718 This one is a bit more involved: https://github.com/simonw/shot-scraper/issues/18 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/ https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/
tekno45 5y ago
im actually really liking this. Thank you.

seanwilson 5y ago

> Just one problem with this: I’ve never used GitHub actions before. So I had to figure that out, along with setting up proper S3 credentials and getting my site to build. ... > What does mise in place tell me? Separate the tasks. Find a way to prep just the action file, then just the credentials, then the idiosyncrasies of my projects. After that I can integrate the pipeline with the documentation proper. The problem I find is that unless you've done something very similar before (and recently, because services and APIs are always in flux), what can happen is you complete a few tasks, then on a later task you find some gotcha that means your original approach isn't going to work, so you come up with a workaround which requires you to redo/change the earlier tasks. Development whack-a-mole. So what I tend to do is take the riskiest task first, do just enough to convince myself it can be finished, then move on to the next task etc. and then iterate back around filling in the gaps until I'm done. By the way, I recently did some GitHub Action automation and it was super frustrating. There's no official way to run/test this locally (there's https://github.com/nektos/act https://github.com/nektos/act which doesn't replicate a lot of features) so you end up editing-saving-pushing-waiting-diagnosing (e.g. even just for basic syntax errors) in this painfully slow feedback loop until it eventually works and hope it doesn't break later. I'd rather just stick to the simplest single script I can come up with than use GitHub Action features because of this.

vinceguidry 5y ago
I didn't think there could be anything worse than Harness. Then I got asked to build and maintain GitHub Actions CI pipelines. Never again.
- seanwilson 5y ago
  I'm sure I got a GitHub Action syntax error for writing 'main' instead "main" for a conditional check that the local "act" tool didn't pick up, the development feedback loop was infuriating... How are people able to piece together such complex GitHub Actions? Does GitHub have to deal with this internally as well or they just haven't gotten around to releasing dev tools yet?

lbayes 5y ago

This is how (and at least partly, why) I often work in a TDD style. The test environment is the isolated place where I can quickly stand up individual parts and then later, assemble them into larger chunks of value.

senjin 5y ago

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-place-organize/dp/1623365929/ref=sr_1_4 https://www.amazon.com/Work-Clean-life-changing-mise-en-plac...

alasdair_ 5y ago
I deliberately leave a project in a broken state when I am done for the day (e.g. a broken test) if I am coming back to it tomorrow. The reason is that it’s very easy to get started again - the test is broken, so the next task is to fix the test.
paulcole 5y ago
Yes, this is an excellent book. About 1/3 of the people where I work read it. The difference between those who did and those who didn’t is stark. A good “add-on” read to this is Essentialism. I felt like it complemented Working Clean very well. https://www.amazon.com/Essentialism-Disciplined-Pursuit-Greg-McKeown/dp/0804137382 https://www.amazon.com/Essentialism-Disciplined-Pursuit-Greg...

tmnvix 5y ago

I sometimes remind myself of the principle 'mise en place' when I need that little bit of motivation to get started on something (trusting that once I've invested a few minutes I'll carry on). It involves 'getting out all the tools' - the local development server, opening up my notes, a terminal window running the virtual environment, etc. An equally important part though is clearing away the things I won't be using.