Daniel Moth has written a post called The ABCDEFGHI of setting up Visual Studio for Demos. Some of his points are great. Things like using the default colour scheme, larger fonts and maximizing the screen are bang on.
Other points that he lists I'm more ambivalent about. I really don't think that changing the tab key to be two spaces is really going to gain you enough horizontal space to make a difference. If you're so deep into nested logic of any kind that your code is falling off the side of the page, you should probably be rethinking your code structure.
Still more of the points Daniel makes I disagree with completely. First and foremost, we presenters are up there to convey ideas within a realm of perceived knowledge and skill. If you're on stage presenting I guarantee you that there will be people (probably a lot) who are in the audience that see you as an omnipotent coder.
If you ignore that fact and start working or writing code in a way that is not following best practices, these people will leave thinking that it's okay for them to do the same the following day at work. When that happens, you've just killed a puppy. Developers around the world have had their skills set back because of seemingly innocuous incidents like this.
When I'm writing code during a presentation, no matter it's topic, I'm a spokesman for good coding practices. That includes code design, code structure, tools and personal (developer) processes. It's incumbent for the few of us that have the stage and the audience in earshot to ensure that we are working to do more than just spew out the most recent technology. We have to convey the topic at hand in a way that people can see better ways of doing things at the same time.
I, for one, will never again present without my productivity tools installed in the IDE. For a while this past year I was doing presentations on the new language features in .Net 3.5 without ReSharper. I disabled v3.1 of ReSharper because it added clutter to the screen when it found language features that it didn't know how to handle. Like Bil says here, you never looked like a bigger fool as when you repeatedly, in every presentation, catch yourself trying to introduce a variable, going to definition, or some other shortcut that I was used to. I was quite embarrassed to have to say, in every one of those presentations, that "..I'm so used to using ReSharper...one second while I figure out how to do this."
Turning off your productivity tools gives the audience a false sense of the real world. I don't know of a single developer worth his/her salt that doesn't use ReSharper or Coderush or some other tool in their day to day work. We do it because it makes sense. Yes there are things on the screen that will cause members of the audience to ask questions not related to your presentation. A simple request to come and ask you after is how that can be addressed, and you're free to carry on with the show. If you're worried that constantly hitting Ctrl-Alt-V to introduce a variable with ReSharper is going to confuse your audience, then take to talking them through what you're doing while you do it. "Let's create a new variable for the Foo object....new Foo...Ctrl-Alt-V to introduce the variable...Tab over the Type and Tab to accept ReSharper's recommended name." Not so hard is it? Not only does it not distract greatly from the presentation, it gives the audience a little something else to take home and think about.
While productivity tools are a reality of modern development, so too are best practices. Daniel suggests, in item H, to remove the namespace declaration and it's related curly braces. Fantastic. In every file that we open we have now saved 3 lines vertically. For those three lines, we've just suggested to the audience that namespacing isn't important. We've created a "Don't do this in production code" moment. Nothing pisses me off more than hearing or feeling that I have to vomit out that statement. It's ridiculous. Why are you doing it then? To save 3 lines of space? Fan-fucking-tastic. What's next, eliminate the blank lines so that we can recover some more space? Thanks for making the code unreadable.
Coding best practices have been categorized as such because they should be universally adopted. We presenters should never assume that the entire audience understands and fully appreciates these practices. If you're going to get up in front of a group of people and talk about car safety, but when you demonstrate the proper hand location on the wheel you don't put on the seatbelt, then you'd better damn well be prepare for people to assume that the previously taught seatbelt lesson really isn't as important as you claim it to be.
Not everyone knows best practices. Not everyone knows patterns. Not everyone knows good coding standards. Not everyone knows what presenters know (although with some presenters I'd argue most know more, but that's another drunken rant). One of the plagues that is currently running through the industry is the notion of presenting just the Api. No worry or thought is put into the surrounding practices. You don't have to go out of your way to include these things into your presentation. Instead, you should just code like you do any other time. If you get to a point where you think you should be implementing a pattern, then do it. Briefly explain what you're doing and why. People love these little nuggets in a presentation.
People come to User Groups, Code Camps, Bar Camps, Conferences and whatever else you can think of, to learn. Let's not be afraid to challenge them. Better yet, let's not be afraid to teach them.
Daniel, none of this was targeted at you. The topic has been simmering for some time and your post just galvanized the thoughts for me.
posted @ Monday, March 03, 2008 8:46 PM