As a relatively new industry, we're not averse to borrowing terms from some of our more established role models. Many of these come from construction: we use terms like 'architecture', 'building' and 'plumbing'. I'd like to suggest we borrow some terminology to an even older profession.

In the culinary world, 'mise-en-place' borders on an obsession. It traditionally refers to the preparation before cooking begins. With vegetables chopped, meats cut and spices measured out, the chef can focus on making the dish taste great when it comes to services. Some chefs think of it more like a state of mind than a process, incorporating all manner of preparation and workflow boosters.

It's a metaphor that has helped me in software development. It's equally useful when applied day-to-day development as to starting a new project. Here are six ways to apply mise-en-place to software development.

---

Build a walking skeleton

A walking skeleton is a minimal implementation of the entire system than can perform an end-to-end function. Think of it like a 'Hello, world', integrating all dependencies, frameworks, and services.

This can be a slow and painful part of a project. It might involve reading documentation and trying to force square pegs in round holes.

You are unlikely to find 'flow' in integrating different technologies, so it's best to have something working from the outset.

Learn your tools

Take the time to actively learn your tools. Learn the keyboard shortcuts. Learn the debug cycle. Customise them to behave how you want.

In the heat of the moment, when you're debugging a gnarly one, you want your tools to be an extension of you.

Script and automate

You're working through the same problem again. You hear that nagging voice in your head telling you that you should have scripted it. Now's not the time, though, you're busy. It will take too long to script it.

Try to anticipate that voice and script any workflow that you might need: build cycles, debug cycles, installation, formatting, release, deployment.

Draw diagrams

Sometimes just thinking about drawing a diagram can be enough to trigger interesting design questions. I'll be wrestling with a problem and I go to draw a diagram. It usually starts with a generic, meaningless, labelled box in the centre of the page.

It's at this point I start asking myself questions. Wait... what type of diagram am I about to draw here? What is it I'm trying to model? Is it different states? Is it behaviours? Is it a sequence of events?

Sometimes these questions are enough to get a better idea about what I'm about to develop.

Prepare for distractions

Distractions, although frustrating, are the reason we work together. They are when we learn and how we share ideas.

The best you can do isn't to avoid distractions but prepare for them. If you sense there might be an uninterrupted moment, take the opportunity to work on work that needs more concentration.

Write checklists

Checklists aren't new or revolutionary (well...) The act of writing out a simple checklist before starting on a task can be a great way to uncover the complexity. It might be a list of files you need to modify. It might be a list of tests you need to write.

Whatever it is, it can help you switch into a preparation mindset that might map out the road ahead.

---

Cover photo by Katie Smith on Unsplash

Also posted on Medium