33
Giving Technical Talks Jaspal Subhlok How to avoid making some of the mistakes that I have made Entirely based on a talk by Scott Drysdale, Dartmouth

Giving Technical Talks

  • Upload
    sorley

  • View
    45

  • Download
    0

Embed Size (px)

DESCRIPTION

Giving Technical Talks. Jaspal Subhlok How to avoid making some of the mistakes that I have made Entirely based on a talk by Scott Drysdale, Dartmouth College. Overview. Why are you Giving a Talk? How to Organize a Talk Some More Detailed Advice Ten Commandments Seven Deadly Sins - PowerPoint PPT Presentation

Citation preview

Page 1: Giving Technical Talks

Giving Technical Talks

Jaspal Subhlok

How to avoid making some of the mistakes that I have made

Entirely based on a talk by

Scott Drysdale, Dartmouth College

Page 2: Giving Technical Talks

Overview

• Why are you Giving a Talk?

• How to Organize a Talk

• Some More Detailed Advice– Ten Commandments– Seven Deadly Sins

• Conclusions

Page 3: Giving Technical Talks

Acknowledgements:

• Many of these ideas from a paper by Ian Parberry:– http://hercule.csci.unt.edu/ian/guides/

speaker.html

• and a talk by Bill McKeeman– http://www.gorillaman.com/mckeeman/

writings/presentation/

Page 4: Giving Technical Talks

Your Reason for Giving a Talk

• Somebody is making me do it.• I want to impress the audience with my

brilliance.• I want to get a job.• I want the audience to understand this piece

of research.• I want to detail everything I know on the

subject while someone is still listening

Page 5: Giving Technical Talks

A technical talk is great for conveying:

• context– What has been done before?– Why is the research important?– What problems are still open?

• An overview and framework– What does this research contribute?– What methods were used to solve problems?

• Enthusiasm and excitement

Page 6: Giving Technical Talks

A technical talk is a poor way to convey:

• Nitty-gritty details

• Lots of factual information

Page 7: Giving Technical Talks

The Parts of a Technical Talk

• Introduction

• Body

• Technicalities

• Conclusion

Page 8: Giving Technical Talks

Introduction

• Define the problem

• Motivate the problem and hook audience

• Introduce needed terminology

• Discuss earlier work

• Explain the contributions you will present

• Provide a roadmap for the rest of the talk

Page 9: Giving Technical Talks

Body

• Outline the major results of your work

• Explain the significance of the results

• Sketch a high-level explanation or proof or justification of your results

Page 10: Giving Technical Talks

Technicalities

• Present a key lemma or idea

• Discuss it in detail

• This is where you convince people that what you have done is not trivial and has some depth and difficulty.

Page 11: Giving Technical Talks

Conclusions

• Summarize the key points

• Make observations that would have been confusing to make before the audience heard the talk

• Give open problems

• Indicate that the talk is over

Page 12: Giving Technical Talks

Who is your Audience?

• General public

• CS folks (e.g. colloquium)

• CS folks in your area (e.g. seminar class)

• Experts in the exact area of your research (e.g. research group meeting)

Page 13: Giving Technical Talks

General Public

• Concentrate on Introduction

• Body presented at a high level

• Eliminate Technicalities

Page 14: Giving Technical Talks

CS Folks

• Introduction important

• Substantial Body

• Skimpy Technicalities

Page 15: Giving Technical Talks

CS Folks in your Area

• Can cut back on Introduction

• Meaty Body

• Moderate Technicalities

Page 16: Giving Technical Talks

Experts in your exact area of research

• Skimpy Introduction

• Meaty Body

• Meaty Technicalities– May discuss more than one idea or lemma

Page 17: Giving Technical Talks

The Ten Commandments

• Know your material• Communicate the key

ideas• Use logical order• Concrete examples

before abstract ideas• Size talk to the time

• Maintain eye contact• Maintain ear contact• Simple visuals• Quality over quantity• Practice your talk in

full before people

Page 18: Giving Technical Talks

Use Logical Order

• You are telling a story. What order will make the best sense to the audience?

• Avoid forward references

• Motivate each step, tie it back to the overall outline

