With PDC coming up, there have been lots
of Microsoft entries about what makes a good presentation, and I’d like to throw
my 35 cents into the discussion. Here are three things I like to keep in mind.

Why is always more important than what

Technical people are smart and used to figuring out things on their own. They can
figure out the C# property syntax in their sleep. What they can’t figure out is what
was going on in your mind when you wrote a feature, and knowing that is the most
important part.

This is also critical for connecting with your audience. Showing some code and saying,
“have you ever had to write ugly code like this?”, and then showing the improvement
will always garner a good response (assuming that the feature is actually useful).
It’s your job to provide the connection between the feature and the problem it solves.

What you don’t talk about is more important than what you do talk about

Technical topics always have lots of subtle and interesting points that you could
talk about. Understand the difference between what you could talk
about and what the audience needs to know, and stick with the simplest scenario to
start with. I’ve seen lots of presentations where the speaker throws in “interesting”
asides that merely confuse the attendee.

To put it another way, your job as a speaker is to filter the important information
out of all the possible information. If you don’t filter out the irrelevant details,
your attendees won’t know whether they should understand that information. That will
1) leave them thinking about your previous aside when you want them thinking about
the topic you’re now discussion and 2) make them feel stupid.

Your job is not to display your technical mastery of the subject. I don’t, for example,
talk about the advanced events syntax when I talk about C# events. It’s not relevant
information.

Get concrete fast

Real world examples always beat abstract ones. Don’t spend time on introductions when
you could explain it as part of a real-world example, or show as part of a demo

Iterate and embellish

Most topics have several layers to them, either layers of complexity or ordered layers
of discussion. In properties, for example, I would first show the world without properties,
discuss the problems, and then show the world with properties. A building-block approach
is easier for people to understand, and it builds the progression into the presentation
so you can’t forget it.

I once came across a presentation guide that suggested not using revelation in presentations
(revelation is when points are gradually revealed). If you’re going to present effectively,
you need to be able to focus the discussion on a specific point, and you do this through
revelation. If you have three main points on a slide, and you show them all at once,
your audience will be reading the second and third points while you’re talking about
the first. You want them listening to you instead.

Revelation combined with diagrams can be a tremendous learning aid. A good diagram
is worth at least 2^10 words. Consider whether you can express points graphically.

Finally, I have a personal reason for liking revelation. One of the reason I
emjoy presentating is the comedic potential, and an essential element of humor
is timing. The funny part of the slide usually isn’t the first part, and
if you don’t use revelation, everybody gets to it at different points – if they
notice it at all. You want the impact to hit them all at once, and that’s why you
use revelation.

Final Thoughts

You should also read Conference
Presentation Judo by Mark-Jason Dominus. If you presented before,
this is a phenomenally useful presentation. Make sure you read the notes along
with the slides.

And if you’re a Microsoft person who wants somebody to comment on your slides, I might
be amenable.