by Erin Dees
You’ve got a story inside that you’re burning to tell. I know because you’re reading this blog post.
Maybe you saved your customers lost data and heartache by stopping a nasty bug early. Or you found a new and better way to work together. Perhaps you want to teach a powerful new statistical technique to the world.
Whatever your story is, I want to hear it. We all do. That’s why we go to PNSQC, and it’s why I’m encouraging you to submit your idea as a talk proposal.
If you’re curious what it’s like to pitch and prepare a talk, here’s how my presentation came together for a PNSQC paper.
The Topic that Wouldn’t Let Go
A lot of my ideas for talks come either from things I’ve experienced or hallway conversations with other tech folks. Sometimes, it’s a combo of these places.
At a prior PNSQC, I was chatting with fellow attendees about the topic of code review. We all agreed we’d like to see a talk on the subject. The conversation soon moved to another subject, but the idea lingered in the background of my mind.
In a perfect world, someone else would pitch and deliver a presentation on the topic you’re most interested in, but sometimes that “someone else” is actually you. “Physician, heal thyself,” indeed.
During my time at New Relic, I learned a lot from fellow engineers about effective code review. In particular, the notion of reviewers having different roles — reading for correctness, maintainability, license compatibility, URL stability, etc. — was a revelation. These roles aren’t just informal; they’re an official, documented, and semi-automated part of the process. The result is a lightweight approach that scales well to larger code bases.
When the PNSQC 2017 call was announced, something clicked: People wanted to hear about code review, and I had learned a few things about it that might be new and useful to others.
What’s the Hook?
I had an idea for a topic, but not much else. What was the best way to show the value of this topic without overpromising on what I could deliver in a 35-minute (plus questions) talk?
Here are the main points I wanted to get across:
- The “room full of people” approach to code review doesn’t scale well to distributed teams or frequently-changed code bases (Too strict of a process isn’t scalable)
- If we don’t agree upfront about what and how to review, we bore reviewers and frustrate code authors (Too lax of a process isn’t humane)
- A “just enough process” approach will scale with us as our code base and our number of contributors increases
Wait, wasn’t “scaling software quality” the theme of 2017’s conference? Why, yes it was! We have a hook, my friends.
Your Abstract Has One Job
I’m a big believer in short talk proposals. Before attending a conference, I read dozens or hundreds of abstracts to know which talks to go see.
A nice, brisk abstract tells me the following things:
- What topics is this talk going to cover?
- Who is the talk for?
Even more important is the single biggest piece of information I’m looking for in your abstract:
- What am I going to be able to do after I see your talk that I couldn’t do before?
To connect the dots between my experiences and my audience’s needs, I need to connect some literal dots on a diagram; specifically, a mind map:
I spent a few minutes on this step, adding each thought as it popped into my head. Then, I rearranged the thoughts into related clusters. Some parts of the diagram would be helpful for writing the talk itself, but one part jumped out as immediately useful for writing my proposal. Check out that section in the upper-right corner!
Without It:
- Excessively formal reviews are time-consuming
- Ad hoc reviews don’t catch much
If the audience tries some new code review techniques, they could save time while still finding defects in the software. They could solve the problem of reviews being too lax or too strict.
Bingo! I was ready to write my abstract.
The Abstract
The words “code review” may conjure images of resentful or bored engineers occupying a conference room for hours. Or the phrase evokes last-minute, superficial discussions with a cubicle neighbor. Neither of these extremes is much fun, nor will they support you as your team and your code base grow.
In this talk, we’re going to use the asynchronous “pull request” model of code review as a starting point. We’ll discuss how to fine-tune this approach for just the right level of formality. We’ll also go over ways to scale code review with your organization.
In particular, you can automatically tag in reviewers with specific roles (e.g., experts in certain areas of the project), and use software to detect stylistic issues in your code (freeing the humans up for deeper review).
By the end of the talk, you’ll have a handful of techniques that can make your code review process more humane and scalable.
Ship It!
An abstract doesn’t have to be perfect, and it doesn’t have to get across every point from your talk. It just has to tell your audience what they’ll take away if they attend.
When you’re done with your talk, they will have brand-new knowledge and skills that they’ve never had before, and it’s all thanks to you.
We can’t wait to hear the burning idea you’re hoping to share with the world. When you’re ready, visit our Call for Proposals page and fill out the form.
If you’d like to chat with someone first, I’ll be around on Twitter.
Cheers!
