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.