Thank you for having me. I'm going to talk to you about how to give talks, but I want to start by welcoming you to POPL. It might be your first POPL, so: welcome!

I'd like a quick show of hands: how many people have read a POPL paper? [Nearly all hands raise.] I'm going to call that very nearly 100%. Very good. I have a weird question: we've all read POPL papers, so... why are we here?

You could get the papers! The papers are often available before the deadline. If you're truly determined, you could go to arXiv and read the papers before they're even submitted to POPL. You could get all the details, all of those juicy technical bits. So: why are we here?

[An uncomfortable pause passes as the audience realizes this is not a rhetorical question. Someone suggests, "networking."]

We've got networking, sure. It's cool to be around other people, but then why are there talks at the conference? We could just get together and network, but we do this weird talk stuff. Why do we have talks at conferences? What are talks for? It's not rhetorical.

[The audience warms to its task; someone suggests that "talks communicate information effectively."]

Talks can communicate information effectively. I agree with that---that's a good point. There's this argument that humans learn from spoken stuff better. While the whole "learning styles" thing has been pretty soundly debunked, it's still nice to listen to talks. But I don't think that's the reason why we have talks.

[Someone provides the answer I'm looking for, that "a talk is an advertisement."]

I love this: a talk is an advertisement.

That's right: talks exist because they are a way for us to focus attention. Talks are a way for us to bring attention to our work. There are 80-something papers in POPL. I know people who sit down with the paper proceedings and they read the abstract of every single paper at POPL. These people have crazy, encyclopedic knowledge of the research record---and they're great people to talk to for your references. But you may not be that way. I'm not wired that way: I can't do it. Talks are a way for you to figure out what you should be paying attention to. Talks are about capturing attention.

But there's a problem. Fellow Columbia High School graduate Pras Michel put it best in the foundational Fugee's song "How Many Mics":

too many MCs, not enough mics
exit your show like I exit the turnpike

That is, you're competing for attention.

POPL has two tracks of talks---never mind all the workshops before and after, and of course the secret and most important hallway track. There are other, secret tracks one can unlock, as you start to meet more people: more things are happening than are even happening at the hotel. POPL is a big human endeavor---a big human community.

Competing for attention is hard. If you want people to pay attention to the work that you did, you have to convince them. You have to show them that what you did is valuable. Their attention is valuable, and they value it, and it is your job to make sure that they're willing to apply their attention to what you're doing.

A good talk must communicate why it's valuable. If it doesn't, people won't care about what you did.

A good talk is a valuable talk; we're going to use this value framework throughout my talk. But I think we can we can give more advice than merely saying, "Oh, a good talk is one that is valuable." What is valuable? We'll talk more about 'value' at the end.

For now, a good talk has to do three things:

• It has to inform the audience about what you've done.

• In our community the norm is that, your talk must educate or teach the audience something.

• And, most contentiously, your talk must entertain the audience in some way.

Let's dig deeper into each of these ideas. First, I'll talk about these three things in more detail. Afterwards, I'll talk a little bit about technology and the way that we we make talks today; at the very end, I'll return to this value framework.

We've already heard that a talk is an advertisement. That is for many people a very uncomfortable thought: advertisement sounds like you're engaging in marketing, or being deceptive, or having to be particularly capitalist about what you're doing. I've said the word 'value' now probably a dozen times---who is this guy?

But it is advertising. You have some piece of work; you have achieved some insight; you've done something. For people to care about it, step one is for them to know about it. Part of your job is making sure people know about and care about and value what you've done. A good talk has to inform.

There's a problem, though. A talk cannot be the whole thing that you did. Two relevant sayings can help focus your efforts.

The first saying I learned from my advisor, Benjamin Pierce, and it is a Zen Buddhist koan. Koans are sort of like short stories or short phrases that are meant to point the mind towards enlightenment. The saying is:

Pointing at the moon is not the moon.

What's great about koans is you can sound so sagacious when you say them. You can sound like an absolute genius. I should first say: this is really a Zen Buddhist saying---it is not a literal thing the Buddha said, though you can read it from his teachings. The saying is used to mean that you should not confuse the things we say about enlightenment with enlightenment itself---our speech and the thing are not the same. (Knowing a koan and being enlightened are not the same!) Removing ourselves from Buddhism for a moment, a talk cannot be the actual paper. A talk is pointing at the paper. Your job is deictic; your job is to point out, "Here is this thing!" But you can't point at the entirety of something, you have to select features of it to point out. And, critically, you must select features of it to not point out. Your talk is pointing at the moon. You want to point well at the moon---you want to indicate the features of the moon that will help people see it.

Another saying that may serve you is due to Jorge Luis Borges, in his essay On Exactitude in Science:

The map is not the territory.

The talk is a schematic, saying, "Here's what I've done, let me show it to you in précis." The work itself is not even the paper, on some level. The talk is at several removes of abstraction from the actual work that you've done, and it's your job to give people that map---to give them the right level of abstraction so that they can know about what you've done.

But why is this the case---why must we merely point at the moon, or refer to a map? There are two reasons.

The first reason your talk must abbreviate your work is pure time. Your paper is twenty pages, say 15,000 words. That's a lot. If you simply read your paper at a decent clip---not my insane, "why is this guy talking so fast" pace---it will take you about an hour and a half. Can you imagine if that's how we did talks? Somebody gets up there, and they take out their paper and read it? To me, this sounds like the most inhumane possible way to communicate scientific results.

(There are academic fields that work this way! In the humanities people, will actually read a paper to the audience. It is a deep irony that the humanities have the least humane way of delivering results. I digress.)

Twenty minutes is not enough time to talk about everything.

There's a second fundamental reason your talk must abbreviate your work: people don't care yet. How could they? They don't know what you did! They haven't read the paper or the abstract; they may not have even seen the title. Maybe they went into your session for something else, your talk is next and---well, they're in, why not stick around for a minute and see what this next one is about?

You need to make them care! And you have just a little bit of time to do so.

This brings me to the first concrete rule that I'm going to give you:

You must motivate what you're doing at the absolute very beginning.

Why should people pay attention? What is valuable about your work? What are they going to take away from your talk, saying, "Gosh, good thing I stuck around for that!" Because they don't have to stick around.

That is: what is valuable about your work? You must tell them up front.

"What is valuable about your work?" is a core question, and we're going to talk a lot more about it at the end.

The most direct forms of value are things that just about everybody cares about: money and other resources; power; control; human time; safety; justice. Of course, people value other things, too---but these are high level concerns that the person on the street will care about. If your work can appeal to these, then your work will appeal to people.

Putting myself in your shoes, I can imagine how I would have responded to this 'value' talk as a grad student. I would not have responded well. I would have disliked this slide, and I would have disliked the speaker. That's fair! You don't have to like me.

Let's think for a second, though. These are too high level for POPL. Power: what could programming languages possibly have to say about power? What, then, are the high-level motivations of PL work?

[A professor raises their hand; I deflect them. A student suggests 'novelty'.]

I don't think novelty is an end in itself. People want novelty to be an end in itself, but I don't think it is.

[A student suggests 'efficiency'.]

Yes! Efficiency is a core PL value. There's a huge amount of work in programming languages about how to do things efficiently. Efficiency is clearly valuable. When things are efficient, you spend less resources; you have more control; you have more power, as efficiency opens up new opportunities; you save human time, probably the single most precious resource we have. If you can make it clear that you're making something efficient, then people who care about that thing will care about your work.

[A student suggests 'correctness'.]

Yes! It's as though you are literally looking at my notes. Correctness is another core PL value: we like getting things right. When things are correct, you won't waste resources on incorrect results; you exercise more control and do exactly the right thing; you ensure safety, or perhaps even justice.

[A student suggests 'expressivity'.]

Phenomenal---these are the exact three values that I have written down, in the exact order I wrote them down. Reflect for a moment on what that means: these are deeply held community values; these are values that everyone in this room shares. We will return to this idea.

Expressivity is the third core PL value. Expressivity is how we say things, and it affects control and human time. In fact, expressivity affects resources---but not always in the 'good' direction! But expressivity is so important that we're often willing to trade resources for more expressivity. Human time is far more precious than kilowatt hours.

If your talk addresses one or more of these core PL concerns---efficiency, correctness, expressivity---then people can relate to your work. They will be able to care about your work. The sooner you can do that, the sooner they will be able to see what they can get out of it.

Thinking about value at a very high level can be tricky. There's another framing that I really like: the problem/solution framing.

• Something seemed impossible, but you can show how to do it. Delightful! Classic results in computer science have this form: we couldn't articulate how to do something, but here's how. This addresses correctness and expressivity.

• Something is hard or inefficient, but you have found a better way. This addresses efficiency and expressivity.

• Something is error prone, but you know how to detect or avoid those errors. Classic PL work---like type systems---addresses correctness and expressivity.

• Something is complex and poorly understood, but you can explain it plainly. This addresses correctness and expressivity.

• Something seems correct, but is actually wrong. This last is my favorite; it addresses correctness, naturally enough. Something is "correct". Guess what! It's not, let me show you what's wrong with it---and then, ideally, here's the right way to do it. Fixing correctness bugs is one of the greatest things PL work can do. Fixing correctness is how we've built this scaffold of correctness---the incredible achievements attained by logic, programming languages, and other formal fields in the 20^th and 21^st Centuries---on fallible human understanding. It is amazing. David Hilbert would never.

These framings are structures for PL storytelling. If your talk can fit these framings, people will understand what you're doing---and then they'll be able to value it.

Can your work fit in one of these framings? If you can provide this framing up front---if you can say this thing's wrong, here's how we fix it; this thing's slow, here's how we make it fast---people will be able to care about what you're doing, and they will be able to value it.

You must begin here. First you have to tell people what wrong thing they believe, then you have to tell them how you're going to fix it. The sooner they can understand the problem and your proposed solution, the sooner they can decide that your talk is valuable.

To inform is to plant the seed of value in your audience's mind. After you have planted the seed, it must sprout and blossom.

We're all in academia for the same reason: we're dorks. Wanting to learn is an essential dorky trait! It's how we got here. The second thing a good talk must do is educate.

(That talks must educate is specific to computer science in general and PL in particular. It's not necessarily true in other communities!)

Your work has some insight---probably several. Some novel thing, a novel way of looking or describing or understanding or relating or doing. That insight is why you have a paper---congratulations!

But your talk is only twenty minutes. What insights do you have that you can communicate in that time? What is the thing that you've realized that other people can profit from, that other people can derive value from? What is the valuable insight?

With only twenty minutes, we are already running out of talk time: you've spent some time motivating what you're doing---situating it, explaining the problem, explaining the solution. And now somewhere in there you've got to sneak in your insight.

The second rule I have is:

You have to teach something portable.

Portable may as well be 'valuable'. Portable means someone else could possibly care about it enough that they take it with them, from your domain to theirs. If your inight is only about your special thing, that only you use, then the community will value it less. It's just your thing! What does the community care about? What can the community relate to?

Teaching something with general appeal makes your talk more valuable. It makes your audience member feel like they have gotten something worth their time.

PL is, broadly speaking, more of a 'techniques' field than a 'problems' field. So often the thing we teach in a talk is a new technique or something new about a technique. This is fine---techniques are valued in the PL community. But! If you can teaching something broader than techniques, I think that's even more valuable.

You can't include every insight from your technical work---the insight you teach must be a portable one that fits in the time you have. The bits that do make it in might not even be the key technical results, as they may not be portable or fit into the time allotted.

Joe Cutler, in his talk on "Getting the Most Out of POPL" showed a slide like this [but without the skeptical face], with "mean audience understanding over time" declining precipitously. After his talk he confronted me, saying I "looked so angry". That's mostly just my resting face---but not for this slide. If a talk fits this graph, I don't think that's a very good talk.

At the very least, the graph should be somehow U-shaped, with understanding increasing again as the talk concludes. Maybe my talk had to get into the weeds---some narrow, technical domain of practice. Maybe my arch nemesis needs to hear a message for just a moment... and then we pop up and talk about technical results more generally. That's just fine---we all have our own agenda. But no talk should be spending a lot of time on the low end of "mean audience understanding". If that's happening, you're not getting all the value out of your talk that you could be---and you're not giving people the value that they could receive.

By the time you hit here [I gesture to the emoji in the middle of the slide], they're on their phones---and they're not coming back.

However descriptive Joe's graph may be, it is not normative. Talks should be intelligible.

I don't know if you've noticed, but we're not just dorks---we're people. People like to have fun. Did you know your talk can be fun? Your talk must entertain.

Surely this is my most contentious point. Trying to entertain seems frivolous---aren't we serious academics? Don't we write papers in the first person plural? If we're European, don't we avoid contractions and talk about "the authors" as though they were on some remote planet? Isn't that how we're supposed to do it?

I don't think that's right. If the human has to be left out of the academic endeavor, then I want to be left out, too. I don't want to be part of a PL community that that doesn't value the humanity of its members. Part of that means respecting people's time and attention. There's an opportunity for all this---talks, conferences, research, academia---to be good in an immediate, human way. Entertainment and pleasure are good! To have that opportunity and not take it up is to fail ourselves. What a world we could have! That's the noble framing of entertainment.

The canny framing is: you are competing for attention. People could go to another session. They could skip the session entirely. You gotta grab 'em.

Every talk is a performance. It's a very particular kind performance, with its own mores and norms. There are a variety of performance tools that you can use to hold audience attention. There's room to push it---people do all kinds of funny stuff.

Like any performance, your talk could be scripted or it could be improvised. What it must be is practiced. It doesn't matter what kind of talk you're giving, you have to know what you're going to do---you cannot be just figuring out for the first time when you're up there. Practicing is a way of valuing people's time.

How can you give a good performance? How does one perform? Maybe you don't have that theater kid energy, where it's hard not to perform. There are many tools for giving a good performance: you can do it with humor; you can do it with sincerity; you can do it with fevered excitement and jumping up and down (this is not my favorite, but if you do this---just keep your clothes on); you can nail the pacing and timing and structure. You don't have to showboat! But if you have it, you can ride on pure, raw charisma. There are lots of different ways to perform.

Some of these ways might come to you more naturally than others. You're going to have to use your strengths. In the theater world, there's this idea that you have to "find your clown". Maybe you shouldn't find your clown for your professional talks---there should be no clowning at POPL. But you do need to find your performance strengths, and to identify approaches to performance that will work for you.

Hearing you need to perform may feel bad. None of the tools I presented may feel natural to you. As you may be aware, there's a broad stereotype of computer scientists as not having the most robust social skills, and performance is a social skill. You may not be able to use raw charisma. You'll have to find something else, and the way to do that is practice. And if these skills don't come naturally to you, that means you're going to have to practice even more.

You're going to have to give lots of talks. Your conference talks are rate limited, and you're not going to get a ton of opportunities---at least not in graduate school. Which means you're going to want to give many talks well before your first conference talk!

If your first conference talk is your first talk... how nerve-wracking! I'm sorry to point it out, but that's rough! You want to have experience getting up in front of large groups of people. This room is maybe fifty or sixty people; a POPL session could easily be a hundred or more. You may not be comfortable, but you should be able to stand up there and deliver the performance that you've practiced.

The way to be able to give a conference talk is to practice and perform frequently. You need to find the regional workshops; you need to find the other groups you can visit; you need to make sure that you're giving talks in your group. You need to make sure that you're getting a bunch of different audiences, listening to their feedback, and adapting your approach.

It's also good practice to watch a lot of talks. Take the framework for "good talks" that I'm giving you here and apply it to the talks at POPL. How are they achieving their ends? If they are! Watch and see what they do; steal what you like. Watch a talk and ask yourself, "Could I do it the way they're doing it? Could I wear those proverbial clothes?" Watch talks where you know the work well---what did they include, and what did they leave out? There are so many talks on the SIGPLAN YouTube channel... why not spend an hour or two each week, watching and learning?

Your talks are your public persona. Sure, you're going to network like Joe [Cutler] told you to. You're going to meet a bunch of different people in the hallway track; you're going to meet people at meals; you're going to meet people by whispering to each other in sessions, "What does that even mean?" You'll talk to a bunch of people---but far fewer than will attend your talk. When you're speaking at a conference session, you have the community's attention. We established this up front---this is why we have conferences, so we can grab the whole community's attention! When you're giving a talk, that's when they are receiving information not just about your work, but also about you---about who you are.

If you pursue academia, you're going to give something called a "job talk". A job talk is one of the most condensed forms of anxiety that exists in the world. A job talk is supposed to do so much! Obviously you have to communicate strong technical content, showing you're a good computer scientist. But you're also going to have to show that you'll be a good colleague---you have to show who you are. A job talk is putting your professional self---which inevitably overlaps with your true self---into a sixty-minute package. And during that sixty-minute package, you may be getting hostile questions from people you've never met. That's rough!

If you want to be an academic, you're need to be able to give a good job talk. To give a good job talk, you must first be able to give a good talk. And to do that, you're going to have to give a lot of talks. You're going to have to build up that public persona.

But also: every talk is a job talk. At every talk you give, the community is receiving information about who you are and what you do and how you do it. It is very much incumbent on you to do that well. The community is going to watch and---it's a rough word, but frankly the community is going to judge you based on your performance. It's the only time most people in the community will see your work. Your talks are you.

I am so sorry to point all of this out. It's surely not the best thing to hear. "Oh, you're telling me it's even higher stakes than I thought? Great news!" I'm sorry to point it out, but I feel like I must. It's true, and it's important.

People are gracious, and people are realistic. Nobody expects a student's first talk at a workshop or at POPL or anywhere to be a bombshell, bringing down the house. But there people do expect you to give a competent talk; there is a bar that everyone is expected to meet. People will notice who gives good talks, and they will interact with that work more---citing it more.

The benefits of speaking well are very real. It's worth investing the time to learn to speak well---even if it's uncomfortable, and even if it's not how you want to spend your time. If you want to be in this community, learning to speak well is something that will increase your stature in the community. The rewards are real.

I've given you this three-part framework of what a good talk does---what a valuable talk does:

• It informs people about the value proposition. What's broken, and how do we fix it? What's impossible, and how do we do it? You start by telling people what they could be getting out of your work, what is the valuable thing.

• Then you literally deliver value in the talk by teaching them something---you educate. You give them something they can take home, a little party favor from your talk: "Oh, I didn't know you could do that with logical relations!" or whatever it is. Something.

• Lastly, you are going to entertain the audience; you are going to perform. You're going to value their attention by doing a good job. You've practiced and rehearsed. You are giving them something valuable in that moment---entertainment. In exchange, you get to hold their valuable attention.

The entire enterprise of giving a talk is about giving something valuable to the audience in exchange for attention. I want to spend a little bit of time talking about the technology we use to give talks, and then I'm going to talk more about this value framework.

You may notice that I have not really talked about the tools we use to give talks: slideshow software, presentation remotes, whatever. There's all kinds of technology, all kinds of gimmicks.

I haven't talked about technology, because I don't care. The slides for your talk are pixels on the screen---and the way that you get them up there is your business, not mine.

I have given good talks with beamer, with Keynote, with PowerPoint, with Google Slides, with an emacs buffer, straight out of a terminal, with a Blackboard. I made the slides for this talk in LibreOffice Impress---anything is possible if you believe in yourself.

Personally, some of these tools are easier than others. Beamer could never be worth my time. I gave one solitary talk with Beamer, and I resolved that I was not going to write a program in the world's worst programming language just to make my slides. I'm not going to spend twenty minutes looking up TiKZ documentation to see how to move some object five pixels to the left. That's a mouse action! But if that's how you want to spend your time---if that tickles your funny bone---you know, good for you.

Nobody cares how you get there---your slides just need to serve your talk. Nobody cares whether you did it in Beamer or Keynote or this or that---they care about what they saw and what they got out of it. That said, if you are going to use Beamer, please remove the stupid little controls from the bottom. It's embarrassing. You have a PDF viewer, learn to use it.

There's no shortage of advice on how to structure your talk. Neel Krishnaswami gave a lovely talk, "How to Give a Talk", at PLMW at POPL 2024: it's a case study of one of his talks (that he did in Beamer!). He walks you through the reasoning behind his structure. His presentation goes into the nitty-gritty, with more technical focus than I'm giving you. I think you'll find a fair bit of overlap with my framework. And while I disagree with him on a few points, there's no arguing that Neel is a very effective presenter. I saw the talk that he breaks down, and it is a good talk.

While I'm not going to go into the same level of detail as Neel does, I can give some high level guidelines. I have some patterns, and I have some anti-patterns.

• Your slides should be pretty. The bullets should be aligned; the same text on consecutive slides shouldn't shift around. I find it distracting. Is it petty? Hell yes. But sloppiness sends a bad signal. Is my attention not important enough for you to make it look nice for me? Make it look clean.

• Use pictures; represent things diagrammatically as much as possible. Diagrams foster human understanding. It's not easy---PL is a textual field! But very often there's a diagrammatic way to explain a thing. If you can find that way, people will understand what you're saying better---and they can only value things they understand.

• Build slides that can stand alone. People's attention will drift: good slides will let them catch up without needing to follow your voice. If the slides are clear, others can present from them at their group meetings, helping spread your work and get it cited. This talk with its "mashing on an emoji keyboard" aesthetic is a bad example, of course, but it's not a technical PL talk---it's a different kind of technical talk.

Beyond things you should do---positive patterns---there are things you should avoid---anti-patterns.

• Do not tell the story of the work. How you got to the answer is not the interesting part. It could be that the missteps you had along the way are actually some of the portable insight---maybe one might expect things thinks to work one way, but it turns out to be different. But in general, nobody cares how you got there. Relatedly, don't keep people in suspense. I don't want drama, I want the answer. Spoilers up front: show me that it's going to be worth my while.

• Do not dump text on the slides. Avoid text if you can; certainly avoid bullets, which have a corporate low-effort "PowerPoint default theme" vibe to me. You could take a slide with bullets and immediately improve it by simply removing the bullets.

• Do not screenshot your paper's technical material. It is very rarely the case that the presentation in the paper of some technical fact is the right presentation for a talk. Also: the fonts won't match! Do you seriously think I can't tell? Write it out again---and as you write it out, you'll realize you can leave a little bit of it out or present it at little differently. Lie to people! People expect to be lied to in a talk; they expect to be given the pat, simple version that they can take away, knowing that the paper has a more nuanced version.

• Avoid new notation. Perhaps a bit of a hobby horse of mine, but nobody needs your new notation. Just use English, or explain it diagrammatically. Maybe your new notation is really important and worthwhile, but I doubt that your talk is the right time to introduce it.

• Avoid judgments and inference rules. Is this the level of detail that you need to present? Maybe you're doing some foundational type systems work, and it's all about one particular rule. But again: I doubt you need to show it. Is there a different way? Can you show it diagrammatically, rather than as an inference rule?

We've talked about what a talk needs to do, framed around this idea of value. You inform the audience about how the work is valuable; you educate them, delivering value; you entertain them, valuing their time---and they give you their valuable attention in return.

Let's talk a bit more about value.

Let me begin by saying that I've borrowed this value framework from Larry McEnerney's "The Craft of Writing Effectively". I cannot recommend this video highly enough. He's giving a talk on writing to social scientists at the University of Chicago. It's an amazing talk. Watching the graduate students squirm in that lecture as he talks about value is its own joy---but also his ideas are phenomenal.

While Larry's talk is about writing, that's not the point---everything we do is about value. And 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 Carl Marx or Adam Smith. Value is simply the framework for understanding how these things work. I recognize that this smacks of capitalism---and it's about to get worse.

Value isn't just about money, though. We assign value to the things we care about. It is a hard truth that by default, people do not care. Absent any other information, people are not going to care about something.

Let's consider our academic work. So there's a paper on some subject. Okay---cool. That it's in POPL, say, provides some social signal. I could be interested. But in expectation, I'm not interested in most POPL papers. This is rough! You work really hard, you finally get the paper---but who cares? It's hard to make people care! The academic's job is not to merely produce papers. Just doing the work isn't enough. Having done it doesn't count for much. The actual work is the convincing people of things. As an academic, your job is to get people to believe that what you've done is valuable. That's the actual work that an academic has to do.

Within any discipline, there are community norms on what counts as valuable or interesting, what constitutes a well motivated problem, and what constitutes good technical work. But even so, every research paper still puts the most important thing right at the front: a value claim. Every research paper distills into a few bullet points, "We contribute these [valuable] things". Every paper has this, because that's what we're doing: the name of the game is convincing people to value things.

Let me be still more capitalist, still more crass, still more mercenary. This slightly hard to read table is excerpted from Wikipedia's article on "Household income in the United States", broken down by education and gender. The gist of this chart is that by getting a PhD you are giving up total lifetime earnings. Even getting a Masters, you're giving up lifetime earnings. If your goal is to maximize income, you should start working as soon as possible---the marginal difference in pay from a PhD or a Masters doesn't make up the difference from several years of professional work, especially if you're talented. Did everybody in the room know that?

The fact that we're all here---and nobody burst from the room to go work on their LinkedIn profile or their MBA applications or their VC pitch---is very clear evidence that value is not just about money. If we cared only about money, this room would be empty and the hotel would be hosting a different event. We're all choosing to give up money in exchange for something else that we value.

What's more, it's clear that some of these non-monetary values are shared. When I asked at the beginning, "What does the PL community care about?", I was able to get my top three items---efficiency, correctness, expressivity---in order from the room. I didn't plant those answers! That was real! We hold these values in common! That's why we're here.

Which is to say: maybe it's not as bad as I made it out earlier? People don't come to POPL to sit like sullen teenagers, strolling into your POPL talk, saying to themslves, "Ugh, do I have to listen to this?" No! They want to be there. We all came to POPL because we believe we're going to get something out of it. We came because we care about the some of the same things, and that is beautiful.

So the message of my talk, made less crass, less grim, less mercenary: people come to POPL because they expect to come away with something worthwhile; as a speaker, it's your job to make sure that you give it to them.

You might be wondering, "Is my work valuable? What is my motivation? How am I contributing?"

Good! You should think very hard about that. What value does your work contribute? Are your values with shared with this community? Is this the audience you want, or do you want a different one? Whatever audience you choose to address, you will need to come to understand---and likely adopt---its values.

If you want to address a broader audience, you need to address broader needs. If your work addresses things with less appeal---specific techniques, small communities of practice---you'll be restricting your scope to whatever community values those things.

You have to think, "Who is my work's audience?" And then you have live with the choice that you've made! You're going to pick a kind of work to do, contributing a certain kind of value---and that is going to determine the audience for your work.

This kind of talk---the work determines the audience---is something I resented as a grad student. To me, the whole conversation felt like it was telling me to "be more applied". I got a PhD because I wanted to do theory! At the time, I absolutely rejected anything tainted with the foul reek of application. "Why would you spend time with that? See how embarrassing JavaScript is? C? Ugh, so bad." My thinking has evolved. Way more people care about JavaScript and C than the lambda calculus.

But there's room for a lot of different stuff! Think carefully about what you value. Is the work that you're doing achieving ends that you care about? If you feel stuck with a small audience, if you want to reach more people, if you want to influence the world in a bigger way---you can change what you're doing. And if you feel good about your audience---great! You're getting what you needed. This value framework isn't just about how you talk about the work you have done, but it informs the work that you will do.

Nowadays, I eschew a theory/practice division entirely. All the best work does both. I much prefer the problem/solution framing. When you frame your work in terms of addressing problems, it's much easier to find communities who will care about your work. Pick a problem that a bunch of people have, and if your solution actually works people will care about it... if you can get them to understand why your solution works. If you can frame your problems generally, and you can offer plausibly general solutions, then you will be rewarded with a commensurately broad audience.

If you're going to work on a technique, you're only going to capture the attention of the community that knows about that technique and cares about it. You can cross communities, you can teach people to care about techniques---but it's very hard. If you're going to work on a problem, people will happily learn about whatever techniques you like if they think it will offer them a real solution. If you can, frame things as general problems with general solutions. If you don’t overreach, you’ll do good work.

I've given a bunch of advice, with some concrete rules along the way. Very effective talks break these rules---don't over-index on my advice. Your talk is your performance, not my performance. Even so, this value framework is the right one.

When you're planning a talk, you must consider, "How am I going to communicate that what I'm doing is valuable?" When you give your talk, the people in the audience are going to give you their most precious, most valuable resource---their time and attention. The stakes of a talk are indeed very high. As they should be: people are trusting you with their time and attention, so don't waste it.

Thank you for your time and attention. I hope this has been valuable for you.