31–40 of 85 posts
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…
* Physically clean desk and laptop.
* Commit old code changes before working on new ones.
* Main branch is pulled.
* Fix the build before writing more code.
* Set up tmux or whatever so every terminal is in a convenient place.
* Check that the failing test fails as expected.
* Set up text editor/IDE to have easy access to relevant files and browser to have access to e.g. the relevant JIRA.
* Close irrelevant browser windows and applications.
etc.
Dont think it means "do the easy tasks first", just "prep the environment".
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…
Another good software example is having slack. If you're always busy, you may not be working on the right things.
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.
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…
Then you are a "bad operator" according to Escoffier:) "I should thus resemble those bad operators who, having neglected their mise en place, are obliged to make it in the course of other work, and thereby not only run the risk of making it badly, but also of losing valuable time which might be used to better advantage. Elementary preparations consist of those things whereof one is constantly in need, which may be pr…
I think this one sentence much better describes what I feel the spirit of mise en place is in regards to software. Things which you need, which may be prepared in advance. When I think of it this way, I am reminded of the many little scripts, aliases, editor plugins, configuration settings, etc. that I have accrued over the course of my day job that make it easy to do the things I have to do many times per day. For example, our product can be launched in several different configurations, so I have a script that takes a build directory and a configuration parameter and sets up everything so it's launched exactly as it should be; I also have a bunch of GDB scripts to set up the environment and to display data in a meaningful fashion; and many more things like that. Unlike in cooking however, once I have set up some aspect of my msie en place, it stays that way forever - it's like if you cut the peppers once and you have an infinite bucket of cut peppers. When looked at that way, I think it makes sense to make your mise en place as you go, since you don't really know what you need before you need it. Obviously a lot of trivial things should be set up beforehand and shared with the team, but every programmer has a slightly different workflow, so it pays to write some simple little tools for yourself when you come to need them and put them in your mise en place.
Earlier quoted context omitted.
This is the "your example is invalid, therefore your argument is invalid" fallacy.
It's not a fallacy. There is downtime in baking, but not cooking.
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. :)
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/
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 handl…
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.