Personal Site & Blog of

Andrew L. Van Slaars

Not Quite Live Coding

· by Andrew Van Slaars · Read in about 5 min · (894 Words)
code presentation git

How I use git to give better code presentations

I originally posted this on medium. The basic idea is the same, but I have done quite a bit of editing and added some content.

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 being in an interactive classroom environment, was able to turn these mistakes into lessons. I built enough time into my lesson plans to account for the live coding, and the subsequent debugging, questions, and conversations that came with it.

I have done a few video lessons on YouTube in the last year or so, and I occasionally give code-related in front of actual humans. In those cases I am either constrained by time or I do not have the live interaction I would have in a classroom setting. For these situations I have been moving away from live coding. A presentation, whether live or in video form, should be a little more polished than in an interactive setting, and my ability to talk through a concept while typing mistake-free code is basically non-existent.

If you have the same issue with live coding that I do, you have several options for demonstrating code without typing it in front of an audience.

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.

Uncommenting as you go. 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. A work-around for this could be to update your editor theme to make comments very faint.

Copy and paste. 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.

Snippets In a similar vein to the copy and paste approach, you could prepare and use snippets in your IDE or through a tool like TextExpander.

CodePen, JSBin, Gists, etc. You could use a REPL or online snippet tool. Save a new Pen/Snippet/Gist for each version of your code. Many of the tools allow you to edit and run the code on the fly, as long as it’s code that will run in that environment. This also assumes a reliable internet connection.

All of these options have their benefits and drawbacks, but I have settled on another option that I prefer.

Using git

My current preference is to prepare my code in a git repository and use commits to represent each step in a lesson/presentation. 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 checking out out the first commit and then I 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 with just a couple of keystrokes. If a question comes up and I need to make changes on the fly to respond, 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. 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. 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 smooth transitions so the code changes are less jarring.

I add the following functions to my .bash_profile. It works with the master branch by default, but if you’re working on a different branch, you can call git_next dev where dev is the name of the branch you want to step through. get_prev doesn’t require a branch name.

git_next() {
  BRANCH=$1
  git checkout `git log --reverse --ancestry-path HEAD..${BRANCH:="master"} | head -n 1 | cut -d \  -f 2`
}

git_prev(){
  git checkout HEAD^
}

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.

Comments