Nope! Not gonna happen.
Author Archives: Randy Peterman
Yessing and Knowing
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.
Vulnerable
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?
That One Subway Story
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.”
And
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.
Today is National Bacation Day!
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!!
Developing, Code and Context for Hobbies: Brewing
[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!
i declare today national drive to a town near you and buy a fun treat day!
Go learn something new somewhere new and have a new treat.
The Hair Cut Story
I went and got my hairs cut Saturday. I walked in, put my name on the list, and waited for a hair cutress. I don’t think that’s the job title that they prefer, but it seems appropriate this early in the morning. She asked me if I wanted my normal buzzcut, but that’s not what I got last time, so I told her I wanted to keep my part, but I just needed my hair shorter. As she turned to get tools out of her cabinet she asked, “So you want a comb over?”
What I heard was, “So you don’t want a comb over?” I thought she was joking because in my mind a comb over is for balding men hiding baldness. I’m a balding man embracing baldness. I’m not that bald, I’m also not that ‘thick’ up front any more.
So she began trimming and all was well until the clippers went zipping through major parts of the hair I thought my prescribed haircut needed. I was surprised, but I think I hid it pretty well. She finished and I paid and then called Jessica on the way out of the parking lot (on speaker phone, Trint) to let her know I did not get the haircut she was expecting. That way she could have time to prepare for this:
Ma Hairzes
Write a Screen Play, A Story, A Pterodactyl
Phteven
Have you ever wanted to write a screenplay? Me neither. But if you didn’t want to write a screenplay, have you ever wanted to write a story? How about a short story? Essay? A Tweet? A Haiku? Nothing? OK, this book is not for you.
I figure only a subset of humans want to tell stories that are fictional outside of the dog eating homework genre. But if you put your mind to becoming the next Stephen King, Steven King, or Phteven King, consider checking out the book Story (amazon link). I was listening to the Michael Hyatt podcast and he listed 10 books that were most influential to him and one of them was this book Story. Since I subscribe to Audible I thought I’d check it out eventually (I have an ever growing wishlist over there) and what I found most fascinating is that of all the books on Michael’s list, this one was less business oriented. Unless you’re in the business of telling stories, I guess.
The power of the book lies in how the author grabs onto the demands of a professional story teller and pushes them into the reality of the job. And then pushes some more to get them to hone their craft. And then pushes them some more to keep honing their craft. He made a statement that really got my attention [paraphrased because it’s an audiobook]:
The reason Hollywood is putting out the movies with the plots that it is putting out is because this is the best writing that they can find. They would love more and better writers.
Now, please don’t quote me on that, but that was the gist of the sentence that almost caused me to stop mid-run and post the quote to facebook. I believe this was a jarring first point in the book to begin digging into the craft of story telling in movies (and in part other forms of story telling).
After laying down his perspective so tersely the author leans in and pushes in towards how to fix this problem. Along the journey he points out other issues like audiences not being able to follow, authors wanting to add in irrational or unexplainable twists, and the need to write characters just the right way so that the writer doesn’t over build something that will become a distraction or leave the audience wondering why so much energy was put into someone so unimportant.
This book is a great introduction to thinking through fiction, thinking through your audience, and thinking through story quirks. If you find the analysis of stories, the analysis of the writing, and analysis of movies interesting, you definitely need to check this out. It’ll ruin every movie you’ll ever watch 😉