Giving a conference talk is a professional goal of many programmers. Most conferences put out a public call for proposals (CFP) where you can submit an abstract of what you plan to talk about. With any luck, the committee will like what you wrote and you will be selected as a speaker!
So how do you write a good CFP submission and how can you increase your odds of getting a proposal accepted? There are some great articles out there already with advice on how to improve your proposal such as Sarah Mei’s What Your Conference Proposal is Missing or Noel Rappin’s What I Learned from Reading 429 Conference Proposals.
Unfortunately, there aren’t many good examples of CFP submissions out there. To remedy that, I am opening up all of my submissions, both accepted and rejected talks.
I’m also highlighting a few that are good examples of lessons I’ve learned about submitting a talk idea. While I can’t say for sure why a particular talk got accepted or rejected, I have noticed patterns over time.
Talk proposals generally consist of an abstract, which will become the blurb attendees see about your talk if it gets accepted, and some other fields that are only seen by the CFP committee and vary from one conference to another. I’ve linked to the full proposal for each talk. Additionally, I’ve quoted the abstract of those proposals that serve as examples for a particular lesson learned.
Tell a story
Rolling Random Romans
Dive into Elm’s random generators on a quest to build a historically accurate Roman random name generator for the goddess Juno, based on a series of dependent and independent constraints.
This talk was inspired by a personal project I had done that combined learning about Elm and ancient Roman history. I took the project and wrapped it with a narrative device that fit the theme. By telling a story, the talk becomes much more intriguing and memorable to both the committee and the audience at large than it would have been as a straightforward “explain random generators” talk.
Good topics get rejected
Real World JSON Decoding
The real world is messy and servers are no exception. The data we get is inconsistent, oddly-shaped, and sometimes flat-out wrong. Elm’s JSON decoders give us the tools to deal with all of these scenarios and more.
The world beyond the nicely contrived examples of decoding tutorials is riddled with challenges such as decoding union types, conditional decoding, and handling bad data. Join me as we attempt to decode data into something our Elm apps can work with in a series of real-world examples. Along the way, we’ll level up your JSON skills till you’re slinging decoders around that can convert anything the server wants to throw at you!
I liked this proposal and it addressed a real need in the community for practical content that goes beyond simple tutorials. I submitted it to Elm Europe 2018 (they chose another of my proposals), ElmConf 2018, and ElmConf 2019 but no one picked it up.
Sometimes you have a talk that you think is a great fit with a decent pitch and it won’t get picked. Don’t get discouraged. Even people who you see speaking a lot get many rejections. As you will see in the full list at the bottom of this article, a lot of my talks have been rejected.
Submit multiple proposals
Working with Maybe
One of the selling points of Elm is that you cannot get null errors. Maybe is what allows Elm to avoid this billion-dollar problem entirely. It’s a beautiful solution.
But it doesn’t take too long before your code is one long ugly nested case statement checking Maybes at every level. Surely this can’t be right. There must be a better way.
We have an array of tools at our disposal to solve this problem, from simple convenience functions all the way to eliminating Maybe altogether in favor of other constructs. Join me on a whirlwind tour of these solutions and take back control of your codebase.
Most conferences don’t limit you to a single proposal. If you have several ideas, submit them all! Don’t sacrifice quality for quantity but if you can have both, it increases your chances of getting accepted. I regularly submit 3-5 proposals to conferences.
Working with Maybe was the last of several talks I submitted to Elm Europe 2018, and it was selected. I added this proposal almost as an afterthought so this choice was unexpected for me. The talk turned out to be one of my best. Sometimes CFP committees will surprise you with what they pick! They know their needs and audience better than you do, so give them options.
Know your audience
Data vs Metadata
What do types like
MaybeandRemoteDatahave in common? They both augment some other value with contextual metadata (presence and request status respectively).Using this mental model, we will look at various ways we can design data structures that represent contextual metadata as well as strategies that can keep that information out of our core business functions. Has
Maybetaken over your codebase? Do you need to model a complex data synchronization problem? This talk will equip you with the mental model and tools to deal with these problems and more.
It’s important to do your research beforehand. What kinds of talks is a conference looking for? Are there any types of talks they are looking to avoid? It is possible to submit a great submission for a talk that a conference is just not interested in. It’s not that your idea is bad, just that you submitted it to the wrong audience.
Elm conferences tend to prefer talks that are on the more practical and concrete side of things. In Data vs Metadata I was excited to discuss a mental model that has been quite helpful for me. While I tried to give it a practical slant, it is still pretty theoretical.
I submitted it to ElmConf 2018 but it was rejected. If I were to try to submit this again to an Elm conference, I would probably try to invert things. Instead of discussing a big idea and giving some examples, I’d give a talk focused on a single problem such as that synchronizable data example and weave in this idea as part of the why the solution works.
Keep submitting
A Number by Any Other Name
In 1999 NASA’s Mars probe infamously crashed due to a unit of measure error. 20 years later we still write the same bug. Join me as we leverage Elm’s type system to catch these, get better errors, and improve readability. Along the way we’ll challenge some common assumptions we have around numbers.
Just because a conference rejects your talk doesn’t mean it is bad! Maybe they could only pick their top 10 out of 200 submissions and yours was number 11. Maybe they received many proposals similar to yours and are trying to have more variety. Maybe your idea doesn’t quite fit with their audience.
Don’t give up! It’s totally OK to submit your proposal to another conference, or even to the same conference next year. Don’t just copy/paste and mass-mail your idea to all the conferences though. Tweak your proposal to best fit what each conference is looking for.
A Number by Any Other Name was a talk I’d been wanting to give for quite a while. I shopped it around many times before it got picked up by Elm in the Spring 2019. I submitted it Elm Europe 2018 (they picked another of my proposals), ElmConf 2018, and ElmConf 2019. Persistance paid off here!
History
✅ = accepted, 🔁 = repeat submission
There are several rejected talks to RailsConf, RubyConf, and some regional Ruby conferences from before 2016 that are lost to the mists of time.
- ElmConf 2016
- Elm Europe 2017
- ElmConf 2017
- RailsConf 2018
- Elm Europe 2018
- ElmConf 2018
- Elm in the Spring 2019
- RailsConf 2019
- Elm Europe 2019
- ElmConf 2019