Mis en place is the term for the prep work done in kitchens prior to the actual act of cooking, or in a restaurant kitchen, prior to service. It basically entails slicing, dicing, measuring and otherwise prepping all your ingredients and positioning your pans, utensils and other tools for ready access. Everything in its optimal place. Preparing the mis en place is usually the most laborious and time consuming aspect of good cooking. After all, the majority of food products don’t take very long to actually cook. One of the most important things I learned from my very brief time studying with Jacques Pepin was that you have to think through your entire menu ahead of time and that this forethought should drive your mis en place. Thinking back to Julia Child’s classic cooking show The French Chef, as she moved from one recipe to the next, she would aways bring out a different full lunchroom tray of ingredients. This wasn’t done just because it was for tv, no, this was and is the right way to cook.

As my career path has moved me more towards a management and supervisory role and further away from day to day hands on programming, I’ve had to spend more time thinking about how to make my employees more effective at the tasks I used to do myself. I’ve often wondered why solutions to some programming problems would come easily to me but be so hard for others to come up with. Why did they so often get tangled and snarled in wickedly complex algorithms in lengthy pieces of code intended to do small tasks? It would be easy for me to get big(ger) headed and just attribute it to a difference in innate creative ability, but the teacher in me won’t accept that there isn’t something useful I can impart to them. So I started to think about whether or not there was any structure or process to the way I go about my problem solving in programming which is inherently different than what I see from others. That’s when it hit me- it’s mis en place.

Since we do a lot of stuff in the wonderfully easy scripting language called Python, it’s easy to get sucked into the bad habit of just diving right in and starting to write code without a plan of attack. Python makes it trivial to get something working in almost no time at all. This makes it too easy to just start approaching a problem in linear fashion, coding the first piece you need for the first piece of functionality and not thinking about the second piece until you’re done with the first. So what’s wrong with that? First of all, it’s like stepping into a kitchen and tossing a salad just because it’s the first course you intend to serve at dinner even though your rib roast will need hours more cooking time. In addition, it adds inefficiencies and you’ll often end up with either redundant, non-reusable or inflexible pieces of code. This would be analogous to chopping carrots for your appetizer, making your appetizer, then chopping some carrots for your entree, instead of preparing your mis en place by chopping all your carrots in one shot. As a simple example, imagine that the first step of a business process requires writing some user information to a database, and the second step requires querying information from that same database. Approached linearly, a bad programmer will choose to open a database cursor at the beginning of step 1, close it at the end of step 1, open another cursor at the start of step 2 and so on. But someone who is conscious of his mis en place would think thru the whole process just like a chef thinks through his menu. He would see that two different steps require a database cusor and would plan on being able to pass a single open db cursor as a parameter to both functions. That is of course a really dumb example but you get the idea.

Anybody who’s ever taken computer science has spent some considerable amount of time studying the concept of data structures. Well, in programming, the careful planning of our data structures is in fact the preparation of our mis en place. I’ve found this to be the single most important tangible thing I do to improve the quality and elegance of my ultimate solutions. Poor or inappropriate data structures can be overcome by brute force programming, but the results are so ugly you would never be able to, nor want to, reuse them. Instead, I always spend a teeny bit of extra time to properly plan the data structures, the containers that will hold the data elements, in order to make sure that they have the right layout and the right hooks. I try to make sure that every single data point has a place to reside and will be accessible in a way that is fast, easy, and efficient for the tasks at hand. What I end up with is a lovely array of sensible data structures from which I can pick, choose and assemble in any way that I need; like a big set of Lego pieces that I can assemble in any which way I’d like. Then, when it comes time to do the actual cooking so to speak, all I have to do is write the trivial pieces to insert the data into the data structures, and then code the algorithms for manipulating those puzzle pieces. It’s fast and easy since the mis en place has been done. And as an additional benefit, whenever a snag occurs in development, having to scrap bad algorithms no longer means having to start back at square one since you can just trash the algorithm while the data structures remain useful.

I know that there have been tons of books written on different software development concepts and I am woefully ignorant of most of them. I just don’t have the time nor the inclination to read them. But I do know this- many bad programmers can become better ones right away. All they have to do is think like a chef.