BattlefyBlogHistoryOpen menu
Close menuHistory

Learning how to learn by baking bread

Ronald ChenDecember 13th 2021

As Software Developers, we are always constantly learning and the journey is often awkward. I’ve noticed a few patterns when learning something new and how easy it is to get stuck. In this blog post, I’ll walk through the seemingly unrelated domain of learning how to make bread. I’ll describe some pitfalls and how to avoid them by learning how to learn.

Follow this tutorial

The first thing I did was find a simple bread-making video tutorial. It showed me all the ingredients I needed and step-by-step instructions. Seemed easy enough.

I gathered all the ingredients, followed all the steps, but the bread came out weird. I know what bread is supposed to be like, but it came out so strange I didn’t even have the vocabulary to describe what was wrong with it.

This is very typical with software development tutorials. The author thinks if they could just get the reader to follow their instructions exactly, they will be successful. But often it doesn’t turn out well and the student is often left frustrated.

Tutorials rot, instructions are unclear, adherence to the instructions is poor.

Maybe this tutorial is just bad, let me find another.

Adjust it perfectly

The next bread-making video I watched was also frustrating. At the point which it tells you to mix the water and flour, they say, “Add some more water if the dough is too dry”. Gee thanks. If only I knew what “too dry” looked like with my years of bread-making experience, oh wait I don’t.

While I meme, I don’t want to be hard on the people who are only trying to teach their craft to others. This happens when the teacher doesn’t appreciate just how much they know and how little their students know. Teachers have a difficult time forgetting what they know and students have a hard time knowing what they don’t know. Teachers have the curse of knowledge.

Teachers need to assess which level the student is at and adjust according. Go back to the basics if required. This is personalized one-on-one education, which isn’t cheap. The only way to get this form of education is by paying for a tutor/coach or finding a mentor willing to take you under their wing.

Students need to avoid hiding their ignorance. Ask “stupid questions”. The stupider the question, the more value you’ll get out of when answered well. Leave the ego at the door and slow down the teacher when you don’t get it.

Bread-making can’t be this hard. I know what to do! I have a friend who is really into bread-making! I’ll just ask them how to make bread.

Ask an enthusiast

Me: How do you make bread?

Enthusiast: Bread? It’s really quite simple. It’s just 4 ingredients, water, yeast, sugar and flour. But of course, you have to make sure you use good water. You have to make sure the water isn’t too hard or too soft. Oh yeah, and the yeast. There are a few options. You can make your own starter by mixing flour and water. I would recommend this as this gives you the best flavour. But since you are just starting, use the instant yeast packets. Oh yeah, but you gotta make sure to bloom the yeast to ensure it’s still alive.

Me: Wait, this sounds complicat-

Enthusiast: And you have to use the right sugar to bloom the yeast. Technically you could use any sugar, but trust me for the best flavour you need to use Manuka honey.

Me: I just want to make brea-

Enthusiast: Yes, but let me explain what flour you need to use, the hydration ratio. Oh yeah and the most important part, the oven and bake times!

…and so on.

The problem here is, enthusiasts don’t make good teachers. They are so deep into the nitty-gritty details they lose sight of the overall purpose. Enthusiasts care more about the process than the outcome.

This happens in software development with people who are more interested in producing clever code than solving the business problem at hand. When a refactoring project is poorly communicated, people are sus because they can’t tell if the desire is just to make an improvement to the code for its own sake, or if there is real business value behind the refactoring.

Are we doomed? I have found a better way to learn, but it isn’t easy.

Mechanisms and failure

Ultimately the learning material that taught me how to make bread successful came in two types.

  1. Mechanisms of individual parts of bread
  2. Forms of failed bread


I started learning how each part of bread-making worked. What is the purpose of each ingredient? What is the purpose of each instruction? How do the ingredients and instructions interact to form bread?

This took a long time as it was difficult to formulate the right question to Google. It was also a rabbit hole. Each ingredient/instruction had variations and it was difficult to know what was important.

Eventually, by seeing how many different people make bread patterns started to emerge. My mind started to connect the dots. Suddenly those original tutorials started to make sense on why they were laid out in the way they were. Those tutorials were attempting to hit the middle ground to maximize the probability of success for the general masses.


Learning about failure was also extremely valuable, especially after understanding the mechanisms.

Failure: dough didn’t rise. Did you forget the yeast? Is your yeast dead? Did you forget to add the sugar? Did you kill the yeast with water too hot? Are you using the right type of yeast?

Failure: bread came out too dense. Did you rise the dough? Did you develop enough gluten? Did you overdevelop the gluten? Did you underbake it? Did you whole wheat flour without adjusting the water ratio?

Failure: bread is still wet inside. Did you bake it to the right temperature? Did you let it rest? Did you use whole wheat flour instead of bread flour? Is the bread actually wet or just oily?

Learning about all these different forms of failure built up my vocabulary. Finally, I was able to express what was wrong with my bread. This didn’t give me the immediate answer on how to fix my bread but gave me possible mechanisms.

Failure is the ultimate form of feedback as one can then form a hypothesis on which mechanism can be used to fix it. Then you test the hypothesis by making a change. If this looks like the scientific method because it is.

Learning about failure allowed me to understand what people meant when they said, “Add some more water if the dough is too dry”. Ah-ha, dough that doesn’t rise could be related to dough that is too dense, which could be caused by it being too dry.

Applied to designing production systems

What learning mechanisms and failure applied to designing production system looks like the following:

  1. Learn about all the mechanisms by reading the documentation for every programming language, cloud system, third-party service and database in consideration. Pay special attention to concepts/architecture/overview sections as they allow one to form a mental model for the mechanisms.
  2. Find and read incident reports to learn about different forms of failure. Look for high-quality ones that perform root cause analysis and describe which mechanism they used to prevent future occurrences.
  3. Look at existing systems. What is the business problem being solved? How are the mechanisms used to solve the business problem? What forms of failures are being avoided? Don’t conflate business mechanisms/failure with technical mechanisms/failure. Carefully translate between the two.

Nothing wrong with being an enthusiast

As you learn about mechanisms and failure, you’ll quickly have the knowledge of an enthusiast. People will start noticing your knowledge and ask you questions. Make sure you understand the context of the question. Do they want to just learn more about the subject? Be an enthusiast. Do they have a special problem/goal they are trying to solve? Be a teacher.

Do you want to learn more software mechanisms and failure? You’re in luck, Battlefy is hiring.


Powered by