Partager via

What makes for a good PDC session?

  • Article

The closer the PDC track team comes to locking down our session list, the more we hear from internal Microsoft platform folks who wonder why their sessions didn't make the cut (or why out of the 10 sessions they proposed, only 1 got approved).  When the track team first started their triages a few months back, they asked me for some guidance they could use to prioritize.  I just stumbled across the mail I sent them, and I thought it might be interesting to paste it here verbatim (or almost verbatim -- any edits are in [brackets]).  If you're wondering what kind of session content you can expect to see at PDC this year, read on...

----

The primary objective of any PDC breakout session must be to help our customers (senior developers and architects) make strategic decisions about how and when they commit to our platform over the next 2+ years.  We want attendees to leave the conference with a clear understanding of the new scenarios we think our platform enables, and confidence that the platform is robust and complete enough to meet their needs.  We also want them to be genuinely excited by our vision, to share in our enthusiasm for our work, and to evangelize our technologies to their colleagues back home.

 

I can envision several different kinds of breakout sessions that would meet the goals above:

  • Broad vision and platform roadmap, covering where we think the industry is going, what the new requirements and needs are for software, and how we plan to build a platform that meets those needs.  I’d expect this kind of content mostly in keynotes and anchor sessions.
  • Specific technology/product roadmap, explaining how and when the functionality in a given piece of our platform will evolve over time, and how we expect it to be used at each stage along the way.  This is mostly anchor and overview sessions, I think.
  • New technology details, reviewing the specific capabilities of new parts of our platform and how they help developers address the scenarios that we think are important.  PDC is billed as our strategic, forward looking event, and this kind of content should make up the bulk of our breakouts.
  • Internals, architecture and robustness, content that explains to attendees how our platform works so that they can be confident it will meet their needs.  In some cases, this may be directly actionable (“here’s how Avalon parses the element tree and load time, so here are three things you should avoid to keep performance snappy”), but in many cases it may be more information sharing (“here’s how Avalon uses Dx, so you can be confident that you will get the graphics performance you need in your Avalon apps”).
  • Best practices and better together, sharing the best information we have on key architectural insights that will help our developers actually succeed in building new scenarios using all the technologies in our platform.

 

Those 5 bullets make for a pretty broad umbrella, so let me scope it back down by adding one more criteria:

  • Content should be presented at PDC because it is the only appropriate forum – it is so advanced that it requires the person who spec’d and built the technology to present it in person to the architect who’s going to try to use it.

To me, that means the following kinds of breakout sessions are not appropriate for PDC

  • Training and “how-to” sessions.  Our breakout sessions are not intended to be simple “here’s how to use this class, here’s how to use that class” training sessions.  If your content is covered in the SDK docs, it’s not appropriate for PDC
  • [I removed another point here that focused on some internal politics -- I don't think it makes sense to include publicly]
  • Sessions on shipping technology.  We generally assume that anything shipping within a few months of PDC is going to be exhaustively documented via books, whitepapers, outside training classes, etc.  There will be some key 400-level sessions on internals/architecture that can only be given at PDC, and we do want to include those, but for the most part a 300-level or lower session on shipping technology doesn’t belong at PDC.
  • Content that was covered at TechEd.  TechEd is all about training on today’s technology – it’s almost a given that a talk [presented] at TechEd is not a fit for PDC (and vice-versa).
  • IT pro and end-user content.  Our audience is [mostly] developers, and so we focus our content towards that audience.

 

Another way to evaluate potential sessions is to think of what level content is being proposed.  PDC is a technical conference, and we want to see at least 25% of our content at the 400-level this year.  Here’s how I described levels at our first track team meeting in April:

  • 200 level (generally anchor and overview sessions)
    • Focuses on broad technology overview
    • Emphasizes capabilities, scenarios and value
    • Simple code samples to make a point
  • 300 level (generally scenario sessions)
    • Focuses on demonstrating how to implement a solution
    • Detailed code samples and architecture to show how it all fits together
  • 400 level (generally deep technical internals sessions)
    • Focuses on internals, the how and why
    • Emphasizes internal architectural considerations and decisions and how they impact real-world usage
    • Code samples that illustrate the behavior of the component

Comments