composition.al

Some reasons why your talk might have been rejected from !!Con

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 $library/$language/$tool” 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, or what have you. These talks tend to get a slate of B and C grades from the reviewers and are subsequently rejected. Why?

Since !!Con talks are only ten minutes long, it’s hard to fit a complete tour of $library/$language/$tool/whatever into the allotted time. Such a talk is at risk of ending 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 $library/$language/$tool is going to be for them.

One way to make this kind of talk work in the !!Con setting is to focus the talk around a particular feature of the library, language, framework or tool that the speaker found especially fun and surprising. Another option is to tell a story about building something specific with the library, language, framework, or tool — especially if it involves using the tool in an unexpected and exciting way. This kinds of talk might also work better at a conference with longer talk slots.

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’re going 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.

A good way to get your talk proposal rejected at !!Con is to fail to provide a timeline at all. Believe it or not, this happens — we sometimes get talk proposals where the “timeline” field is filled in with more prose written in the same style as the abstract, and providing no information on how much time will be spent on the various parts of the talk.

Then there are so-called “timelines” that look more or less like this:

  • Introduction (1 min)
  • Main content of talk (8 min)
  • Conclusion (1 min)

That’s another good way to get rejected. A good timeline offers enough detail to give us a sense that the speaker is comfortable with their topic and has a plan for how to proceed. As an example of a well-done timeline, here’s the timeline that Tara Vancil submitted as part of her proposal for the talk “How Merkle trees enable the decentralied Web!”, which appeared at !!Con this year (shared with her permission):

2 min: Intro to network topology – How are decentralized networks different than centralized networks? – Where must trust exist in each model? – What are trust and performance requirements of a peer-to-peer/decentralized system?

5 min: What is a Merkle tree? – What is a Merkle tree and what makes it unique? – Content validation properties (explain very briefly what a hash function does, and how Merkle trees use them to verify logs) – Explain performance properties

3 min: Examples – Recap how Merkle tree is uniquely suited to needs of peer-to-peer systems that need to share state – Merkle trees in Git – Flattened Merkle trees in the Dat protocol

Here’s a second example of a timeline, submitted by Geoffrey Litt as part of his proposal for “ENHANCE! Upscaling Images with Neural Networks”:

(1min) Introduction – We can now “enhance” photos!! – Show examples from CSI and from a 2016 research paper

(2min) A very brief neural networks crash course – A taxonomy of neural networks: Treating a single neural network as a black box, what are the different types of inputs and outputs that are possible? – Training a neural network: How does a neural network learn?

(2min) GANs: inspired by art forgery – Human art forgers are in a constant battle with the police. As the detection techniques get better, so do the forgers. – By creating multiple neural networks (a “forger” and a “detector”) and pitting them against each other, we end up with a really good forger!

(2min) Training a GAN – Explain how the GAN training process works using visuals – Show examples of the output getting better as the network trains

(3min) Cool applications of GANs – converting text to images! – converting line drawings to photographs! – converting images to 3D models!

Although most timelines are in bulleted-list format, it’s also fine to write in paragraphs of complete sentences.

It may also be helpful to keep in mind that the actual talk need not conform precisely to what was proposed in the timeline. 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 way of thinking. These kinds of talks can be a good fit for some 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!).

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 next year!

The “everyone at this conference shares my background and goals, right?” talk proposal

!!Con attendees and speakers come from a wide variety of backgrounds. Perhaps 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 good. The problem arises when speakers assume that the audience is already interested in a particular topic and motivated to listen to a talk about it. 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 wording 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!”

Does this mean that you shouldn’t focus your talk proposal narrowly? Absolutely not — a narrow focus is good. The key is to not assume the audience will come into your talk with particular goals and a particular background.

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 is part of everything and that everything is part of computing. If you’re going to submit a talk proposal about

We do accept talks

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.

Comments