Am I right, or are you right? (Please read the rest of this post before you respond (unless you plan to be really funny, in which case you should feel free to begin commenting immediately))
My Opinion
As someone who basically talks for a living, I’ve spend a good deal of time thinking about what the best way to give talks might be.
A very common criticism on the evaluation forms that we presenters get following an MSDN Event is that the content wasn’t “real world.” By “real world,” attendees are often referring to the code in the demos. We aren’t writing or presenting “real” applications during our talks.
I’ve given presentations both ways – some with real world stuff, and some with just enough code to get the point across, and I’ve pretty much made up my mind: Generally speaking, I think that the talks which deal with least amount of code possible are the best. That is, I believe that talks which lean toward the conceptual end of things are much more valuable than talks which lead toward the implementation end. Details and implementation are, I think, best served by articles and books.
As if that weren’t enough, I even have reasons for believing so.
1) Your average talk lasts about an hour – the likelihood of the presenter being able to write a full blown app in this kind of time is obviously ludicrous, but I would also argue that it would be very difficult to get anything particularly meaningful out of an already written large app in this time either. The benefit of learning from a large app is understanding how all the bits fit together to make the whole. In talks, short as they are, you really just wind up learning about a few isolated components of the app, and receive little understanding about how they really alter the codebase.
2) As an audience member, you are not going to walk away from a talk that was end-to-end code with a clear memory of what happened. I’ve been to enough conferences and seen all the slack-jawed faces in the audience to know that there are definitely limits to what can be absorbed in an hour. It’s way too much detail. Even with a photographic memory, you’d still have to pay attention to everything and then attempt to digest it at a later time.
3) Without a conceptual framework upon which to build, there isn’t anything to which knowledge of the code can stick. Take Code Access Security for example – if you try to wrap your head around CAS by coding before trying to understand the system behind it, then you’re asking for trouble. If, then, you go to a talk on CAS, you should expect a large portion of the talk to be context-building, but my bet is that devs attending a CAS talk in which there is little code will walk out complaining.
4) Brushing large issues like CAS aside, consider the smaller things: Surely, they could be understood without a context? Sure - but if they’re that simple, then why don’t you just look at the API docs? Why even go out of your way to attend a talk?
That’s just some stuff off the top o’ the head. It’s been brewing for a while now, and even before the current job.
What do you think? Am I smoking the speaker-crack? I know that the vogue nowadays is “No Powerpoint,” but that shouldn’t necessarily have to mean “All Code.”
Anyway, just some thoughts on an afternoon in Boulder, Colorado…
(On a side note, have you ever spent so much time in VS.NET that, once out of it and in another application (like Word or something), you do silly things like hit ctrl+shift+b to compile the blog post you’re working on?)
After Blog Mint [?] :
Miki Watts has some good points about The CodeRoom (problem solving vs. pontificating). If you have any ideas for The CodeRoom, then feel free to email me – I’d honestly love to hear from you (I think – I could be wrong, though, but we’ll try it and see what happens).