Live Coding in Presentations – Don’t Waste my Time!

Over the years I have grown very sceptical of the “fewer slides, more demos” kind of presentations. I simply have seen too many presentations where things went downhill from the moment the speaker opened Visual Studio.

In an internal presentation or at a user group meeting this is “unfortunate”. But if I fly halfway around the globe and then have to sit through such a talk, I might get a little upset (MIX11 WP7 boot camp, I’m looking at you).

Dear speakers, if you plan to give a talk that contains any kind of “live” usage of Visual Studio, I kindly ask you to keep a few things in mind.

First of all: Even though we developers work with Visual Studio every day, you have to be fully aware that using Visual Studio in front of an audience poses a significant risk:

• Every bit of mistyping or misclicking is a distraction on the way from what you just said to what you wanted to show.
• At some point, Visual Studio will make you and the audience wait for something to complete.
• Visual Studio or some other technology may decide to stop working at the worst possible moment. In contrast, I cannot remember a crash of PowerPoint in any talk I’ve ever seen.
• When writing code you may make mistakes that result in build errors – another distraction that disturbs the flow of your explanations.

It is your job to minimize these risks. Everything that doesn’t work as expected is wasting the audience’s time. If you manage to recover quickly from problems, good for you. But solving an unexpected problem in a demo remains a distraction unless you specifically planned to show the solution to that problem.

Also be aware that what you see differs significantly from what the audience sees. You may see the five important lines of code or the three files that were just added to the project. The audience sees an IDE with lots of panes covering the whole screen, interesting menu and toolbar items from plugins, the full project structure inside the Solution Explorer, and lots of source code besides the few lines you are currently talking about.

Note that even with all these problems, I’m not advocating “all-slides” talks for programming topics. I have seen quite a few talks with a very effective usage of Visual Studio. All these had in common that the speakers had a good idea of when to use Visual Studio and when to rely on prepared slides.

What exactly are you trying to show inside Visual Studio?

• The “discoverability” of an API by showing Intellisense on it: Great!
• The values of some object properties at specifc breakpoints in a debugging session: Great!
• How easy it is to build something within minutes: Ok, but think about choosing a staggered approach of first coding some parts manually, then using code snippets to avoid repetitions, later maybe even using prepared code files if the audience can imagine they contain “more of the same”.
  Note that you start losing parts of your audience if you have to scroll a lot; some people may tune out and simply wait for you to hit F5.
• Some files that were generated: If you’re already inside Visual Studio, just want to show that they were generated and will move on after a brief glance at their content (“see: here’s XML and here’s C# code”): OK.
  If you have to explain their exact purpose and their relationsships, think about preparing slides. A screenshot of (a part of) the Solution Explorer not only helps to focus on the files, it also allows you to highlight them and add call-outs that support what you are saying.
• Features of the Visual Studio UI like dialogs, customization options, etc.: If you have to switch to Visual Studio just for that, better use one or more screenshots. Highlight important details and/or add call-outs.
• Some code that is already complete: It depends. What part should the audience actually remember? Would it be possible to put that code on a slide? If there’s a chance, use the slides. And again: focus of attention, highlighting of important parts, call-outs for explanations.
  If you have to show the code inside Visual Studio, practice finding the locations instantly. Don’t stumble through file after file on stage just to notice you’re in the wrong project.

Each of your demos can be split into the following parts; think about where and how you deal with them:

• Preparation – you have to set up the environment before (the key part of) the demo can be started.
• Establishing context – you have to give the audience enough information to understand what you will show them.
• Show – demonstrate what the audience should see happen live.
• Summary – explain what the audience just saw.
• Conclusion – explain what the main takeaways are.

In all really good presentations that I have seen, little or no preparation was visible to the audience (i.e. all required projects were loaded before the talk started), unless it was actually part of the demo. And the speakers used slides during the “context”, “summary” and “conclusion” phases (instead of having the IDE open and just talking), which kept them focussed.

But this sounds like a lot of work?!

Because it is. Good presentations are a lot of work. Regardless of whether you are using slides or Visual Studio. Just look at e.g. the live coding by Scott Hanselman during the MIX11 keynote. Don’t think for a second that he did this without lots of preparation and practice.

Whenever you enter the stage at a conference, I expect that you are highly prepared and invested a lot of time into your presentation, period. Otherwise you’re wasting my time – with or without live coding.