Technical Presentations and Understanding the Little Things
Today I attended a technical presentation on a domain-specific implementation of some software and a deployment process. The subject matter was relevant to my work, and I watched with interest. While the presentation was, to some degree, dominated by discussion from other attendees rather than pure explanation, I followed along as best I could, even during times when the discussion being raised was not relevant to me or something I already understood.
During the portions of the presentation that were explanation, however, I noticed an interesting trend, and when things went off on tangents, I began to philosophically ponder this trend. What I noticed was that most of the explanation was procedurally oriented and that lot of other presentations tended to be like this as well.
This is what we do…
When I say “procedural,” I mean that people often give presentations and explain in this context: “First we do X, then we do Y. Here are A, B, and C, the files that we use, and here are D, E, and F, the files that we output.” This goes on a for a while as someone explains what, in essence, amounts to their daily or periodic routine. Imagine someone explaining how to program: “First, I turn on my computer, then I log in, then I start Ecplise, but first, I have to wait a little while for the IT startup scripts to run. Next…”
Generally speaking, this is boring, but not always. That depends on the charisma of the speaker and the audience’s level of interest in the subject. However, boring or not, these sorts of checklist explanations and presentations are not engaging. They explain the solution to a problem without context, rather than engaging the audience’s brain to come up with solutions along with the presenter and eventually to conclude that the presenter’s approach makes the most sense in context. The result of such a procedural presentation is that you brainlessly come to understand some process without understanding why it’s done, if it’s a good idea, or if it’s even coherent in any larger scheme.
Persuasive Instead of Expository
Remember speech class? I seem to remember that there were three main kinds of speeches: persuasive, expository, and narrative. I also seem to remember that expository speeches tended to suck. I think this holds true in the format of technical presentations in particular–this describes the procedural presentation I mentioned earlier, which basically boils down to the format “A is true, B is true, C is true, D is true.” Perhaps that seems like an oversimplification, but it’s not, really. We’re programmers, right? What is the logical conclusion of any presentation that says “We do X, then we do Y, then we do Z”?
So, I think that we ought to steer for anything but expository when presenting. Narrative is probably the most engaging and persuasive the most effective. The two can also be mixed in presentation. A while back, I watched some of Misko Hevery’s presentations on clean code. One such presentation, in particular, that struck me as effective had to do with singletons (he calls them pathological liars). In this talk (and in the linked post), he told a story about setting up a test for instantiating a credit card object and exercising its “charge()” method only to find out that his credit card had been billed. This improbable story is interesting and it creates a “Really? I gotta hear this!” kind of feeling. Audience members become engaged by the narrative and want to hear what happens next. (And, consequently, there are probably fewer tangents, since unengaged audience members are probably more interested in quibbling over superior knowledge of procedural minutiae.)
Narrative is effective, but it’s limited in the end when it comes to conveying information. At some point, you’re going to need to be expository in that you’re relating facts and knowledge. I think the best approach is a persuasive one, which can involve narration and exposition as well. That is, I like (and try to give) presentations of the following format: tell a story that conveys a problem in need of solution, explain the “why” of the story (i.e. a little more technical detail about what created the problem and the nuts and bolts of it), explain early/misguided attempts at a solution and why they didn’t work, explain the details of my end solution, and persuade the audience that my solution was the way to go.
This is more or less the format that Misko followed and I’ve seen it go well in plenty of other presentations besides. It’s particularly effective in that you engage the audience, demonstrate that you understand there are multiple possible approaches, finally persuade the audience that your approach makes sense, and that they would eventually have figured this out on their own as well because, hey, they’re intelligent people.
Why This Resonates
As the presentation I was watching drifted off topic again via discussion, I started to ponder why I believe this approach is more effective with an audience like developers and engineers. It occurred to me that an explanation of the history of a problem and various approaches to solving it has a strong parallel with how good developers and engineers conduct their business.
Often, as a programmer, you run across someone that doesn’t understand anything outside of the scope of their normal procedure. They have their operating system, IDE, build script, etc, and they follow a procedure of banging out code and seeing what happens. If something changes (OS upgrade, IDE temporarily not working, etc), they file a support ticket. To me, this is the antithesis of what being a programmer is about. Instead of this sort of extreme reactive behavior, I prefer an approach where I don’t automate anything until I understand what it’s doing. First, I build my C++ application from the command line manually, then I construct a makefile, then I move onto Visual C++ with all its options, for instance. By building up in this fashion, I am well prepared for things going wrong. If, instead, all of the building is a black box to someone, they are not prepared. And if you’re using tools on the machine blissfully ignorant as to what they’re doing, can you really say that you know what you’re doing?
However, I would venture a guess that most of the people who are content with the black box approach are not really all that content. It might be that they have other things going on in their lives or a lack of time to get theoretical or a number of other things. Perhaps it’s just that they learn better by explanation as opposed to experimentation, and they would feel stupid asking how building the application they’ve been working on for two years works. Whatever the case may be, I’d imagine that, all things being equal, they would prefer to know how it works under the hood.
So, I think this mode of speech-giving appeals to the widest cross section of programmers. It appeals to the inveterate tinkerers because they always want, nay, demand, to know questions like “why” and “how” instead of just “what.” But it also appeals to the go-along-to-get-along type that is reasonably content with black boxes because, if they’re attending some form of training or talk, they’d rather know the “why” and “how” for once.
I’d encourage anyone giving a technical talk to keep this in mind. I think that both you’ll feel better about the talk and your audience will be more engaged and benefit more from it. Tell a story. Solve a problem together with the audience. Demonstrate that you’ve seen other ways to approach the issue and that you came to the right decision. Generally speaking, make it a collaborative problem solving exercise during the course of which you guide the audience to the correct solution.