Prototypical Conference Talks

This is a work-in-progress. Your feedback is welcome in the comments, via email to jeff@jumpstartlab.com, or twitter.

This post is a part of a series of articles we’re working on for our SpeakerCorps project to recruit and support new speakers.

Delivering a great conference talk is hard. I’ve been thinking and talking with people about how to get more new voices into the conversation. In that pursuit, I’m working to document some of the things that experienced conference speakers know about the process. Last August, I wrote general guidelines about crafting a talk proposal. Now let’s explore the structure of a talk.

I’ve attended about 30 programming conferences and, in my experience, conference talks fall into one of a few prototypes. Understanding this forms can help you craft a great session and avoid some common pitfalls.

My Un-favorites

Here are the forms that are common and lead to my least favorite talks:

The Readme

Our friend Justin Searls at TestDouble says it best:

Dramatic README recitations need not apply. Talks that can be summarized as an ‘Intro to (Tool)’ are often lazily conceived, poorly designed, and delivered mechanically. Great talks, meanwhile, dive deeper and are eager to explore fundamental issues, even if they use a tool as the catalyst for discussion.

The reality is that these talks are usually better off as a README where we can actually install the tool and try it. If you find your slides include bundle install, you’re probably writing a README.

Listing New Features of X

Have you ever read someone else’s grocery list? That’s what this talk sounds like.

  • You know existing tool
  • Feature A that tool now has
  • Feature B that tool now has
  • Feature G that tool now has
  • Thank you, goodnight!

We’re not at a conference for an overview that could have come from the changelog. This talk form is lazy becuase it fails to weave a narrative. Why were these features added? Why were they added now / not there before?

When you read a list few will remember anything. When you tell a story most will remember the whole thing. Don’t waste the audience’s time.

What You’re Doing is Dumb

There are some complex ego issues when giving a talk. No one wants to see a speaker get up there and, in one form or another, say “I don’t know what I’m doing”. But where this talk form goes wrong is at the other extreme: “What all you people are doing is dumb, I’m here to open your eyes.”

Programmers are accustomed to a bit of bravado, but you can’t take it too far. One of the clear ways to go wrong is to talk bad about another project.

Open Source Software was written by people, and those people have feelings. If you need to deride another project to demonstrate how great the alternative is, that’s a weak argument. You can do better.

Imagine you have a big fan in the audience. Could they possibly come up to you after the talk and say “Damn, I wish I were as smart as you! Screw those other people!” If so, you might be falling into this trap.

The Library My Company Built That’s Better Than X Existing Library

A variation of the “What You’re Doing Is Dumb,” this prototype could also be called “My Team Is Smarter Than All the Other Teams.”

It might be the case that your team is dealing with Really Difficult Problems ®. It might be the case that the existing solution wasn’t a right fit.

But, guess what? That other tool probably has an existing community. It has maintainers, users, and contributors spread across different countries around the world. Your tool has a few people involved who have demonstrated interest for the last few months.

There’s a significant chance that your team loses interest or that your company folds up in the near future. In one swoop your tool’s “community” ends. Think the same could happen to that popular, distributed, community supported tool?

A conference isn’t the place to debut your thing. Sure, you want to build a community around the library. But that should happen well before a conference. Getting those first few contributors from the outside is really difficult. You’ve got to do that work ahead of time, get the premise and approach vetted by people outside your tiny circle, and establish it as a real thing.

Then come to a conference and tell us about how awesome it is.

The Successes

Great conference talks are great stories. They respect and engage the audience. Here are a few forms that typically go right:

The Hero’s Journey

I was once young and dumb. I faced a challenge and did what I thought was the right thing. I started observing the results, though, and I saw struggle and failure. I learned the hard way that my initial thinking was wrong and, based on this new evidence, I went down a new road. And it was awesome. And here’s the data to show how awesome it was.

Well executed, this talk works on two levels for the audience:

  1. They learn a new approach that could be used to solve a similar problem that pops up for them
  2. More importantly, they learn that hey, this is hard, and it’s ok to struggle. This person, who must be smart because they’re up there on the stage, makes mistakes. I make mistakes too, so we’re kind of similar. They conquered their problem, so maybe I can conquer mine.

That’s a powerful combo.

I Was Dumb and Learned the Hard Way

