A couple of weeks ago, the !!Con organizers wrapped up the process of writing and sending feedback to people who’d had their talk proposals rejected this year and had asked us to explain the reasoning behind the rejection. Providing feedback took a long time. In our case, we rejected 185 talk proposals this year, and we were only asked to give feedback on twenty-one of those rejections — and it still took us two months to come up with feedback on the twenty-one proposals.
What took us so long? When we review talk proposals, we don’t actually write reviews; instead, each reviewer just assigns a letter grade from A to D to each proposal, and then, as a group, we consider every proposal that got at least one A. Reviewers may optionally add a few words of commentary to go along with their grade, but there isn’t really any written material that comes out of the review process that is suitable for sharing with the author of the proposal. So, coming up with helpful feedback in a format that we can share with authors takes some time and effort. Add that to the fact that we have to reject a lot of quite good proposals for space reasons, and the fact that many reviewers disagree on proposals, and writing feedback becomes especially hard. It’s understandable that many conferences don’t offer individual feedback on rejections at all.
Anyway, I’m writing this post because, in the process of writing the feedback for the twenty-one rejected proposals, a few patterns emerged in the kinds of feedback we were writing. I want to share a few failure modes of !!Con talk proposals, in the hope that someone will find it helpful when they’re writing talk proposals for this kind of conference in the future. (Keep in mind that the advice in this post is pretty !!Con-specific; it may not be helpful for submitting talk proposals to other conferences, and in fact, it may be harmful!)
The “Tour of My Favorite Programming Language” talk proposal
Each year at !!Con, we get a number of proposals for talks that would introduce the audience to the speaker’s favorite programming language, library, framework, debugging or profiling tool, networking protocol, or what have you. These talks sometimes get accepted, but it’s more common for them to get a slate of B and C grades from the reviewers and subsequently be rejected. Why?
Since !!Con talks are only ten minutes long, it’s hard to fit a complete tour of a library, language, tool, protocol, or what have you into the allotted time. The talk is likely to end up being a superficial list of features, with no time to explore any of them in depth. It can also be hard to motivate the talk to audience members who aren’t sure what use the tool is going to be for them.
One way to make this kind of talk work in the setting of !!Con is to focus the talk around one specific feature of the library, language, framework or tool that the speaker found especially interesting, and then use that one feature as a hook that will draw people in to explore more on their own. Another option is to tell a story about building something specific with the tool — especially if it involves using the tool in an unexpected and exciting way.
The “Timeline? What timeline?” talk proposal
On our talk proposal submission form, in addition to an abstract, we ask prospective speakers to provide a brief timeline explaining how they plan to use their ten minutes of stage time. This helps us make sure that the speaker understands the lightning talk format, and that they’ve put some thought into making sure that their talk will fit into the allotted time.
Every year, there are a few talk proposals that get rejected due to a failure to provide a timeline. Some people even copy-paste the abstract into the timeline field on the form! Others provide a timeline that’s too superficial to tell us much. If you want some examples of what a good timeline looks like, I wrote a whole post last year about that!
Timelines aren’t legally binding agreements. We expect that most speakers will rearrange things a little, or even a lot, between when the talk proposal is due and when the talk actually happens. The important thing is that the speaker is aware of the time constraints and has come up with some kind of a plausible-sounding plan for their talk.
The “this talk will make you a better programmer!” talk proposal
We get a lot of talk proposals that purport to show the audience how to achieve a practical goal — get more done! produce more maintainable code! ship a product! — or that purport to teach a specific programming skill or a way of thinking about programmimg. These kinds of talks work well at many conferences, but we find that they don’t tend to work so well at !!Con. Successful talks at !!Con tend to be those that tell a compelling and engaging story of a project (like the story of how Lisa Ballard and Ariel Waldman built spaceprob.es using an undocumented NASA API!), or share an interesting concept for its own sake (like locality-sensitive hashing!).
When I see a talk proposal that promises, “You’ll learn how to do X from this talk!”, I suspect that the author doesn’t understand the !!Con aesthetic. For the most part, people don’t tend to come to !!Con to learn practical skills. Rather, they’re there to have fun and reignite their excitement and curiosity about computing. This doesn’t mean that people don’t learn things from talks at !!Con — to the contrary! — but it’s a question of how the talk is framed. Since our talks are only ten minutes long, there’s not really time to teach a skill in any depth, so the goal is instead to excite and inspire people, which will then motivate them to go out and devote more time to learning on their own.
My good friend Will Byrd, a great teacher, brought this philosophy to his teaching practice when we worked together on a course several years ago. Will’s view was that it took many years to become an expert on a topic, and there was no way that a semester-long course would be enough time for students to develop expertise starting from scratch. So, instead of trying to develop expertise in students, his foremost goal as a teacher was to get students really excited about the topic at hand — to light a fire under them that would fuel them for a lifetime of learning, long after the course was over.
Some !!Con talks (like Bomani McClendon’s great talk about building giant animatronic glowing mushrooms) do include “lessons learned” and high-level takeaways, but these talks are effective because they frame those high-level takeaways in the context of a specific project or a specific area of inquiry. One of the high-level themes of Bomani’s talk, for instance, was how he came to see himself as an artist by working on software for an art project, and how that can be a fruitful way of looking at ourselves. But if the proposed title of his talk had been “Software as a medium for art!” or “Start thinking of yourself as an artist!” rather than “Making Mushrooms Glow!”, it wouldn’t have been as strong of a talk proposal. This difference in framing can be subtle, but the good news is that if you submitted a talk proposal of the “this talk will make you a better programmer!” variety and it was rejected, it might not take much to reframe it as a talk proposal that would be a great fit for !!Con. Consider revising and resubmitting it this year!
The “everyone at this conference shares my background, goals, and motivations — right?” talk proposal
!!Con attendees and speakers come from a wide variety of backgrounds. Maybe they design games, build smart watches, study geometry, or develop interplanetary spacecraft flight software. A given audience member may or may not know much about any of these topics, but even talks on very narrowly specialized topics can have something to offer to both specialists and non-specialists, if the presentation is done right. (The lightning talk format helps: in our experience, just about anything can be interesting for ten minutes.)
So, narrowly focused talks are great. The problem arises when speakers assume that the whole audience already has the background for a narrowly focused talk. We get a lot of talk proposals that aren’t a good fit for !!Con because they assume background that not everyone has, or goals that not everyone has. The difference between a talk proposal that focuses on a particular specialized topic (which is good), and one that does so and assumes that everyone in the audience does, too (which is bad) can, again, be subtle. Removing the assumptions about background and goals from a talk proposal could be as simple as changing a sentence like “We all want the web apps we build to work well on mobile!” to “I wanted the web app I was building to work well on mobile!”
The “OMG, can you believe that $topic and computing are related?! Who knew?!” talk proposal
Come on — this is !!Con. We already know that computing can be related to everything, and that everything can be related to computing. Don’t insult
The “didn’t we have this talk last year?” talk proposal
Once in a while, we get a talk proposal submission that would be great if not for its (presumably coincidental) close similarity to a talk that already appeared at a past !!Con. We do our best not to repeat topics if we can avoid it (or, if we ever did have a repeat, we’d probably try to wait several years in between), so, sadly, that means turning these talk proposals down. Talk proposals that fall into this category are strong candidates for submitting to other conferences.