Element 84 Logo

The Bread and Butter of Software Development: Informing My Learning Through Professional Baking

11.15.2022

Like many other career changers during 2020, my day-to-day work has shifted pretty drastically over the past few years. Three years ago my morning ritual as a professional baker involved flipping over a milk crate to catch up with the day’s orders while I snacked on pretzels listening to Chaka Khan. Now, as a software developer, I swivel in my chair to face my computer screen to catch up with open issues…..while I snack on pretzels and listen to Chaka Khan. Jumping from my career as a baker into software engineering came with a lot of new challenges, but I was surprised by the similarities to baking and how working in kitchens gave me some skills to refine my learning process and start to contribute with a development team.

Wet Stuff On Dry Stuff

Flour binds, cocoa is acidic, mountains grow, empires fall, and in every dimension in which a bakery exists, so will a customer asking you to hand-pick the coconut out of a coconut custard pie. These are the fundamental truths of the universe. There are stabilizers and liquefiers and the order and timing in which they interact with each other determines the building blocks of your product. There are only so many ways you can work your way around these chemical reactions, so most of baking boils down to how creatively you can apply, in the less colorful words of my former boss, “wet stuff on dry stuff”. 

In software engineering the structure of an application is similarly dependent on two fundamental truths:

  1. How a program compiles and runs
  2. The business logic underpinning the application

My team taught me to build functionality and problem solve in the context of the business logic rather than catering to a library, framework, or outlier in data — dry stuff on wet stuff just doesn’t hold up. Similar to recipe development, once I began tasks by dividing up the constraints of the logic and language, I was better prepared to problem solve, flesh out any unknowns, and know how to creatively apply the tools at my disposal.

The Result Outweighs The Method

How to apply an application’s “wet stuff on dry stuff” was often unique across projects with different resources available—a familiar concept in food service. The building blocks of a macaron dough don’t change, but depending on the team, space, and budget it could mean you’re Ina blissfully folding almond flour into meringue while Jeffrey pops olives on the patio or you’re shoulder-deep in 30 quarts of meringue with “God’s spatula”, a glove that reaches to a baker’s shoulder so they can use their arm to fold.

I did my best un-learning between bakeries and similarly having a team that plans for elasticity has helped me to jump between projects and refine how I come up to speed. During my apprenticeship, this meant focusing on breakable toys that prioritized common fundamentals versus specific methods; having an onboarding buddy and mentor to help navigate team-specific processes; as well as having documentation and historical context for each project’s decisions, like descriptive pull requests and ADRs.

Mise En Place

Baking relies on timing and temperature, and, as a business where pennies matter, all actions become a battle against wasted time. Setting up “mise” is a baker’s greatest defense, and means to organize your immediate space so that all dependent ingredients and tools are prepped and within reach. The process allows you to create natural checkpoints at stable states to validate, clean your space, and quickly move on to the next task without losing focus or time.

When it comes to software engineering the practice of “mise en place” is not only an incredibly helpful mindset when breaking down the dependencies of a task, but also for better understanding how projects can be structured for collaboration. The best examples of mise in project development are employing templates and Scripts To Rule Them All in projects. These practices allow me to jump into tasks and know I have the correct dependencies, the ability to run tests, and format and lint my code so that I could focus on the task at hand and limit time waste for others on my team while I gained experience.

A spread of baking utensils is laid out on a counter with labels. A towel is labeled as "lint", bowls are labeled as "dependencies, and framework". Larger bowls are labeled as "data" and "business logic". There are also labels associated with "test", "format" and "deployment pipeline"
A simple application’s mise en place

Mise en place works best when it’s a means to accept and be malleable to fallibility (and the baker’s pressure, temperature, and fallibility graph is a solid positive slope) so altering my own mise as I gained more experience with what kind of mistakes I make was key, too. I found pair programming during my apprenticeship a valuable opportunity to refine this process. I was able to see how others set up their mise to predict common pitfalls, validate, and save time for themselves and apply those lessons towards my own environment.

It’s Not Real Until It’s Written

There aren’t a lot of opportunities to troubleshoot in baking; you either do it right or you do it again. For this reason, reliable resources that are explicit and don’t waste time and product are valued. A cup of dry-erase markers next to a wall of timers—or to write on the oven door itself—tends to mitigate any miscommunication on what’s going in and out of the oven, but standardizing practices across shifts and having some source of knowledge permanence in a high turnover industry is a little trickier. To solve this issue, every bakery I’ve worked with has a whiteboard, recipe binder and a bookshelf of resources. Any changes in inventory or processes aren’t real until they’re written down in their appropriate medium for others to clearly see.

An orange book with the title "Baking" by James Peterson
How messy the cover of the book on the bakery shelf is a good indicator of how useful of a resource it can be

Software engineering has been a more forgiving learning process. There is constant troubleshooting involved. However, writing clean and functional code is similarly dependent on how well I can communicate the problem I’m running into and knowing where to go for reliable resources to solve it. I now keep stream-of-consciousness-style notes as I develop so I have a reference of my own immediate history to form questions. My team prioritizes documenting discussions so I know where to go to gain context by pulling resources from most-direct to least-direct: a git blame, related PR’s with a helpful comment, or a slack thread on that same error or concept. Just like in baking, a team that encourages asking questions and documenting the learning process rather than just the solution makes troubleshooting easier, refines a project’s mise en place, and helps lift new team member anxiety.

My Takeaways

At the end of the day, it’s just pie; or napoleons; or whatever you’re making. The core of the baking industry is not the craft, but rather acts of service in relationship with a small community. Food service relies on synergy to be successful, and acknowledging those relationships and allowing for investment in them are well worth the effort. I wasn’t completely sure how my career change would go, but that synergy has carried over in my leap to software engineering. It’s been energizing to learn to problem solve and contribute to projects I’m proud of as a team and the mentorship I’ve received from everyone at Azavea has been—yes, sneaking in some bakery wordplay here—the cherry on top.

If you’re interested in learning more about how your skillset might fit in at Azavea, send us a message. We’re proud to support an environment of innovation and growth for our employees from all backgrounds. You can find more information about our hiring process and any open positions on our careers page.

Rachele Morino

Software Engineer