When I saw the comments pouring in over at my post about content style and public speaking, I decided I’d wait a couple days and then put up a post detailing some of the most interesting responses. It seems that many of my readers are public speakers, and I figured it would be helpful to see some of the arguments laid out in one place, divided between “Pro-Why” and “Pro-How.” I’ll explain more about the two categories in a moment.
First, though, I’m posting the longest comic I’ve ever drawn - practically a graphic novel by my own standards - illustrating why the customer is not always right. This is an old adage which I think goes back to a time when it was your job to let the customer dictate terms to you, making the decisions about your products and services.
It turns out that this is kind of a crazy way to go about things. Most customers are customers because they themselves do not produce the product or service in question, and need someone else to do it. While, as the consumers of these goods and services, they definitely have some real insight on how improvements and additions could be made, they’re limited in some ways.
One limitation on the usefulness of customer input is that a customer will almost certainly make a request for himself without considering the needs of others. This can be quite obvious in jobs like mine where a customer who, for example, works in the underwater welding industry would like to see more presentations on underwater welding and web services. Obviously, this would be of limited use to other people in the audience.
And the list goes on.
So there’s a point at which the person responsible for producing the product or service has to put her foot down and draw the line. Otherwise, things like this might happen…
I also forgot to mention earlier that customers don't always know what's best for them.
The Comments
I’m going to divide the comments into two (2) sections (note as well that I will only be posting selections from the comments, as there were too many to post all of them here):
– Pro Why
– Pro How
My post was a “Pro-Why” post, which is to say that I’m of the opinion that coders should be taught the concepts - the why – behind technologies so that they’re equipped with the knowledge they need to handle many different situations. The other side of the coin is the “Pro-How” camp, where there’s emphasis on code examples that demonstrate how to do something.
Note that these categories aren’t mutually exclusive, and that most people in the comments seem to sit comfortably between the two. What I’m doing here is taking the bits of commentary that lean strongly in either direction, and highlighting them.
In any talk, there is going to be a mixture of both “Pro-Why” and “Pro-How” information, but I’m of the opinion that the majority of useful talks, which is to say talks that will “keep on giving” in many scenarios rather than just the one around which the talk was designed, are the mostest and the bestest.
You may disagree. That’s what the comments section is for.
[Note: Most comments are abridged – each comes with a link to the original so that you can read the thing in its entirety.]
Pro-Why
From David Corun – Comment – His site
I've been doing a lot of training over the past year or so on .NET as well, and it *kills* me to read the eval sheets afterwards and see those same criticisms.
Even w/ small private classes, if you tailor the content directly to their environment you get the same comments.
For some people "real world" apparently means "doing the real work for them".
Indeed it's a fine line between consulting and training.
I’ve hear this argument, and although I don’t think it accounts for the majority of attendees, I do think that there might be some validity to this - that some people show up to find the solution to a specific problem.
That’s strange, though. Coming to a talk in the hopes of finding an answer to a specific problem would be like trying to find a song in your CD collection by listening to every single CD. In both examples, you have some idea of what it is that you’re looking for at first, and seems that it would be wise to do a more targeted search.
From Chris Sells – Comment – His site
duh
The thing about Chris is that he can never shut up – he just drones on, and on, and on, and on, and on, and…
From Joshua Flanagan – Comment – His site
I'm with you, Rory. Give me the concepts. If you demonstrate the concept using a simple Northwind Traders app, I can concentrate on the details of the app. On the other hand, if you tried to create a CRM application in your presentation, and I happened to beworking on a CRM application in the real world, I think I would get distracted by the little decisions you made in your implementation, and get caught up thinking about the details of the app instead of the technology. When you use an obviously contrived example, I can safely put the details of the app out of my brain.
This is a perspective I hadn’t even considered - that someone in the audience could be distracted by a real-world app is an interesting thought.
From Eric Gunnerson – Comment – His site
I don't think it's really an either/or question.
I agree that the conceptual framework is important - some of the most important information that you can give in a talk is the rationale and high-level viewpoint about a subject.
[…]
My preference has always been to keep things simple, so that I can highlight the salient points. "Real-world" details can get in the way.
Eric is absolutely right in that the issue isn’t black and white.
I agree wholeheartedly with his last point – when learning a concept, you don’t want to get bogged down in implementation details.
From Steven Rockarts – Comment – His site
I also know a lot of devs that skip out on the MSDN events because they believe that the events are just marketing BS. Most of the time I attend to get an introduction to the newest technology Microsoft is releasing. If you were to introduce ASP.NET 2.0 to me by building a real world application, all of it would go over my head. It's like someone trying to explain the string theory to a physics newbie.
My expectations are met if not exceeded every time I go. It gets me pumped to go home and try out what I have just learned.
I like the analogy about string theory and physics newbies, although I’d argue that string theory would make about as much sense to a physics newbie as it would to aborigine cut off from society, but that’s just me.
Also, you get twenty bonus points for liking MSDN Events :)
From Yogi – Comment – (no site)
I attend few of the MSDN and TechEd Events. One thing that i think separates a good presenter from a bad one is its improvisation, depending on the audience. If you are giving a presentation on SOA and not more that 40% of your audience have worked in Distribued Application, i dont think it will be a very good idea to load them with too much of Code. But conceptual building will be perfect.
There are lot of Help Docs to look up the code, but what audience wants is to hear the presenter's experience in doing things he's talking about, Best Practices or challenges he faced etc.
This might be one of my favorite comments of the bunch. He’s so completely dead-on about code and relevance, which is to say that, if your audience isn’t already with you conceptually, then you’re going to completely leave them behind when you whip out the semicolons.
Then, Yogi goes home and reads the docs to get the details.
Yogi: I love you.
Pro-How
From DonXML – Comment – His site
I don't know. I've done doing a bit of presenting lately, and I've been using real world examples and getting them in within 60 minutes.
[...]
They think that they have to write every line of code in front of the audience. Why? Do you always start writing a project from scratch? Or do you use a framework of code that you have developed over the years?
Don has a good point here. It’s true that some presenters go way overboard when it comes to live code examples. They’ll start with a blank project and try to make an enterprise-ready app in fifteen minutes. Oddly enough, it doesn’t work.
But, you can do what Don does and work with an existing framework so that you can integrate more of the how into a why talk.
From Rob Johnston – Comment – His site
I would tend to side with the "small examples in a real world context" argument.
For example, when you see a description of delegates and the example given is how two dogs bark you don't really get a good idea of how you are going to apply the concepts. I previously programmed in C and it was the ability to map delegates onto pointers to functions and to think of the examples I had written previously that made the concept of delegates real to me
I’m not entirely in agreement with Rob, but I see what he means. With something as strange as delegates, code is a very good thing. I would argue that the concepts behind delegates are hugely important, but also that the code itself, and the application of the concepts, is just weird enough that it’s going to go over much better if you drive the concepts home with a lot of code slinging.
From John Elliot – Comment – His site
There is a lot of open source code around these days...
Perhaps you could strike a balance between 'real world' and 'conceptual' by explaining the concepts and refactoring an open source codebase to include them?
I.e. go and pick up some product from sf.net or gdn or whatever that is lacking the application of the concepts, but that could do with their application, and then show how to integrate the concepts.
If you can't do that, then I think you'll find that's what your audience is complaining about. That is, there is no 'real world' application for the concepts they've learned that they've been able to identify.
I’m going to remember to file this under “bloody-stinking perceptive.”
John’s last point is excellent (I define “excellent” as anything I haven’t thought of). I wonder if he’s right - that the reason some people want the “real world” app is that they’re unable to map the concepts to implementation on their own.
This is getting pretty damned interesting…
From Jeffrey Palermo – Comment – His site
I've made some of the same comments about MSDN presentations. When I see a UI slapped together with drag n drop with no data validation, and then a "ta da", I'm not impressed. If it were taken one step further and validation was added as well, then I could see that the tool supports something I would actually do.
Design patterns are void from MSDN presentations, and I'm with the people who can't stand it when we are shown "something you wouldn't do in real life". If you are going to do code, then do the code right. If you are going with concepts, then do concepts, and you aren't doing code, so there isn't a chance to present bad code.
Jeffrey is right – when we do demos at MSDN Events, we often skip over doing some thing like data validation.
The reason we do this, though, is that data validation is what we’re trying to teach you - that’s something that, as good developers, you should already be doing. And, if you’re offended by the lack of data validation in our code, then it means that you already have your head on straight, so you’re OK :)
If I were, for example, showing you a sports car, the focus would be on the engine and the car’s performance. I wouldn’t be trying to sell you on the car by showing its cigarette lighter or the glove-compartment.
Also, in my defense, when I have code at my events that’s sloppy in some way (like ad-hoc SQL instead of parameterized queries / stored procedures / etc.), I try to remember to point it out and take thirty seconds to explain the pitfalls. In my opinion, it can be just as useful to explain why something is bad, rather than to teach the proper way to do that thing, but without any explanation at all as to why it’s good (which I’ve certainly seen).
Thoughts?
That’s all I have time for today. I was so pleased with the quantity and quality of comments that I wish I could spend the rest of the day addressing each and every one of them, but I have all these Microsoft people breathing down my neck right now, saying something about how I’m supposed to provide services in exchange for the money they give me. There’s obviously been a misunderstanding somewhere, so if you’ll just excuse me while I go settle this…