• Remember that the audience is not as familiar with the material as you are!

Page 19: Giving Technical Talks

Concrete Examples before Abstract Ideas

• Compare– I will now prove that if m|a and n|a and

gcd(m,n) = 1, then mn|a.

• To– Suppose 3|a and 5|a. Does 15|a? (a = 15, 30..)– Suppose 6|a and 9|a. Does 54|a? (a = 18,36,54)– Under what circumstances does m|a and n|a

imply that mn|a?

Page 20: Giving Technical Talks

Size Talk to Time

• Leave time for audience interaction

• Plan to end at least 5 minutes early

• Plan what to leave out if you get behind

• You can’t include everything - keep the most important stuff and cut the rest

Page 21: Giving Technical Talks

Maintain Eye Contact

• It is a way to communicate

• It is how you tell if the audience is following, lost, bored, etc.

• Talk to your audience - don’t read your talk, talk to your feet, talk to the screen

Page 22: Giving Technical Talks

Maintain Ear Contact

• Speak slowly (but not too slowly)

• Speak clearly

• Project your voice

• Pause after delivering a packet of information or asking a question

Page 23: Giving Technical Talks

Simple Visuals

• Make sure that the text is large enough to read

• The purpose of the slide is to give the audience a structure, as something to jog their memory as to the point you are trying to make, or as a concrete expression of a formula, etc. It should not be a verbatim transcript of what you are saying. If you are saying exactly what is on the slide then you are doing something wrong.

Page 24: Giving Technical Talks

Simple Visuals

• One picture (graph, diagram) can be worth 1000 words

• Try out the projection equipment, overhead, or whatever before the talk

• Think about what you will do if the equipment does not work

Page 25: Giving Technical Talks

Simple Visuals

• Too many sspecial effectss, fonts, colorscolors, etc. make slides hard to read and understand and distract from youryour talk.

Page 26: Giving Technical Talks

Seven Deadly Sins

• Getting bogged down in details• Going over your time• Trying to include too much• Being boring• Speaking unintelligibly• Arrogance• Losing your audience• Including material you don’t really understand

Page 27: Giving Technical Talks

Trying to include too much

• Symptom - Time almost up and you are half way through your talk

• Symptom - Tearing through slides faster than the audience can read them

• Symptom - Too many slides. Plan on at least two minutes per slide.

• Disaster - you left the most important stuff to the end, and are out of time

Page 28: Giving Technical Talks

Being boring

• Presentation is a public performance

• You have to be energetic, animated, enthusiastic. (You can overdo this.)

• If you don’t seem to be interested, why should your audience be interested?

• If you find the material boring, so will your audience. Pick more interesting material.

Page 29: Giving Technical Talks

Speaking unintelligibly

• Don’t mumble

• Don’t talk in a monotone

• Don’t use jargon or undefined terms

• Don’t swallow your words or endin...

• Avoid mannerisms that distract your audience from what you are saying

Page 30: Giving Technical Talks

Arrogance

• The fact that you know more about your talk than the audience does not make you superior to them.

• Don’t put down or belittle questioners

Page 31: Giving Technical Talks

Losing your audience

• Over their heads (slow down, back up)

• Beneath their interest (get to the good stuff)

• Too big a step (go back and fill in details)

• Not enough relevant examples

• Loss detector: eye contact

Page 32: Giving Technical Talks

Conclusions

• You can learn to give good talks

• Plan and organize your talk

• Think from the audience’s point of view

• Follow commandments, avoid sins

• Practice! Get feedback. Get better.

Page 33: Giving Technical Talks

Paper Critique• A typical review usually contains:

– Summary: Please summarize the paper briefly – Positives: What are the most important reasons to accept this paper, in

order of importance?– Negatives: What are the most important reasons NOT to accept this

paper, in order of importance? (e.g., the paper has serious a) technical mistakes, b) isn't novel, c) doesn't demonstrate its point by proofs, simulations or experiments, makes very unreasonable assumptions, etc.) If the overall conclusions are still likely to hold despite these flaws, please say so. Say whether the negatives dominate the positives

– Rating (out of 5)– How to improve?