Talks

Talks are another form of communication with your colleagues, and most of what we said about writing is true of talking also. An ability to stand in front of an audience and give a talk that doesn't make the audience fall asleep is crucial for success in terms of recognition, respect and eventually a job. Speaking ability is not innate-you can start out graduate life as a terrible public speaker and end up as a sparkling wit so long as you practice, practice, practice, by actually giving talks to groups of people.

Some ways to learn and practice speaking:

Patrick Winston has a great short paper on how to give talks. He also gives a lecture based on it every January which simultaneously illustrates and describes his heuristics.

If you feel you are a bad speaker, or if you want to be a good one, take a course on public speaking. An intro acting class is also useful.

If your advisor's students have regular research meetings, volunteer to talk about your stuff.

The MIT AI lab has a series of semiformal talks known as the Revolving Seminar. Volunteer to give one if you have something worth turning into an AI memo or a conference paper.

Learn enough about the Lab's various robotics projects so when your relatives or friends from out of town come you can give them a tour and a little 60 second talk in front of each robot about it. (Your relatives and non-AI friends will usually love this; they won't be so impressed by the intricacies of your TMS.)

Since revising a talk is generally much easier than revising a paper, some people find that this is a good way to find the right way to express their ideas. (Mike Brady once remarked that all of his best papers started out as talks.)

Practice the talk in an empty room, preferably the one in which you will deliver it. Studies of context effects in memory suggest that you will remember what you are going to say better if you have practiced in the room you deliver in. Practice runs let you debug the mechanics of a talk: what to say during each slide, moving overlays around smoothly, keeping notes and slides synchronized, estimating the length of the entire talk. The less time you spend fumbling around with your equipment, the more time you have left to communicate.

Practicing with a mirror or tape or video recorder is another alternative. The lab has all three. They might help debug your voice and body language, too.

For a relatively formal talk-especially your Oral Exam-do a practice run for half a dozen friends and have them critique it.

Watch the way other people give talks. There are a lot of talks given by people visiting MIT. Attending such talks is a good way to get a taste of areas you aren't so familiar with, and if the talk turns out to be boring, you can amuse yourself by analyzing what the speaker is doing wrong. (Going to a seminar is also a way to cure the mid-afternoon munchies)

Cornering one of your friends and trying to explain your most recent brainstorm to him is a good way both to improve your communication skills, and to debug your ideas.

Some key things to remember in planning and delivering a talk:

You can only present one ``idea'' or ``theme'' in a talk. In a 20 minute or shorter talk the idea must be crystal clear and cannot have complicated associated baggage. In a 30 or 45 minute talk the idea can require some buildup or background. In an hour talk the idea can be presented in context, and some of the uglies can be revealed. Talks should almost never go on for more than an hour (though they often do).

The people in the audience want to be there; they want to learn what you have to say. They aren't just waiting for an excuse to attack you, and will feel more comfortable if you are relaxed.

Take at least one minute per overhead. Some people vary in their rate, but a common bug is to think that you can do it faster than that and still be clear. You can't.

Don't try to cram everything you know into a talk. You need to touch on just the high points of your ideas, leaving out the details.

AI talks are usually accompanied by overhead transparencies, otherwise known as ``slides''. They should be kept simple. Use few words and big type. If you can't easily read your slides when you are standing and they are on the floor, they're too small. Draw pictures whenever possible. Don't stand in front of the screen. Don't point at the overhead if it is possible to point directly at the screen. If you must point at the overhead, don't actually touch the transparency since you will make it jerk around.

A whole lot of people at MIT