What makes a good PDC session?

I just got an email asking me what makes a great PDC session.  What should we tell speakers to remember in every session?  A couple of ideas came to mind immediately:

 

•          Make it readable – use large enough fonts

•          Make sure you know the top 3 things everyone in the audience should walk away remembering

•          Remember…it’s a developer audience…and they want code.

•          Assume managed code knowledge

•          Balance use of  C#  and VB…. Use MC++  as appropriate..

 

And of course, we should remember these wise words: Tips for a Successful MSFT Presentation.

 

Then I thought I’d ask you folks – what do you value?  What gets you to give high marks on the session survey?  (we take that very seriously you know)..

 

Published 26 September 03 09:39 by BradA
Filed under:

Comments

# Martin Spedding said on September 26, 2003 10:45 AM:
I would say : (1) Don't make it dry and add some humour if possible (2) Give insight why certain decisions were made (3) Give practical real world examples and a guide how you can implement what you have just learnt. Even though the technology is not being shipped now you still want to know how you will use it. (4) Ensure that the audience get more from the presentation than they would by simply reading the slides. (5) Like a story, have a beginning, a middle and an end and clearly indicate to the audience where you are in the presentation.
# Ivan Towlson said on September 26, 2003 12:31 PM:
(1) Big picture. I can read the documentation for the details, what I need is the context to make sense of those details, the mental roadmap to lead me to the details when the time comes. (2) The whys and wherefores. The "philosophy" that guided the design. The problems you were trying to solve or the opportunities you were trying to create. (3) Make it concrete. The documentation is likely to be full of abstractions. Make them come alive for me, so I can relate the abstract stuff back to something I've seen working and in context. (4) Accept that some demos will break. Be ready for it and have a "next best thing" in reserve. Don't get hung up on trying to fix the demo if it's going to take too much precious time. Unfortunately what works for me will completely frustrate other people (say, people who learn by building up from specific details); and vice versa. Good luck!
# Fumiaki Yoshimatsu said on September 26, 2003 8:24 PM:
As I wrote in my blog entry, why is important than what and how. For PDC it is more important than for the other event, because the bits that are discussed in the PDC is still young and pre-mature.
# Joseph Shook said on September 26, 2003 10:12 PM:
I like to have my hands on the code instantly. If it is in a packet ahead of time, great. If not then make it available via wireless or hard lan either during or very soon after the presentation. Sometimes my mouse and keyboard really help the brain matter retention process.
# Simon Stewart said on September 28, 2003 8:25 AM:
Some great comments above! 1) Be opinionated. Give your 2 cents on the technology you are talking about. 2) Don't read the slides. Rather use those as a basis for general conversation with audience. They can use the decks for further info. 3) Demos are great, but talk about some of the issues you had in building it and the decisions you made. 4) Would recommend sticking to one dev language per presentation. 5) Include "call to action" and "further reading" slides. 6) Include sample code in download pack or include link to download in slide deck.
New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)

These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker