What I Learned About Software Development From Cooking

I was raised cooking and my love for the craft hasn’t diminished a single bit over the years. Every day I experiment new recipes, unravel the reasons of why a given technique works, and discover new ingredients. From playing with different types of salt to obsessing with how different types of wheat affect the pasta I make, my need for knowing more is an essential part of my life.

Cooking is not my only passion though. While I was on high school, I discovered programming. Unlike cooking, developing software grew on me over time. At first, it was just a medium to express my interests about other topics. Now, it’s become the source of my aspirations and the canvas where I’ve drawn my professional career. It’s an unending source of challenges, but also, experiences that make me proud.

After thinking about my inclinations for some time, it makes sense for me to fall in love with these seemingly unrelated activities. I didn’t have to look far to find the similarities. Both are quite structured yet they allow a lot of freedom to creativity. They are intrinsically social activities, demanding constant feedback, and evolving only through the exchange of ideas among people and cultures. The pace of change in both areas is breathtaking with exciting innovations emerging every day.

One of the most recurrent thoughts I see in cooking classes is the importance of paying attention. Even though preparing a meal tends to be a recipe-guided process, cooking is far from a predictable endeavor. The environment and the ingredients you use will vary depending on your location and season of the year. For example, the temperature of the kitchen and the PH of the water will determine how a bread’s dough will rise and there are several varieties of tomatoes depending on which part of the world you live.

Software development is full of recipes too. Some of them are focused on solving common design problems. Others, in organizing development processes, like how teams are structured or how code is delivered to final users. As many developers, sometimes I become religious about following every step described in such recipes. The problem wsith being so devout to these procedures is that, in the same way as cooking, developing software is a complex process influenced by intricate human interactions and dynamic requirements.

In cooking, paying attention manifests in always tasting the food, checking the level of doneness of a steak, or being very careful while rolling out fresh pasta. In software, it does in listening everyone involved carefully and empathically, validating if the current development process adapts to the size of the company, monitoring how a design performs in the real world, etc.

It may seem obvious but it took me some time to understand that models are not reality. There’s such a soothing comfort in the idea that following an exact set of steps will lead you to a desire outcome. I’ve always been a big fan of models and in my mind, absorbing all this knowledge and translating it to a project would lead to success. It didn’t. Farman Street conveys this idea gracefully in the map is not the territory:

The map of reality is not reality. Even the best maps are imperfect. That’s because they are reductions of what they represent. If a map were to represent the territory with perfect fidelity, it would no longer be a reduction and thus would no longer be useful to us.

Software models and cooking recipes were created as a medium where people could share their interpretations of a given reality. They are useful because such interpretations may include a successful approach to solve a problem in that context. We have to consider though that our actual context is composed not only by the problem described in the model but by many others at the same time. I learned that I can’t take advantage of all the knowledge accumulated in these models if I don’t pay enough attention to my own reality.