Not Quite Live Coding

How I use git to give better code presentations

For years, I would live code while teaching development classes. The mistakes I made (and there were plenty) would lead to ad-hoc lessons on debugging, and that was a good thing. I had the advantage of time and an interactive classroom environment. I built enough time into my lesson plans to account for the live coding, the debugging, questions, conversations, etc.

Recently, I have done a few video lessons on YouTube(you can find them here if you’re interested), and I have been giving some presentations at work. In those cases I am either constrained by time or I do not have the live interaction I would have in a classroom setting, so I have been moving away from live coding.

You have several options for demonstrating code without live coding. You can use slides. Slides only show a small amount of code and are typically not the best way to show ad-hoc changes to the code. Having all of the code ready to go and simply uncommenting lines of code as you get to them allows larger pieces of code and the ability to show changes on the fly. The problem here is that the commented code can be quite a distraction since it’s always visible. Copying code from an off-screen file and pasting it where it goes will help you avoid the distraction of seeing all of the code, but requires you to maintain the additional file(s) required to do this. In a similar vein, you could prepare and use snippets in your IDE or through a tool like TextExpander. All of these options have their benefits and drawbacks, but I have settled on another option that I prefer.

My current preference is to prepare my code in a git repository and use commits to represent each step in a lesson. Then I can step through the code one change/set of changes at a time by checking out specific commits in order. I do this by checkout out the first commit and then use a couple of handy bash commands (shared below) to step forward and backward through the commits. This allows me to have code “magically” appear at exactly the right moment in the presentation. I can back up if needed and if I need to make changes to the code on the fly to show something else or respond to a question, I can do that and then checkout or git reset to get back to the step I was on.

From a planning standpoint, this requires some forethought to get the right commits. But the upside to this is that I tend to think through my lesson more carefully and cover things I may have forgotten to plan for otherwise. I also get to rehearse as I put everything together and I can use my commit messages as a bit of an outline and as prompts for which code change is coming next. For example, if I am focusing on one file for the majority of a demo, but the next commit is going to result in a code change in a different file, I can prompt myself with a commit message to open the correct file before I checkout the next commit. As a bonus, when I’m using this technique for a screencast, I can use my video editing software to add transitions so the code changes are less jarring.

Couple this technique with an embedded terminal in your favorite editor (I use Atom with terminal plus), and your whole demo can take place in the comfort of your normal development environment.

The next time you want to present code without live coding, give this a shot and please leave comments here if you can improve on this approach or just want to share your own experiences in presenting code.

Like what you read? Give Andrew Van Slaars a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.