How to give a good research talk

Simon L Peyton Jones John Hughes John Launchbury

Department of Computing Science, University of Glasgow, G12 8QQ Scotland Email: fsimonpj,[email protected], [email protected]

Abstract

Giving a good research talk is not easy. We try to identify some things which we have found helpful, in the hope that they may be useful to you.

This paper appears in SIGPLAN Notices 28(11) (Nov 1993).

1 What this paper is about

By a research talk" we mean a presentation of 30-60 minutes, given to a group of people who are motivated and intelligent, but who may not know much about your particular area.

The paper is heavily on our personal experience of giving talks in the area of Computing Science. What we have to say is quite different from what business people are often taught, but perhaps that's due mainly to a difference in the style of presentation needed for technical material.

Papers like this one often tend to consist mainly of motherhood" statements, with which nobody could possibly disagree (such as prepare well"), and thereby end up with little real punch. We have tried to avoid this, partly by deliberately overstating some things (the title, for example) in order to make our points more vividly.

We make no claim to have all the answers; rather, we have simply tried to write down suggestions which have worked for us in the hope that they may be useful to you. Everyone is different, so take what is useful for you, and ignore the rest.

2 What to say

You should usually see your talk primarily as a aster" for your work, rather than as an indepth treatment. So two very useful questions to

ask are these:

ffl Who is my primary audience?

ffl If someone remembers only one thing from my talk, what would I like it to be?.

If you have the answer to these questions pinned down, you can use them as criteria when deciding what to say and what to omit. And don't forget to tell the audience the answer to the second question!

2.1 Using examples

Most of us do research by trying to solve a bunch of related problems, finding some suitable framework in which to solve them, and then generalising and abstracting our solution. For example, if the problem is to find out whether a function evaluates its argument, then a suitable framework might be denotational semantics, and a generalisation might be abstract interpretation.

The Awful Trap is to present only the framework and the abstraction, leaving out the motivating examples which you used to guide your work. Many talks are far too abstract. They present slide upon slide of impressive-looking squiggles, but leave the audience none the wiser.

It is utterly vital to present examples which demonstrate the points you are trying to make. When you give a definition of a property, or a mathematical structure, or some new notation, give examples to show what the definition captures. When you give a theorem, give examples to show what it means in practice.

Of course in a written paper you must be careful to fill in the details, and state precisely what is going on (though a good paper has plenty of motivating examples too). With any luck, your talk will persuade your listeners to read your