Learning in High-end kitchens

agile learning principes Aug 01, 2019

I’ve worked for some amazing software companies over the years, but I don’t think I really understood having a good daily routine and how to work well with others until I took a break and started cooking. I’ve worked for some very well known chefs in some pretty nice places and what I got out of those experiences is priceless.  Even though it was years ago, it left an impact that helps me every day.

Here are some learnings I’ve gleaned over the 21 years across two seemingly different industries, which I think is a good snack for a young software engineer getting started.

Be Organized. The first thing you do when you get into a kitchen is check your prep list to see what you are making for the day. Once you have a plan for how you are going to make all this food, you get your ingredients and tools set up to start prepping — you only have a few hours before you have to deploy your ingredients onto the plates. Having a plan every day and a list of things to do is always good in any industry.

Clean up periodically. Whenever you are finished chopping a bag of carrots, you don’t just move onto the onions. You stop, wipe down you cutting board and station, empty your trash, and check around you to see if you need to sweep up. Coding is no different. Remove old code you aren’t using, don’t just comment it out. Indent things properly, you don’t want your peers doing it for you.

Just say “Oui chef!” Sometimes you are asked to do something and maybe you don’t understand why in the world anyone would ask for such a thing. But by doing it, you learn why in the process. I sometimes ask people to do things without a reason. I always have one, but you might not understand why at the time.

There is more than one way to cook something right. When you braise meat, do you sear it first, last, or not at all? The answer is yes — it depends on what you are going for. How many people’s Moms meatloaf is the best? Well, ALL OF THEM. Same goes for design and code — where you put a control and how it works depends on your brand, device, user flow and data. There are so many ways to iterate thorough an array, but I would argue that while there are some wrong ways, there are many right ones.

Its’ (probably) been done. The chances of inventing anything new is 0.001%. People open hamburger restaurants all the time, but they aren’t “disrupting”. They are just making a good hamburger. In the restaurant business, there have been no more than a handful of people inventing anything new. Most of what we do as software developers and designers follow existing patters and experience of others. This should not take away from what you are doing and why you do what you do every day. Making things the best they can be is really the key. Look at all the “disruption” in the industry: Airbnb for matchbox cars, Uber for hamsters, etc. It’s not new. And it doesn’t matter. It’s still good.

Taste everything. Don’t assume its going to be right. Make sure it is. Ask for someone to give feedback if you aren’t sure. This is how you get good. Copying code from stack overflow or using a template you found on behance might not be 100% right for what you need. When you write code or design a screen, test it out. Give it to someone else to play with. Let people poke holes in it sooner rather than later (or in production). In the kitchen , not tasting your food could be disaster. Did someone accidentally mistake it for another component and add something wrong to it? did you add enough salt, sugar, pepper or fat to it? Sometimes you can’t tell just by looking at it, you have to actually put it in your mouth - or someone else’s. Make sure you test, and make sure you have someone else re-test.

Communicate often. Know whats about to get pushed to the client. When you are getting a product read y to ship, its not enough to just put your contributions in. You should be aware of what the rest of the team is up to and how each person’s work affects another. In a restaurant kitchen, a filet of fish takes, on average, 6 minutes to cook using in a sauce pan. If that fish is going with a 22oz ribeye, the fish cook and the meat cook had both better know when these things will be ready. Or you will have food sitting around waiting.

Cross train and respect. I always liked to work both kitchen and dining room, and get into the heads of the people working on both of these sides. The work is very different but everyone has the same goal : a successful dinner service. In the software world, the FOH (front of house ) are the marketing, sales and “business people”. In many cases, both the engineering side and the “business” side fail to understand one another, and this leads to a lack of respect in both directions. I think a good practice would be to let the engineering team listen in on a customer call with a difficult client. The FOH side could try coding a feature that they asked for to see how that goes.


Stay connected!

It's where I share all my best stuff about finding your superpowers and getting ahead at work. Sign up now for weekly updates:


50% Complete

Join the mailing list

Get this blog, and more, in your inbox.