"Mise en Place" for Front End Efficiency

It’s 2:30 pm on a Friday as I get off the bus in San Francisco’s Mission District. I get off at Mission and 16th because I like to walk past all the taquerias before work. I was a restaurant line cook, with a knife roll slung over my shoulder, a focused look on my face, and fast-walking while listening to my pre-work mix. I walk through the restaurant doors, greet the bartender bringing a cart of citrus and garnish to the bar in front, and read the reservations at the Host station. Busy night: a Private Event for 60 with passed apps, and a few six-tops (what restaurants call a “table for six”) reserved during the 7 and 8 o’clock hours. I change into a fresh uniform, have a menu meeting with the Chef, hear the plans for the private party’s passed apps (asking questions and pointing out repetition and adding ideas along the way), get assigned staff meal that night, and start prepping my station. I’m the first of the line cooks to arrive, the only other people in the kitchen are the Sous Chefs and the Prep & Dish Crew. I prep everything I need for the night for the next two hours. I readied myself to assemble any dish at any time of the night with the first rush of adrenaline coursing through my veins. Nightly success was assured by one thing: my mise en place.

When I started cooking I was told, ad nauseam, to begin with a plan and prep work. You set your tools and ingredients/assets where you can intuitively reach for them such that you can cook all night with your eyes closed. Mise en place, mise en place, mise en place. It means, “everything in its place.” The bowls you like, the spoons that feel right in your hand, and the right knife for slicing steak during service are all there. That meant the first big push in the kitchen was always prep. You prep everything you need for that service, including backups and emergency backups. So when I started coding projects, the concept of being prepped out was the bridge between industries that helped ground me. When I joined an Engineering team building its Design System, my heart skipped a beat! I was back to setting my mise and knew I could focus on writing performant logic after these components were done. A light bump of adrenaline from the component prep work puts a smile on my face.

A Design System is the creation of reusable components that match the branding and appearance the Designer has composed. It creates consistency throughout the entire project, which creates a cohesive product for the user. A Design System is also a collection of building blocks a Front End Engineer can reach for to drop a button in place, or text already in the company font and sizing without having to go back and restyle. This is a huge time saver for Engineers so we can focus on the business logic. For the Product and Design Team, it’s shared language with the Engineering Team to define what the users will see and “touch.”

As I created buttons, inputs, popups, and a Typography component for my team, I learned the consistency and discipline Designers need to have to stay on brand and make the UI feel intuitive. Sometimes, I would message my Designer to ask about what seems like an inconsistency in design conventions. At first, I was scared to upset them. However, I relearned the banter between an idea and the implementation. It was a lesson I learned in menu meetings with my Chef. It’s not always a dynamic of instruction to follow. In my career(s?) these chats are collaborations like Jazz musicians improvising the next line together helping each other shine on stage.

For years, I’ve read an organizational system and optimized it. I’ve taught cooks to “read the waves” like a surfer by looking at the books to see what is coming and checking the weather (it comes up more than you initially think in Food Service). When I join a new project, just as I would when stepping into another line cook’s station to assist, I look at how things are laid out. Does the file and organization structure make sense? How much repetition is there? How are the basic building block components set up? Are they extensible? Are there any one-off button variants floating around? I want to know where I need to reach for my Development ingredients. And this is just for UI. Then I’ll look to see what utils exist. How does the engineering team address time? A team I worked with even created a util file for time-related functions where it re-wrapped functions from another library. Why not just use the library itself? Because if the team decides to change libraries or dependencies there’s only one file to make the change. For anyone using moment.js in a project and needing to change over when the library stopped support, something like this would save you refactoring in multiple files.

Just as a chef carefully arranges ingredients before cooking, a successful Front End Developer plans meticulously before coding. The parallel between "mise en place" in the kitchen and in software development is striking: both prioritize clarity, efficiency, and readiness for any challenge. Embracing this philosophy has not only refined my technical skills but has also fostered a deeper appreciation for the art of building intuitive user interfaces. Whether I’m creating a Design System for consistency or optimizing utility functions for flexibility, the lessons of preparation and foresight learned in the kitchen continue to guide me. As I move forward in my career, I carry with me the belief that in coding, as in cooking, thoughtful preparation is the cornerstone of excellence.