🧑‍🍳 Mise en Place for Development

Mise en place is French for “putting in place”. I’ve heard it in the context of cooking, where you prepare and arrange your ingredients and tools before you even start cooking. Whenever I’ve taken the time to really try to do this well, the whole process becomes smooth compared to my typical “oh no I forgot the tomatoes”. Getting this right really changes the whole way cooking feels. It’s almost like jumping straight into a flow state.

Software can be very flow driven, for me. It feels like my typical workday involves juggling a half-dozen chainsaws while herding cats though, and in real life it just isn’t always possible to really get into the zone. The lure of mise en place for me is that if I can set myself up well for work then it doesn’t take as much time and effort out of my day to get myself there. I see it as enabling myself to work as efficiently as possible as comfortably as possible.

Aymeric Beaumet described it as “nurturing your coding experience.” I really like the questions that they ask in the linked article:

what are my most frequent tasks? where am I wasting my time? what are the most tedious tasks I have to do on a regular basis? which inconsistencies can I find in my workflow? what is slowing me down?

Rephrased, what’s making me uncomfortable? What’s killing my efficiency? A few common culprits as examples:

• Not understanding the terminal. So much development necessitates the use of a shell that avoiding it is only doing yourself a disservice. My personal advice here is to try to do everything via the command line and only dial that back where it’s absolutely necessary.
• Not understanding your tools in general. The terminal is such an important one that I think it does deserve its own bullet point, but truly the idea stands for anything you’re interacting with on a regular basis. It sounds obvious to say but the more time you put into understanding what you’re actually doing, the better you’ll be at doing it.
• Slow (or non-existent) test suites. If you can’t run your test suite at about the same pace you’re making code changes, then you aren’t going to run your test suite at the same pace that you’re making code changes.
• Pointless junk. Controversial take, I know, but seriously: how much of what you’re doing really matters? It’s not always the case, but complete elimination of a task is better than just doing it faster. A real world example is that maybe your team doesn’t need a full on standup every morning and changing over to async updates in a Slack thread accomplishes the same goal.