RailsConf was fantastic. A huge thank-you goes out to everyone who took the time to create presentations and sessions. Creating them is a lot of work and I commend you for preparing them. One common negative theme, however, was this: Live coding isn’t efficient and it is bug-prone. It doesn’t matter who you are or how good you are, you’re not going to be maximally efficient presenting if you are performing live coding. Even if you practice, when you get up on stage you will make typos and it will not run exactly as planned. If you’re not convinced, let me give you a list of people who did live coding this weekend and made typos or mistakes:
Each of these guys are Ruby-Rock-Stars and they are way smarter than I am. The content of what they presented was, in every case, phenomenal. They are some of the best programmers in our community and if they can’t give a presentation without typos and mistakes I can almost guarantee that I (you) won’t be able to either. When you get in front of 300 people, start typing, start talking, and realize you’re under the pressure of time (and the crowd) it changes your ability to focus on any one task and it is very hard to not make mistakes. My theory is that one can present a live-like demonstration with no loss of effectiveness.
The most obvious way to do a live-like demonstration is by recording a screencast. You could also use AppleScript or library like castanaut (if you are on a mac). The app I’d like to recommend today is ttyrec . It’s a great little command-line app (it compiles flawlessly on my OS X 10.4) and it records the output of a shell session and can play it back like you are typing in real time. I see two major benefits to this:
- You can’t make mistakes. It’s recorded and it’s storing the output all into a text file. This means that if the network fritzes out when you’re on stage it doesn’t matter. Network outages, ill-timed bugs, etc. become irrelevant because the commands are not actually run at playback time (the stderr/stdout stream is saved into a text file).
- You can talk while you’re playing the demo. They do this in TV all the time (think Friends). In a scene where actors play video games they don’t actually play the game and act at the same time. The video games are recorded so the actor can focus on acting. When your computer is playing-back the work you’ve prepared before hand you can focus on talking while the “typing” is happening on the screen. You don’t have to do the mental context-switching of talking and typing simultaneously which causes mistakes that cost you (and maybe more importantly, your audience) time.
You may say “Well, I don’t want to do a recording, I want my demo to be live”. Here’s my view on that: Most people don’t care if your demo is actually live. When you’re on stage and what you’re showing is prepared it’s assumed to be in the perfect environment because you’ve been testing and developing in that exact environment. Even if your demo is truly live it still seems “contrived” in that we, the viewer, can never actually see all the pre-work, installing, compiling, back end etc. that was prepared behind the scenes. As Josh Susser pointed out: “keep in mind Lansford’s Corollary to Clarke’s Third Law: ‘Any sufficiently advanced technology is indistinguishable from a rigged demo.’”
I believe that recording your shell with ttyrec or similar is exactly as effective as a live demo. If I, as a listener, am interested in your project I’ll be the same amount of convinced to download/try/buy even if your demo is recorded. In fact, I’ll be a lot more convinced to try it out if you play something recorded that runs perfectly as opposed to a system that is so complicated or buggy that even the author is having problems using it.
So please record your “live coding” before hand. Your audience will thank you, you’ll avoid embarrassment, and you’ll be more effective for it
UPDATE I removed Yehuda Katz from the list of non-recorded presenters. My apologies go out to Yehuda who pointed out that he did record his presentation before-hand.