It’s father’s day. And that means my brain goes to Cake Wrecks which had a series of cakes for father’s day that included an epic cake spelling “error.” I can only tell you that today (technically the day before Father’s day) my daughter Abby presented me with this:
She’s not wrong.
The phrase, “Thinking God’s Thoughts After Him, ” used to drive me bonkers. I wanted to be a free thinker after God’s image. The problem with my optimistic free thinking lies in the source of truth: not me. Good is the source of truth and if I’m to think on truth in going to have to be thinking about His revealed truth after Him.
I consider myself creative as my art and craft often reflect new-to-me experiences, but I’m also highly analytical and yet the truth I find is rooted in exploring God’s creativitt, His truth and then exploring creatively potential appropriations and then subjecting those to analytical comparison of God’s revelation and His approved appropriations as revelation preserves.
God’s Thoughts are perfect. They’re worthy of meditation. They’re worthy of thinking after Him.
Nope! Not gonna happen.
I keep seeing or reading quotes and articles about saying yes to more things for experience and saying no to more things for time management. This balance is crazy hard because you can’t say yes to everything and not become overwhelmed, but you can’t say no to everything or else life gets very boring 🙂
There’s actually something powerful about combining the two so that you say yes to only the experiences and opportunities that will truly add value. Then you’ll know when. To say yes and know when to say no. It’s a longer term perspective thing.
I’m Mr. TMI (too much information). It’s my defense mechanism. You see shame loses its power when you speak about something that might be embarrassing. The cat’s out of the bag. I’ve never been very popular and often growing up in public school I was ridiculed for various things: my faith, my hobbies, my idiosyncrasies, my love of music (I wasn’t a jock). So I over shared and over – informed so that I could reduce the fact that someone else would shine light on my ‘weirdness.’ I’ll just put it out there in the open.
All that to say when my friend Dave O’Hara told me about the book Daring Greatly the topic resonated with me. Vulnerability is a powerful tool for intimacy between people, but shame keeps us from committing to true vulberability. It turns out people use one of (at least) two techniques to handle the shame issue, both of which may hinder intimacy through vulnerability. One way is to over shared (like me), the other way is to strive for perfection. Perfection has no shame – except that no one is truly perfect and no one is going to escape from the shame of their eventual imperfection.
I’m learning a lot about vulnerability and shame as I read the book, but I’m finding that I am guessing the next chapter or point because the implications of these topics in the research is very, very real to me.
I want to be vulnerable and intimate with others, but I need to do that in a healthy way. I want to put shame away in my relationships. I want to rise up to the challenge of healthy intimacy. It’s a great place to be at nearly 38. I haven’t been here before.
Where are you growing?
Some time ago – back when I lived in Texas – I had food allergies and was allergic to wheat. One day my co-workers decided that we should go to Subway for lunch and I went along. When we got there I saw their sign advertising that they’d turn any sandwich into a salad. I really like philly cheesesteak, so I decided that ordering that cheesy goodness on a salad was worth the awkwardness. Once the salad was paid for I sat down and chuckled to myself. My co-worker Blader asked what I was laughing about and I told him that if I came back I’d order the meatball sub because that would be ridiculous. We laughed and moved onto other conversation.
The next day someone asked, “Where do you want to go to lunch?,” and Blader quickly answered, “Let’s go to Subway. Randy needs to order the meatball salad.” So we went. As I approached the counter I said, “This is going to sound weird but I’d like to order the meatball sub as a salad.” The guy didn’t skip a beat when he replied, “That’s OK, yesterday some person ordered a philly cheesesteak as a salad.”
The scriptures are hard because of the and. Be gracious and forgiving and kind and loving. And righteous. The polarization within Christendom is often due to the and where readers have blindly sought the or.
I died to the Law because I was identified with Christ. Grace is my motivator (grace is not merely the forgiveness of sins, it is blessing beyond that), but the life of Christ is to be lived out in me. But that life is done through rest and relationship, not through rigidity or legalism.
The standard for love and righteousness come from the same God. This means that instead of my getting to “or”, I get to “and.” This is a powerful truth that demands I step aside with my attitude and self importance and I get to be a model of submissive grace, serving righteousness, and compassionate listening.
Bacation, is a vacation with lots of bacon! Make today your national Bacation day! Thanks to my friend Joe for sharing this holiday with us!
From Joe:
Took the day off to hang with the folks who came into town this weekend and in simple celebratory discussion with my bro, we decided to coin the weekend “bacation”. One part bacon, two parts vacation! You can do it too, simply add bacon to any celebratory meal and wah-la “bacation” is born!!
[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.
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.
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.
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.
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.
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!