As we are gearing up for POPL’19, my students putting their talks together. For one of them, this is his first conference talk, and for the other it’s his first PL talk. So both of them separately asked me for advice about putting the talk together. After answering the second time, I realized I should follow Matt Might’s advice, and “reply to public” by sharing what I wrote to them.
There’s lots of good advice out there about making conference talks, which I summarize at the end. I think what I say here reinforces much of that good advice, and adds a bit to it.
Principles: Why and What
There are two big-picture principles to keep in mind when putting together a conference talk.
First, be clear about why you are giving a talk. For a conference talk, your goal is not to get all of the technical points across. The goal is to get across the key ideas and contributions of the paper. Your audience will consist of some experts, but mostly of people interested in the general area. Your talk is a success if they go read your paper, and/or remember it later when they do work in the area or someone asks them about work in the area.[ref]Other talks you give — to your own research group, for a dissertation defense, for a panel, for a keynote — will have a different audience and goals than a conference talk, and will differ somewhat.[/ref]
Second, lean on the work you did when writing the paper. Your talk should follow the main argument of the paper. This sounds obvious, but you’d be surprised how strong the temptation is to write the talk from scratch, ignoring the argument and presentation order that was successful in the paper. The paper should have motivated the problem, argued that no good solution exists, and explained your approach and why it works. Your talk should do the same thing! The paper’s introduction — which lays out the scope, the problem, and the reasons that your work is the solution — is particularly useful to carry over to the talk. The introduction was hopefully written as if to a general audience (for this conference) and will have the key argument and contributions in it. Take advantage! Time constraints and emphasis may cause you to adjust what comes later (more below). Nevertheless, the content from the paper — especially examples, illustrations, lines of reasoning — are likely to be useful in the talk, too, and you should start from them.
How to Write the Talk
With the above two principles in mind, you can set out to write your conference talk. How? Here is what I suggest:
Figure out what you are going to say first, in increasing detail, and only then set out to make the slides. Again, this seems a little obvious, but there’s a temptation to make particular slides, and make them beautiful, without knowing how they fit in the big picture. In the worst case, this work is wasted because you end up substantially redoing slides once the big picture is clear.
I usually make an outline first. This should be easy(ish) for a conference talk because you have the paper as a guide. Identify the sections of the talk first, then what you will say in them, roughly, and then how what you say is broken into slides.
To elaborate: The outline is constructed at a high level of abstraction first (e.g., like section headers in a paper), then digs into each part, a layer at a time (e.g., subsection headers, then elements of content like code examples or tables or figures). This way you always have the big picture in front of you as you are digging in, and you will know you are not blowing past your time budget. I estimate 1 slide to take 1 minute in the talk, though there is give and take here, e.g., if there are animations to build (faster), figures to explain (slower), etc.
Once you get to slide-sized chunks, you can switch to making placeholder slides. Make the titles and make notes on the slides of what they will say. Grab code examples and pictures from the paper that you know you will use and put them on the slides. Finally, when you have the basics down and you like the flow of the argument, you can flesh it all out and make it pretty.
What (Not) to Say
One of the toughest things to do when writing a conference talk is to leave things out. When you follow my outline-to-slides approach you will become acutely aware of the time constraint: as you flesh out the outline into slide-sized chunks you will see you are running out of time. Which sections should you expand, and how, and which should remain higher level?
To answer this question you should reflect on the main goal of your talk: get the key points across to an audience of mostly non-experts. Since you don’t have much time, you won’t be able to focus on lots of technical detail. Yes, the proof, type rules, equations, etc. are the key technical results of your paper, but it’s best to reference them for interested readers to see later. Be ruthless in what you don’t include; keep only the essence, and reference the rest.
On the other hand, making vague, ungrounded claims is not very illuminating or convincing. Your best weapon is to use examples. If your paper is about a compiler optimization, then you could show an example program, and then show how it is optimized normally, and with your technique. If your paper is about how to prove a program property like termination, you could use examples that exercise the different features of your technique. Hopefully, you’ve already done this in your paper, so it’s just a matter of adapting them to the talk format.
I usually like to include some parts just for the experts. Doing so helps initiate useful conversations after the talk. These parts might use some jargon or notation or connections to related work only experts would know. Try to do this in a way that the general audience can still see where you are going; you might warn them that you don’t expect them to understand these bits.
The Slides
I won’t spend a lot of time on how the slides of your conference talk should look. There’s actually a lot of advice from others on this, which I’ll mention below. Here are some quick thoughts.
First, keep in mind the principle of “twice told” (or thrice told): If there’s an important point you want to make, make it several times in different ways. Your point should not just be a picture, or just text: it should be both. That way, you will say it, they will see it, and they will read it. Hopefully, as a result they will internalize it.
A related point: Titles of slides should be about key points. Usually there should not be a more important piece of text on the slide. If there is a pithy statement on the slide that is more important than the title, then move it.
Slides should not be long lists of bullets (only). Lists are useful as an outline for you, but they are boring for the audience. Oftentimes I will write bullet lists first, but then ask myself: Can I say this with less text, and without bullets? How could I use a figure, animation, or other illustration? This process leads me toward the “twice told” principle, and also leads me to reduce text that is only narrative.
Finally, a pet peeve: Your last slide should not just read “Thanks!” Such a slide conveys no information. Instead, have your last slide summarize the key points you were hoping to make in the talk itself. It will stay up on the screen while you answer questions, and so people will have an opportunity to read it. Pointers to more information also make sense on the last slide.
Further Reading
There are several other sources of advice on making talks that I’d recommend. First, I’d recommend Simon Peyton Jones’ papers and talks on how to do research. Derek Dreyer gave a nice talk about giving talks at PLMW at POPL’18. Both Simon and Derek’s (meta)talk slides are examples of good talks! Michael Ernst also has good advice about making and giving talks. Most of what I’ve said here is complementary to what is said by these excellent presenters, though we do differ on some things.
Also, for inspiration, I would recommend finding talks by great speakers. Lots of conference talks are now recorded and free on-line. I particularly like talks by Simon Peyton Jones, Derek Dreyer, and Ranjit Jhala (off the top of my head). Who are your favorite speakers, and which are your favorite talks? Link them in the comments!
Summary
Conference talks on rigorous research are a great asset of the computer science culture. Giving a conference talk is a great opportunity to share your research with an interested audience in a way that increases its impact and relevance. A talk can be the start of a conversation that leads to new ideas and collaborations. A great talk takes effort and practice, but doing it can be fun and rewarding.