A variant on The Hero’s Journey, this structure goes:

  • I had a problem to solve
  • I ignored or discarded the accepted thinking/solution
  • I implemented a solution I thought was better
  • It turned out that building a solution was pretty hard
  • I learned more about why the existing thinking/solution is the way it is
  • I went back to the existing approach and succeeded

The takeaways here are pretty similar to the Hero’s Journey:

  1. That existing approach, despite a few rough edges, has a lot of value.
  2. It’s ok to admit that you went down the wrong path, back up, and make it right.

I Was In This Weird Situation/Language/Community. Here’s What You Should Know.

I love this approach because the central premise is “oh damn, other people are smart!” The programming world is a collection of micro-religions. Most of us stay too close to “our people,” but there’s so much interesting work going on out there.

However different a language, framework, or community seems on the surface, they’re solving the same problems we are. They are trying to build great code that works and grows. That’s bascially an impossible problem.

Find the points of similarity between the community you’re speaking to and the community you’re learning from. How do they solve similar problems? What’s possible in their language that’s not in yours? How does the performance in their implementation beat yours? Could yours be rebuilt?

Well delivered, this talk:

  1. Is a friendly call-to-arms. “Hey, we can do this!”
  2. Cuts down the idea that “those people not in our community are idiots” and instead promotes cross-pollination.

An Unusual Technique or Tool and How It Might Change Your Life

In my experience, most programmers play it safe. We stick to the 80% of our language and libraries that we know well. What’s in that 20%?

This talk form focuses on one of those features. The story goes something like…

  1. I was solving this problem that I’ve solved before using technique X
  2. I stumbled on technique Y
  3. I didn’t know how Y worked, so here’s what I did to learn about it
  4. I tried implementing Y and failed
  5. I learned more about Y
  6. I got it working, hooray!
  7. Afterwards, I can compare X and Y
  8. In the future, I’d first reach for (X|Y)

The audience takes away two lessons:

  1. Here’s one more technique for my toolkit if I need to solve a similar problem
  2. Most of us don’t know everything about our language and libraries. That’s ok, but we still have a responsibility to dig in deeper and touch those fringes.

That Thing You Take for Granted and How It Works

One of my favorite forms is the deep dive. This is what I might call the Pat Shaughnessy talk. It’s been a long time since I studied undergrad Computer Science, and I didn’t understand a lot of it the first time around.

This talk form pulls back the curtain on the thing we take for granted. You don’t have to be a C expert to dive into the MRI interpreter and learn about Arrays. You just have to be curious and determined. That’s what Pat does so well in his book.

But that’s only the tip of the iceberg. Modern applications are abstractions on top of abstractions. What’s really happening down there? The story goes like this:

  1. There’s this thing I use all the time
  2. One day, I ran into a weird situation
  3. I decided to learn more
  4. I dove in and was quickly lost
  5. I used X technique or tool to help guide me
  6. I started understanding the strucutres
  7. I figured out why it’s put together the way it is
  8. I found A, B, and C nuggets of awesome along the way
  9. Now when I use the tool I have a deeper understanding of what’s happening

The takeaways from this talk include:

  1. Diving under the hood isn’t that scary. Now you know a little more about one piece of the puzzle.
  2. The people who build these tools for us, those amazing core team members, are super-smart but they’re just people too. It’s great to build on top of their work, but it’s even better to dive in and appreciate their code itself.

Great Talks

Any subject can become a great talk, it’s the approach and the spirit that matter.

If you’re standing on the stage showing us how smart you are, tearing down others' work, the audience will walk out shrugging their shoulders.

Get up there and tell us a story. Show us how we’re all just people trying to figure out hard problems. Help the audience believe that they, too, can do great work. Give us technical details to discuss, debate, and investigate. But remember that the reason we’re here is to be people, together.

comments powered by Disqus
banner_sidebar

Upcoming Events

  • GoGaRuCo 2013

    GoGaRuCo 2013

    Mission Bay Conference Center

    September 20 & 21 - San Francisco, CA

  • RuPy 2013

    RuPy 2013

    October 11-14 - Budapest, Hungary

Contact Us

Twitter
@jumpstartlab
Github
jumpstartlab
Email
contact@jumpstartlab.com
Phone
(202) 670-2852
Fax
(202) 280–1257
Mail
1510 Blake Street
Denver, CO 80202 U.S.A

Stay Connected

Get the scoop on upcoming classes.