When I was beginning to code, I could read and write it, but I couldn’t express myself in it. Forget about making cool generative art or videogames that I liked—I simply couldn’t even figure out what I was doing. I felt boxed in by the code I was writing. I was painting by numbers. Code simply wasn’t a creative medium for me. I thought of code as perfunctory: I was to code for a specific purpose and if the code didn’t serve that purpose then I didn’t succeed. The language of code constantly felt like it was pushing me away. I needed to change, especially since I planned on doing more code.
That change came from the least expected place: my bread baking hobby. I have been baking for ten years and have a long sense of the craft. It is so deeply embodied in me that I often freestyle my loaves these days, without recipe nor measurement. I simply intuit how the loaf should be based on how I feel. I wanted to feel that level of control and expression in my code: I wanted the control that kneading a dough empowered me to feel. And so one day, I began to approach code as if I were making a loaf of bread. And I haven’t looked back since.
It certainly helped that I needed code for my degree in Design and Technology.
What I will share with you here are the three big lessons that I learned from approaching my code as bread. These tips help me every time I sit down to code. They make the work more approachable, manageable, and to put it simply, possible in the first place. I hope they offer some new ways to think about code.
Lesson 1: It’s still bread!
Bread baking is a success-only practice. Similar to how Edison said he learned 7o0 ways how not to make a light bulb.
The same is true in bread, except in bread making, I still get to make bread. I can’t fail. I literally always succeed in varying degrees. Failed homemade bread is still homemade bread and still better than many kinds of bread you might buy. It is “still bread.” And it’s certainly more edible than a failed lightbulb.
When bread doesn’t turn out the way I want, I have to make adjustments. I learn to understand it better. And that’s always a win. Practically speaking, in bread, I am always making small tweaks here and there to make the end result turn out the way I want. More flour here, less salt there, higher temperatures there, maybe a proportion is off by a percent. When bread turns out unexpected, my efforts lead me to making that discovery about how the bread should be expressed. Bread doesn’t fail: I simply learn new expressions.
Coding like a baker means accepting this truth in code too. Error messages in programming insist that there is some code that is bad or wrong. That what I write is somehow broken, and perhaps it is in some ways, but I ignore that. Every line and letter I put into code is a success because each is an expression of myself. Vitally, this let me separate the end product from the dedication to the practice of code. As a bread maker, I am engaged in making bread, and so as a coder, I am dedicated to writing code. For however long I am able to write the code, I will be successful in coding. An error message does not erase my labors.
Lesson 2: Like bread, code is alive
Bread always succeeds because the living yeast are responsible for most of the work.
The little organisms inside of the mix, with enough time, transform the ingredients into dough that makes bread. Yeast naturally consume the starches and transform the flour into a gluten-y mixture full of flavor. This takes time and care, but it is actually a natural process. When the flour, water, salt, and yeast come into contact, the yeast and other organisms get to work making bread. Yeast is a living thing that grows and evolves in bread. Transforming dough is what they are meant to do and they are far more responsible for the quality of the bread than I am.
My role, then, is to guide the process. I make sure that the temperature and texture is right, I jostle them around to make sure things are in the right balance, I make those aforementioned adjustments. It’s a “co-design” process. I don’t do it myself, I am working with a thing that is alive with intention. I make bread with the yeast.
In programming languages, there are no micro-organisms . Yet I have still found this co-design perspective invaluable. Code and languages are not driven by a chemical chain reaction. However, that does not mean that code is without intentions. Like yeast, code is filled with them.
Alive with ideas and never broken, we can understand that code is always working. Even when it says that it isn’t. All those errors and exceptions, the things that keep us up at the computer, are the code talking back to us about our work. They are evidence of the life bubbling up underneath, hinting to us how we should adjust. When code is alive, learning to listen to how the code speaks enables us to move forward.
Lesson 3: You aren’t alone
More than the yeast accompanies me when I bake. The bakers that came before me guide my hands, creating techniques that enable me to make the bread in front of me, and eventually, I pass my own ideas and techniques I found to the next bakers to come. It’s a cultural practice which means I connect to the culture through it. These bakers of past and future are embodied in my baking.
Knowing that there is a longstanding cultural practice of baking is a reassurance that I don’t have to work alone in my craft. The problems I face are shared among many who have come before me. Because, fundamentally, no one isinventing “new” bread. What we do is make bread in new ways. So while the challenge of making bread is the same as it has ever been, the context where I bake is not the same as a French person from years ago. Their work and approach may be useful to me today if I accept their context was different and adapt it. And that adaptation is the work of the baker: facing the challenge of making bread today. This was the most vital change in how I view code–not as a means of making software programs but as a cultural practice of creating in code.
The code I am tasked to write is not new. The refrain that everything has been done before becomes our advantage. This means I draw upon old solutions and adjust them as I might do bread for today.
One of the most common challenges in videogame programming is collision handling. Is something on top of another thing? Is my mouse cursor aligned on the button? Is my target in position? This is a very common question that has been tackled by many before me. There are whole libraries designed to handle this topic, but frequently I find myself needing a custom solution. My role is not to conjure up an entirely new set of solutions, but to build one adapted for my needs. I research the solutions available to me and synthesize my own. It makes sense that I would draw on the past and other people’s code for myself. A common problem means that I have common solutions.
My code is inspired by coders of the past and implemented in the present to handle my version of the problem. My practice of code is added back in, becoming a past solution for some other coder in the future.
I am never coding alone. The full history of code is at my back, waiting to be explored.
These lessons come from the positive experience I had in joining the bread making community. The culture of the bread making craft is defined by the literal practices of eating, producing, and talking about bread. We are united by the ways we approach the challenge, in shared inquiry to create a delicious loaf of bread. Our efforts toward the shared goal defines our community.
What then, is the shared goal of the coding community? Is it to make software products? Generative art? I think it is simpler than that. The shared goal is merely the challenge of expressing ourselves to a computer.
The world of code is filled with people trying to translate their ideas into databases, executables, functions, variables, and even whole computing languages. Their labors toward that goal create space for community discussion. By sharing in their practices, community is embodied and reinforced.
Through sharing my lessons, I hope to add to the available practices of code. I was put off by the computer science & software product approach to code. I rejected it and found my bread-inspired method as a response. By applying my own personal experience to code, I found my method that enables me to integrate the history and culture of coding. This is now here for you to try as well as a mindset.
Beyond sharing my own lessons and perspectives in code, I hope this discussion activates you to start thinking about the idea of coding in new ways. While it is generative for me to think about code as bread, the empowerment I feel is testimony of the need for other approaches.
If you were at all like me, put off by the styles of code that feel inescapable, perhaps you will take a liking to my bread-inspired approach. Or maybe you will bring your own perspective and create a style of your own. You new coders will lead the discovery of your own code and your own craft in the community of code.
Just make sure to share.
A computational designer and theorist living between bread and code.