[Skip this part if you just want to read the article and not why I’m writing it]
The podcast This Developer’s Life is one I’ve enjoyed for some time now. It’s a great NPR-styled show that looks to investigate various facets of the developer’s interaction with the world. At the end of the most recent show on Faith (which I would suggest is about courage and not faith in a historical or religious sense) Scott Hanselman mentioned that suggestions for the show were welcome. On Twitter I suggested the topic of hobbies being impacted by the the developer’s mindset and mentioned that it really impacted my brewing and cooking. Since Twitter is public, Barry Forrest asked me to articulate my thoughts on this – and so I shall.
[OK, Start Here!]
Software development is very much about order, understanding, and taking complex ideas and breaking them down to their simplest parts. It’s also about being lazy where you can [See also: Perl]. So ideally you’ll take a complex idea, break it down into its component parts and then write code that executes that complex code in the least amount of lines with zero bugs. Ideally. Reality is that it can take a lot of code and there are usually at least a few bugs.
The thing that was so hard for me to begin wrestling with as a software developer was the complex to simple conversion process. The breaking things down to their bare components, and then breaking those components down to their raw concepts. This is done so that you can go from a sentence or paragraph describing a feature or idea in written language to a working piece of software that does the very thing that was described (and hopefully more).
I have written or helped write dozens of applications and thousands of features in the 15 years of my career. All of that was practice in craftsmanship, but as I grew as a developer I noticed that it was changing me. It was changing my thought processes so that when I looked at any of my hobbies (music, photography, cooking, and more recently brewing) they were a rich set of components that I knew as a collection of steps. Like classes that were called in order to write a played guitar piece, a coded photograph, a compiled dish, or an abstracted ale. I’m going to simplify this article by hammering out my thoughts on brewing as I think both Barry and Rob (involved in the Twitter discussion) brew.
The following ideas below may be out of order, they may have some assumed nuances, and they might need some clarifications. Throw me a message in the comments and I’ll do my best to fix or clarify things.
Knowing Your Problem/Goal/Recipe
Brewing beer is not just making a beverage. You’re not just trying to make something that can be consumed. You’re trying to craft either a clone recipe, another brewer’s recipe, or your own creation. You may be trying to improvise to learn ingredients, or you may be trying to hone in on an ideal you’re imagining, but haven’t brewed yet. As a software developer I aim to have a user story that clearly states the outcome I’m after. You don’t start coding until you know your goal.
You should not start brewing until you have a recipe (which is equivalent to a user story). It might be an experimental recipe [this is one of mine], but even still you have a goal. Your recipe helps set constraints and it helps you begin to set expectations.
Knowing Your Tools
Visual Studio, Eclipse, or Chrome Web Inspector are examples of tools that developers may lean on to help create better code, better programs, and have a good technique for debugging or understanding existing code. As a brewer you have a brewing setup that involves a kettle, heat and any number of other vessels for getting the sugars from barley (or other grains), hops, and water into a state that the yeast can eat. There are different techniques to brewing, but no matter what you’re doing – you need to understand the process and the tools involved.
I spent a lot of time investigating the processes available to me as a brewer before I started brewing. My brother – who taught me how to brew – showed me the brew in a bag, extract kit, and all-grain/sparge methods in 2 days so that I could see how simple it can be, and how complex it can be. I began reading heavily about what control I could have with the different techniques. How hard would it be to make mistakes and corrections with each one? What were the expenses with the different tools?
I started with brew in a bag because the tools required were fewer, the results were more controllable than an extract kit, and I could begin learning and experimenting through experience. It didn’t take long for me to jump to an all grain/sparge setup, but when I did that I had to re-learn the tools at my disposal. How did the vessels retain temperature? How easily could I transfer liquids between the kettle, cooler (mash tun), and the fermentation buckets?
If I knew the keyboard shortcuts to maximize my efficiency in various development tools, I sure as heck worked out the same sorts of efficiencies in my brewing. What configuration of my brewing equipment gave me faster transfers, better temperature control, and maximum extraction efficiency? I had to learn my tools. Consistency in results built trust in my tools. My tools produced better beers because I knew them.
Knowing Your Process
In building my recipes I take into consideration that I’m going to need to have water at various temperatures at different times. I’m going to need various grains (or sugars), one or more ounces of hops, and yeast. I’m going to add them at different times. I need to know when they are to be added, mixed, resting or whatever the step is. In programming I’ve found that doing the exact same steps in the exact same order with the exact same tools will give me the exact same results. OK, I’ll admit that isn’t always the case, but it’s within a margin of error. Home brewing is about honing in on those same results with the same process.
Testing the Outcome of Each Step
When brewing, and in coding, tests are there to inform you as to what’s going on in your code (or your brew). If you test for starches in the water you’ll know you don’t have the sugars you need for the wort. If you test for pre-boil gravity you’ll know you don’t have enough (or too much, or just right) sugars in the wort. If you test everything as you move through your brewing process you’ll be able to learn your equipment better, fix (some) mistakes, and hone in the desired outcome.
Teaching the User
Software usability matters. It matters in APIs, it matters in user interfaces, and it matters in the steps we present users. Users have been taught how to access and interact with software for decades now. Beer has been more accessible for much longer, however, many beer drinkers don’t have exposure to a diversity of beers and don’t understand many of the styles. Walking users through features of software should not be required, but documentation should exist. Describing appearance (color, head, carbonation level), flavors (malty, hoppy, bitter), aromas (grassy, piney, fruity, carmely), and textures (mouthfeel/viscosity) can really enhance the experience of the drinker of your beer. Talking or writing about what makes this beer special by style, history, brewing process or ingredient list gives consumers access to parts of the beer that they may not have previous exposure to.
On more than one occasion I’ve helped talk people through IPAs and they’ve developed a taste for them. I remember not liking the first 5 or so IPAs I had until I had an O’Dell Myrcenary. It was like switching from Windows to OS X. It felt weird until it felt right. I’m still learning to love lagers and Linux.
Software development taught to me think about the steps, the context, the history, the user’s needs and all (or many) of the ways a problem can be broken down and solved. It taught me about clean code. Brewing has become a parallel process that has steps, context, history and user needs. I’ve seen how recipes can be created with complexity and nearly identical beers produced with fewer ingredients or steps [all grain vs. extract, or adding in DME to help get your gravity higher without a bigger mash tun].
There’s a lot I’m still learning about the craft of software development, and there’s a lot I’m still learning about the craft of brewing – but they’re the same. Next time let’s talk about barbecue!
