DABlog

You may think of live coding as a necessary evil: the thing you have to resort to when a connection fails and you can’t get at a running example, or when someone asks a question you’re not sure of the answer to and you have to try it out in real time. Admittedly, memories of coding in public (especially the connection-failure ones where you end up writing an entire Rails application on the spot…) are not always pleasant memories.

But I’d encourage you, as a trainer, to embrace live coding. Don’t wait for things to go wrong before you do it; weave it into your presentations and examples by design. You’ll find that the rewards are well worth the risks, and that the risks can be successfully managed without too much effort.

Live coding in presentations and Q&A

Live coding usually doesn’t happen in silence (except when something’s gone wrong). I use it in tandem with answering questions and presenting topics. I think with my fingers; I’m more comfortable and confident saying things about code while I’m writing code. Whether you’re that way in general or not, live coding can keep things lively in your classroom.

Sometimes the answer to a question doesn’t come to me unless I can do some typing; sometimes the answer comes to me but wouldn’t mean much or be clear enough without live code to illustrate it. I’ve never had the impression that anyone thinks less of me as a programmer or as a teacher because I’ve resorted to trying something out before answering a question. Furthermore, the technique of trying things out is, itself, an important one, and a good lesson for your students to learn. “Is Hash#update a destructive operation?” someone asks. “Let’s ask Ruby,” I reply, and then try it out on the screen in irb. (By the way, update is destructive. So is merge!. But merge isn’t, and there’s no update!. No wonder I have to keep checking.)

“Let’s ask Ruby” is a good slogan to keep in mind, and a good one to impart to your students. I’m always surprised when someone sends a question to a Ruby mailing list that could easily be answered by typing a few characters of code into irb. But it does happen; apparently the trying-it-out habit isn’t ingrained in everyone, and the classroom situation is a good place to try to instill it.

As for live demos during presentations: I show code snippets and examples on slides, but I often end up tabbing away from the slides into a console session and showing live examples of the language features and idioms that the slides describe. In this context I see live coding as a kind of bridge between static presentation and having the students themselves do some coding. Obviously having me code isn’t the same as having them code; but I believe that seeing me enter code on the screen encourages them to do the same, to an extent that seeing a static example doesn’t.

Managing risk with semi-live coding

There are certain things I don’t like doing from scratch live. Deployment with Capistrano is one of them. It never seems to go right all the way along. I’ll take the fall for this—I have no reason to assign blame to Capistrano—but I have to live with the fact that live Capistrano installaton and setup demos are, for me, risky.

So I do my live demo of Capistrano, but I do it with the help of a list of steps, written on a piece of paper, and I prepare a certain amount of it in advance. (It’s the permission settings and passwords that always get me.). I don’t hide the list of steps from the class; there’s no detrimental effect to their seeing it, and if they think my use of a script like this means that I’m inadequately skilled, then at least now they know!

Having the demo scripted reduces the risk, if not to zero then at least pretty close. Deciding when you need this kind of aid is up to you. For me it’s Capistrano; for you it might be something else. The main thing to remember is that the usefulness of a live demo for the students is that it’s dynamic and engaging. It doesn’t matter if you use a “cheat sheet”, any more than it matters whether a pianist plays by heart or from the music, as long as the performance is good.

The “cheat sheet” technique applies mainly to fairly complex code demos that you can predict and plan in advance (as opposed to those that you do spontaneously in response to a question, or as a sample illustration of a language feature). Losing your way in the demo isn’t the only risk of a lengthy demo, though; there’s also the lengthiness itself. You don’t want to get embroiled in irrelevant details, nor to start boring the class.

Managing lengthy demos with the cooking-show approach

I draw inspiration from television cooking shows, in the matter of dealing with code demos that might otherwise be too long or detailed. These shows often use a kind of time-lapse technique. The chef mixes some ingredients and gets everything to the point of putting it in the oven. Then, instead of waiting in real time for the cake to bake, the chef produces a finished cake that’s been baked beforehand. The lesson can then resume at the point of frosting the cake.

The cooking show approach can be very handy for in-class demos. It’s particularly suited to cases where you want to demonstrate how to do something relatively small, and then want to show how it fits into a finished application. Rather than have the students sit through the writing of the whole application, you can write the bit you’re talking about—a data validation directive in a Rails model file, perhaps—and then run the whole application and show that it fails when the data is invalid. Or you might walk through the creation of one class or module, but then have the others already prepared so that you can fast-forward.

On cooking shows, the fast-forward technique might apply to the overall process (baking a cake, say) or to a subprocess that doesn’t lend itself to real-time presentation, like waiting for dough to rise or chopping large quantities of onions. The TV chef might illustrate the chopping technique, but then pull a bowl of pre-chopped onions out of the refrigerator and thus condense the time-frame.

The same thing applies in training. The time lapse you incorporate may involve a whole application, or it may involve a repeated task at one level of abstraction, analogous to chopping onions. By all means do a live demo of adding a “has_many” association to one or two of your models. But if you’ve got a lot of such cases in your sample application, consider doing most of them in advance and leaving just those one or two to do as a live demo.

So keep your irb session open, even during your slide presentations, and think creatively about semi-live and cooking show-style demos. Live coding keeps things in the moment, and adds motion and interest to the features you’re trying to put across.