Happy CFP Season!

As of this writing, in the Ruby world, it is time to respond to a CFP! CFP stands for Call For Proposals. Conferences are looking for speakers, and they want to hear from you. The CFP for RubyConf and RubyConf Mini is open, and I hope you'll consider submitting.

To celebrate, I've published each of my accepted proposals. This is definitely not me procrastinating on writing new proposals. This post is a whimsical summary of things that worked for me that can help with your proposal.

Why am I only including accepted proposals? Well, first of all, because that's all I want to do. Secondly, I may decide to resubmit an updated version of a past proposal. I don't want to publicly identify myself.

Some review processes are anonymous. I'm sure every current and future Program Committee member reads all my posts (hi, everyone!). I wouldn't want everyone to have to recuse themselves because they already know who wrote it. How would it ever get accepted then?

Let's dig in to some thoughts you might consider in your proposal, using mine as an example.

Build your outline

There are differing opinions on how long your proposal should be. As you can tell from reading this, I tend to be verbose. I try to tamp it down, but, I've got to be me. Whether it's bullet points, sentences, or paragraphs, you need to define the scope of your topic.

What are the main points you want to cover? What will the audience take away from attending your session? The Program Committee needs to know in your proposal. The details section is where I provide this information. There's no need to keep any secrets or hold anything back. If there is something you want to have as a bit of a surprise to the audience, you can keep it out of the abstract. But if you know what your plan is, I recommend having it in your details section. I creatively titled this the "Outline" in my evaluating alternatives proposal.

This also helps you once the Program Committee accepts your proposal. Congratulations! Now you need to turn the proposal into a talk. Where do you start? Your outline gives you a starting point. You're not beholden to it. It might flow in a different order. You might cut sections, or combine them, or add new ones. But you're not starting from scratch. You already helped yourself out in the past with the outline.

Revisit conventions and norms

You don't need to invent a technology, principle, or methodology to have a conference talk. Sharing your experience with a well-known concept is a great contribution. I talked about the potential downsides of some of our favorite conventions in Don't Hang Me Out To DRY.

That doesn't mean that your perspective needs to be controversial or a "hot take". The number of first-time conference attendees is large! This may be the opportunity for early-career developers to learn these time-honored traditions we love, or love to hate.

Write what you know, or what you want to know

Where do proposal ideas come from? For me, they're not born out of a CFP being open. I have a private repository that I keep updated throughout the year with ideas for talks. Some of them may be a sentence. Some of them may be a title. Some may be a link to something I did, or read, and want to flesh out more.

Most of the time, my proposals are about things that I know. That's my comfort zone. That's what I did for Fake It While You Make It. I was on a project that dealt with a lot of third-party dependencies. I explored different options for testing our interactions with them. I felt comfortable sharing that with an audience. I felt that my experience could help someone else.

Proposals can also be about things that you want to know more about. If you have a lot of passion and interest in developing your skills in a certain area, it can be a forcing function. You don't need to be an expert to submit the proposal. You need to do enough work to be comfortable and confident in what you're proposing. You need to project that to the Program Committee. Forward-looking proposals can accelerate your learning. They can also be very enticing to the Program Committee looking for new ideas.

Go all-in with a theme

All my talks have some thematic grounding or some world that they live it. The talks from my proposals above were about food research for SPAM, onboarding for a new role at a "perfect" company, and building the latest in sweater weather detection technology. All those scenarios came to be after proposal acceptance. They aren't present in the proposal.

It doesn't have to be that way though. If you have a theme already picked out that you know the talk will focus on - lean into it. Make it clear in the proposal. Draw attention to it in the abstract. Spell out how you'll tie all your examples back to your theme in the details. I did that in the proposal for my coverage talk. It was always going to be about supporting a band on tour. There was no need to hide it - I couldn't do the talk any other way in my head.

As an aside, this is easily my favorite talk I've written to date. The theme definitely helped with that. I got to escape into that world for a bit, and somewhat avoid the real world in the Fall of 2020. (It wasn't the greatest, for a lot of reasons. If you're wondering why, you must be reading this from the far future. Consult your nearest history book.).

This talk was actually born out of my "Don't Hang Me Out To DRY" talk. I was procrastinating writing the actual talk. Instead I investigated how all these code coverage tools work. I needed to cut all that out from the talk because I didn't have enough time. But, because I keep a list of possible talk topics, I revisited it next year.

Given that it's a talk about live music, one day I want to to deliver this talk to a live, in-person audience.

Incorporate learnings from outside the community

Conference talks about "what x taught me about programming" may feel like an already-covered trope. I think the reason it comes up so much is because it works. We're all grounded in the community we share as developers. But our individual experiences are wider than that. Those different perspectives can have value to others in the community. I've been so bold as to suggest that a developer can learn a thing or two from a MBA program.

What have you done outside of development that we can incorporate into our practices? Whether it be theatre set design, famous bards, woodworking, or anything else, it can make for a compelling proposal topic.

Be honest about yourself

Proposals, and conference talks, should be a reflection of you. They should demonstrate what's interesting and exciting to you, in your voice. Make sure you have the conviction to follow through on anything in your proposal. Someone may suggest some feedback that you don't think you can deliver, or agree with. Even if it guarantees acceptance, I would be hard-pressed to make the change. While I ultimately find it rewarding, writing a talk after getting accepted is (for me) a lot of work. It'd be even harder to do if I wasn't bought into it.

My browser history confessional proposal started off as a joke or a dare to myself. "Wouldn't it be funny to get up on stage and tell the world all the things that I actually searched for to help me with my job?" I thought to myself. Then the Program Committee called my bluff, and accepted it. Thankfully, I bought into the idea. In developing the proposal, I uncovered a greater theme than the initial joke. If I wasn't willing to see it through to the stage, I couldn't have hit the Submit button.

Your Turn

When people ask me for resources about writing a proposal, I currently send them:

What can you share with everyone? What are you passionate about? What do you want to learn more about? Take all that energy and turn it into a proposal! I look forward to reading your abstract in the RubyConf 2022 program.

Sharing Past Conference Proposals