RailsConf08: (opinion) ttyrec and my advice to session presenters

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.

  • del.icio.us
  • Reddit
  • Technorati
  • Twitter
  • Facebook
  • Google Bookmarks
  • HackerNews
  • PDF
  • RSS
This entry was posted in shell, tips and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://www.yehudakatz.com Yehuda Katz


    I agree with you 100%. Which is why I recorded my presentation ahead of time. And made a screencast. There was one tiny mistype that I made during the recording, and rather than try to snip it out, I left it in. It wasn’t a “whoops” moment as much as it was a simple character mistype that required a backspace.

    Of course, I got all the other benefits that you articulated above (namely, not having to focus on not making mistakes) because it was recorded.

    Regardless, I agree 100%. recording > live coding.

  • leethal

    Good point! I don’t mind typos on presentations, as you’re gonna make mistakes anyway even if you were just gonna talk, without any slides, but it’s food for thought nevertheless.

  • mongo1515

    i left this on the wiki feedback page for railsconf2007

    -No talks without previously prepared (even simplified) code samples–if I have to sit through one more ‘let me just code this up a minute…’ I’ll shoot someone.

    i didn’t make it to this years conference–lucky for me because then i might’ve had to shoot someone.

    there is no excuse for being unprepared.

  • http://geminstallthat.wordpress.com/ Reid MacDonald

    Playing devil’s advocate, one nice thing about live coding is when things *do* go wrong. Especially with skilled presenters and coders, watching how they deal with everyday problems can be very enlightening.

    This is, of course, if the session doesn’t get sidetracked or totally off course. I find this mostly in training sessions, when things go very akimbo it makes for good learning too.

  • http://evang.eli.st/blog Pat Maddox

    Nick Kallen’s talk was entirely a live-coding demonstration, and I’ve heard many people say that it was the best talk of the conference.

  • http://blog.bitmacro.com Matt Lins

    Like Pat said, Nick’s talk was all live coding. It was the best presentation I saw, hands down. He made mistakes, the audience helped point them out. It was fun and a great learning experience.

    I can’t believe some of the things people get upset about. I find it incredibly engaging watching skilled programmers code live. Like Reid said, it’s also interesting to see how they debug and solve problems under pressure.

    I would understand if a presenter took a 10 minute detour to fix a simple syntax error or something, but in reality, this never happens. These guys solve their problems pretty quick.

    I’d rather watch live coding over slides/movies at every presentation.

  • http://railspikes.com Jon Dahl

    I agree – live coding is far more often a bad thing than a good thing. There may be exceptions (didn’t see Nick Kallen’s talk), but for every Nick, there are ten of us who distract our audiences with live coding.

    Recording live coding is dead simple. I haven’t used ttyrec, but it looks good. I’ve used ScreenFlow for the last few months, and it works well – lets you record and edit in the same software. Also can record from multiple sources (screen, video camera, built-in mic, system sound), so it is great for building screencasts, doing usability studies, etc. ScreenFlow let me work in half a dozen short video clips into my presentation this year.

    I also gave a lightning talk at RailsConf this year called “How Not to Present at RailsConf” (http://railspikes.com/2008/6/6/lightning-talk-how-not-to-present-at-railsconf) that touched on this sort of thing.