A guide for preparing, and giving, excellent talks.

Koz Ross cff43b635e Filling in first draft 7 years ago
LICENSE ce8c4359e2 Initial 7 years ago
README.md cff43b635e Filling in first draft 7 years ago

README.md

Give you a talk for great good!

Introduction

Giving talks is hard - I know. It scared me a lot when I first started doing it; getting up in front of an audience is intimidating in itself, and when it's about something like computer science, doubly so. Your mind throws itself every which way, trying to figure out where to begin when crafting the talk, and once you add in the formality and complexity of computer science topics, it can be quite scary.

However, it doesn't have to be this bad! By the time you've read this document, you will be in a good place to start making your own talks, and delivering them with finesse. While this won't guarantee your success, it will at least make sure that you're well-equipped with the basics.

It is my desire in writing this that CSC members will contribute their wisdom, experience and ideas to it. Giving talks is both an art and a science, and the amount that could be said about it is huge. The goal of the CSC is for us to share our knowledge and teach each other new things - this document being no exception. Thus, if you have ideas to improve this document or something to add, we welcome them.

Your main idea

Before you even start with anything, you need to decide what the main idea of your talk is. Given that this is computer science, it will usually be one of these:

  • An algorithm
  • A data structure
  • A theorem or proof
  • A formalism (such as a method of analysis)

Note, that this is separate from the context or use of this main idea. These usually serve to ground what you're talking about in some kind of real-world problem or use case: however, the idea is not that real-world problem or use case. It is certainly important to have a real-world problem or use case, but it is used to support the idea, not replace it.

Any given real-world problem or use-case may well have multiple main ideas behind it. Consider something like PageRank; even in a topic like this (which is fairly narrow), there are several main ideas:

  • Graphs in general
  • Graph centrality
  • The PageRank algorithm itself
  • Ways in which the algorithm can be efficiently implemented
  • Use of these methods in the context of distributed systems

Any of these could be the basis of a talk; however, only one of these should be the basis for your talk! Ultimately, while you'd use (and make reference to) PageRank no matter which of these main ideas you end up going with (because otherwise, why do we care about it?), it will provide justification for the main idea, which is what you're really talking about.

In some cases, you might already begin with a main idea. Perhaps you're really fond of some kind of algorithm or data structure, or a method of analysis, or some really interesting theorem in computer science. In that case, great! However, in most cases, computer science is done in response to problems or use cases from the real world; thus, you need to tease out what your main problem is before you can begin.

Keep in mind, your problem doesn't have to be hard - the CSC is a diverse group with regard to levels of knowledge and understanding of computer science, and what might seem easy or obvious to someone might be revolutionary and amazing to someone else. Thus, don't feel like you need to handle an idea that's very hard to follow or complex: something simple can be just as good and interesting.

Anatomy of a talk

Alright, you have your main idea, and you have a context to put it in. Now, it's time to plan the talk. Remember, the audience will be hearing about this for the first time, and to them, there are four questions that need answering, in that order:

  1. What (is this)?
  2. So what (is so good about it)?
  3. How and why (does it work)?
  4. When and where (can and can't I use it)?

Your talk should thus follow the same progression. Essentially, you will have four segments to the talk:

  1. Motivation
  2. Preliminaries
  3. Description
  4. Conclusion

Motivation

In this part of the talk, it is your task to answer the 'what' and 'so what' questions that are filling your audience's head before you begin. As a speaker, the audience are willing to give you a shot to grab their attention and hold it

  • you have to capitalize on that immediately. Describe the context or use case that brought your main idea to prominence and required solving. Give reasons for your audience to care about this idea. Get them thirsting to hear your explanation of this brilliant new concept. Relate it to other areas - an idea useful in one place likely has uses in many others. By the end of this section of your talk, the audience should be dying to hear the details.

Preliminaries

Now that your audience have a context to put your main idea in, as well as a reason to care, we need to prepare their minds to receive the idea. Computer science, like any other science, is about precision and correctness, and in order to ensure that there is no confusion or needless difficulty with our main idea, we have to make sure that the audience are properly aware of anything they will need to understand it.

While it is OK to talk in generalities and hand-wave when motivating your talk, here, you have to get down to brass tacks. Use as much precision and formality as you think you need, but don't avoid it if it's necessary - after all, we are doing science here, and science needs to be precise. However, avoid defining or explaining what you are not using - every definition, lemma or proof that your audience will need to remember to understand your idea imposes a load on their minds, and it's a load you want to keep as light as is reasonable.

Description

Now comes the fun part - actually describing your main idea! Your audience is now mentally prepared to receive it: give them what they want. Don't forget that your main ideas may need proving; when you need proofs, keep them short and clear. It is fine to refer to the results of others if doing otherwise would be too long or difficult, but a talk about a topic is much stronger if you can demonstrate your own ability to explain or reason, rather than just relying on those of others.

Conclusion

It is now time to 'rise' out of the detailed into the general again. Your big idea has implications and limitations: in order to do good science, we have to tip our hats to both of them. Call back to your motivation when doing both: very few problems are truly ever 'solved', and there are likely many things you could have spoken about, but ended up not, for reasons of time or clarity. Mention important consequences, weaknesses of the methods, their relevance to the world... anything that you think would make your audience want to keep thinking on the main idea and its significance to them.

Construction of the talk

Now that you've thought all those things through, put your talk together. This will be a stop-start process, and might require several revisions; like any kind of writing, it will take some time. Every time you write down more, you will see a clearer picture of what you need to say and how you need to say it. Give it the time and love it deserves.

After that, all that remains is to give the talk!

Five do's

  1. Rehearse your talk at least once, while timing yourself. You'll be amazed what this turns up.
  2. Use slide overlays to focus audience attention. There is nothing more demotivating to a viewer than seeing a slide of text, most of which won't become relevant until much later.
  3. Say stuff that isn't on your slides - that way, people have a reason to listen to you and not just read them!
  4. Keep it simple! Computer science is already an area of deep and complex ideas; don't inadvertently make it harder than it needs to be. Remember the words of John Searle: "If you can't say it clearly, you don't understand it yourself."
  5. Put yourself into your presentation. Think of yourself as an actor or other performer: the audience have come to hear you speak, not just to hear you speak.

Five don't's

  1. Use cues. They limit your connection to the audience, force you to follow a 'script' instead of interacting naturally, and remove spontenaity from your talk. Try it - it's not as scary as it looks if you understand your topic and your slides.
  2. Read what's on your slides. The slides are there to support what you're saying, not replace it. If we can get your entire talk by reading your slides, why even deliver it?
  3. Over-use visual elements. Too many pictures are distracting, and sometimes, text gets the point across better (and your words even more so!).
  4. Have too many slides. The more slides you include, the more your audience has to hold in their heads, and the more you will have to create and edit in the end. A good rule of thumb is one slide per three minutes (not including overlays).
  5. Have slides with too much on them. Over-cluttering slides makes them hard to understand, and clouds the main idea. Remember: on each slide, have one idea and up to four points.

Above all

Have fun! If you don't enjoy the topic or the talk, neither will your audience. Be confident and prepared: from there, enjoy the ride.

License

This document is released under a Creative Commons-Attribution-ShareAlike license, version 4.0. See the LICENSE file for more details.