<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>What makes a good PDC session?</title><link>http://blogs.msdn.com/b/brada/archive/2003/09/26/50385.aspx</link><description>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</description><dc:language>en-US</dc:language><generator>Telligent Evolution Platform Developer Build (Build: 5.6.50428.7875)</generator><item><title>RE: What makes a good PDC session?</title><link>http://blogs.msdn.com/b/brada/archive/2003/09/26/50385.aspx#50390</link><pubDate>Sun, 28 Sep 2003 15:25:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:50390</guid><dc:creator>Simon Stewart</dc:creator><description>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 &amp;quot;call to action&amp;quot; and &amp;quot;further reading&amp;quot; slides.
6) Include sample code in download pack or include link to download in slide deck.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=50390" width="1" height="1"&gt;</description></item><item><title>RE: What makes a good PDC session?</title><link>http://blogs.msdn.com/b/brada/archive/2003/09/26/50385.aspx#50389</link><pubDate>Sat, 27 Sep 2003 05:12:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:50389</guid><dc:creator>Joseph Shook</dc:creator><description>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.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=50389" width="1" height="1"&gt;</description></item><item><title>RE: What makes a good PDC session?</title><link>http://blogs.msdn.com/b/brada/archive/2003/09/26/50385.aspx#50388</link><pubDate>Sat, 27 Sep 2003 03:24:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:50388</guid><dc:creator>Fumiaki Yoshimatsu</dc:creator><description>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.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=50388" width="1" height="1"&gt;</description></item><item><title>RE: What makes a good PDC session?</title><link>http://blogs.msdn.com/b/brada/archive/2003/09/26/50385.aspx#50387</link><pubDate>Fri, 26 Sep 2003 19:31:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:50387</guid><dc:creator>Ivan Towlson</dc:creator><description>(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 &amp;quot;philosophy&amp;quot; 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 &amp;quot;next best thing&amp;quot; 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!&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=50387" width="1" height="1"&gt;</description></item><item><title>RE: What makes a good PDC session?</title><link>http://blogs.msdn.com/b/brada/archive/2003/09/26/50385.aspx#50386</link><pubDate>Fri, 26 Sep 2003 17:45:00 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:50386</guid><dc:creator>Martin Spedding</dc:creator><description>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.&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.msdn.com/aggbug.aspx?PostID=50386" width="1" height="1"&gt;</description></item></channel></rss>