How to Give a Good Talk

How to Give a Good Talk In computer science, conferences are a focal point of academic attention. Conferences are a moment where computing communities—distributed over the globe—come together. Giving a talk at a conference is an incredible opportunity: for a moment, you have the community’s attention. If you can give a good talk, the community will pay more attention to your work! But what makes a good talk? I spoke at PLMW 2025 on this topic—“How to give a good talk”. You can read an edited transcript of the talk on my blog; you can watch the unedited livestream on YouTube. This blogpost is another cut at the same ideas. The value framework There are many talks at conferences, and there is much to do at a conference apart from sitting in lecture halls (the “hallway” track; meeting with collaborators and colleagues; recharging in your hotel room; exploring a new city). You are competing for attention. As Pras Michel put it in Fugee’s song “How Many Mics”: too many MCs, not enough mics exit your show like I exit the turnpike A good talk needs to be worth the audience’s time. A good talk is a valuable talk: it should convince the audience that your work is valuable, i.e., it should make the audience care about your work. Good talks inform, educate, and entertain What makes a talk valuable? In the PL community, a talk should ‘deliver value’ in at least three ways, if you can pardon the contemporary capitalist jargon: Your talk must inform the audience about what you’ve done. Your talk must educate the audience. Your talk must entertain the audience. Inform: what have you done, and why is it valuable? Computer science conference talks condense papers with tens of thousands of words into twenty minutes. ‘Condense’ is too weak a word—your talk abridges your work, leaving out gobs of detail. We must omit this detail not merely because there’s no time for it, but because the audience does not yet care about the details. Every talk must begin with its motivation: what are the stakes of the work? How does this work address the fundamental PL concerns of efficiency, correctness, and expressivity? What do we stand to win from your work? The audience cannot care about your work until they understand the ‘value proposition’, to use still more contemporary capitalist jargon. As a graduate student, I struggled with the ‘value proposition’ framing, hoping that academia was a refuge from contemporary capitalism. (It is not.) Fortunately, I think there are a some common scripts for PL value propositions, in a “problem/solution” framing: Something seemed impossible, but you can show how to do it. Classic results in computer science have this form: we couldn’t articulate how to do something, but here’s how. Classic results in computer science have this form: we couldn’t articulate how to do something, but here’s how. Something is hard or inefficient, but you have found a better way. Improving things is almost as good as inventing them. Sometimes improvements are what move things from possible to tractable. Something is error prone, but you know how to detect or avoid those errors. Classic PL work—like type systems—falls into this category. Something is complex and poorly understood, but you can explain it plainly. Not every community in CS appreciates this, but the PL community appreciates “pearls” and clear explanations. Something seems correct, but is actually wrong. PL is part of the logical scaffolding that has built remarkable reasoning tools in the 20th and 21st Centuries. We have built solid formal structures on a foundation of fallible human reasoning—in large part through slowly identifying things that seem correct but are subtly wrong. These framings articulate how you’re contributing value—people can understand how you’re addressing efficiency, correctness, and expressivity concerns. If your work fits in one of these frameworks, you need only (a) cite the framing and (b) explain the domain you’re working in. Educate: what can the audience take with them? It is a norm that a good programming languages talk teaches the listener something: a new insight, a new technique, a new model. Your talk is a party for your work, but the guests expect party favors. You want to teach the audience something valuable, i.e., something they can take from your work and use in their own domain. That is, what you teach must be portable. It may or may not be the case that your work’s portable insight is its main insight. The bits that do make it in might not even be the core technical results, which may not be portable or may be too complex to explain in your talk’s time slot. Just as your talk abridges your paper, your insights will need to be carefully selected: what can you teach that will be the most useful to the most people? Entertain: what holds the audience’s attention? A good talk should entertain the audience. As I write this, I can already hear the “tut-tutting”: isn’t entertainment frivolous? Aren’t we serious academics? I’ve gotten reviews asking me to remove contractions from my writing—if “can’t” isn’t okay, surely having fun is out of bounds! Claptrap! Balderdash! Utter nonsense. If the human has to be left out of the academic endeavor, then let me off the ride. I don’t want to be part of a PL community that that doesn’t value the humanity of its members. Talks are performances, and performances should entertain. You don’t need to bounce around the stage like a maniac. (And if you do, keep your clothes on.) There are many ways to have an entertaining performance: humor, sincerity, careful structure and timing, charisma, intensity. To give a good talk, you must find a way to perform that works for you, and then you must practice performing so that you can do a good job in the moment. What’s more, your talks are your most public persona—giving a good talk is making a good first impression. The rewards of giving good talks is real: people will pay more attention and remember your work better. Giving a talk is one of the primary hurdles to jump when interviewing for academic jobs—you’ll want to perform well! The value framework, redux A good talk is a valuable talk. I’ve borrowed—really, stolen—this idea from Larry McEnerney’s “The Craft of Writing Effectively”. (I’ve written about him before, in a blogpost about “What’s hard about grad school?”.) In fact, everything we do is about value: the topics we work on, the problems we solve, the papers we write, the software we build and distribute, and of course our talks. I cite Larry McEnerney as the person who really opened my eyes to ‘value’ as the lens through which to see all of my work… but I could just as easily cite Karl Marx or Adam Smith or Henry George. Value isn’t just about money, though. We assign value to the things we care about. It is a hard truth that, in general, people do not care. Rather, people do not care unless you can make them care. An academic’s research output is not merely the papers they publish—it’s convincing people that what’s in those papers is important. The good news is that our communities—academia, computer science, programming languages, a particular conference—have shared values. When I gave my talk at PLMW, the students in the audience were able to name the three core PL values—efficiency, correctness, and expressivity—in that order, unprompted. We are members of these communities because we share values. Shared values and shared narratives—the problem/solution framings above—mean that a conference audience is primed to understand and value your work. You’ve just got to help them get there! A good talk meets the audience in the middle. It informs the audience what the value proposition is; it educates them, offering some new teaching; it entertains them. In exchange for these valuable things, the audience will give you their precious resource: their time and attention. About the author: Michael Greenberg is an assistant professor of computer science at the Stevens Institute of Technology. His current focus is the POSIX shell and its ecosystem, but his work has ranged from functional reactive programming JavaScript to higher-order runtime verification to software-defined networking to logic programming. Disclaimer: These posts are written by individual contributors to share their thoughts on the SIGPLAN blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGPLAN or its parent organization, ACM.