Telling people about chef-runner

2 minute read

Last week I took the opportunity to give a talk about chef-runner at our Chef User Group Hamburg. The talk was well received. Some people even applauded and laughed at the right places, which I’m grateful for. My slides and corresponding sources are available online – go and check them out!

This blog post captures some of the pleasant things I noticed while preparing and delivering the talk.

Start with a problem

The talk’s title, “chef-runner - And the story behind it”, shows that my presentation was not only about the what and the how. I also tried my best to answer the question of why I’ve developed the tool in the first place.

Here’s the short version: In order to finish the Practicing Ruby cookbook in time for the accompanied article on infrastructure automation, I needed a tool that would allow me to move fast and break things. That tool eventually became chef-runner.

I really enjoyed putting together a story about chef-runner and – after overcoming my fear of public speaking, at least temporarily – telling it to an audience. According to Avdi Grimm, who regularly produces great content, starting out with a problem was exactly the right thing to do:

The biggest mistake most first-time presenters make is also the biggest mistake most screencasters make: burying the lede. "Today I'm going to show you the Frob tool. The Frob tool is a blah blah blah... now let's install the Frob tool. First, you'll need to blah blah blah..."

Cut all that. Start out with a problem. Tell a story. It doesn't have to be long. "This one time I wrote code that looked like this, and it sucked". That's a story.

Ask (different) questions

Another thing I noticed was that preparing the talk helped me to see the project from a different perspective. Taking a few steps back, I asked myself many questions like:

  • What are the interesting parts worth talking about and how do I connect the dots between them?
  • Am I solving the right problem? More generally, did I make the right decisions?
  • What is missing and where to go from here?

This thinking happens – as Zach Holman wrote so eloquently in a recent blog post – thanks to the nature of public speaking itself:

Building and delivering talks is very different from plopping down and coding all day. It's a different form of problem solving. It works a different part of the brain.

For me, it was only natural to reflect on my work by asking lots of questions. After all, I had to convey a concept to an audience full of strangers. The number of technical and non-technical insights I gained from that experience was surprising.

Do things, tell people

Do Things Tell People

I love this beautiful artwork by Busy Building Things both for its design and its message: It’s not enough to have great ideas and build things. To be successful, you also have to share your work with real people. You have to tell them about the things you’re passionate about!

Up until recently, I had mainly exposed my work through Twitter and blogging. Telling people about chef-runner was such a worthwhile experience – even though it stretched my comfort zone quite a bit – that I’m planning to do it again.

In fact, one of my personal goals for 2014 is to give five technical talks.

One down, four more to go!

Updated: