I am involved in a first year programming and algorithms course. In a recent lecture, I decided to present the material using live coding, which essentially meant that I sit behind the keyboard and write code and evaluate it, using emacs to facilitate the process.

This was quite successful and students commented on how much they appreciated the more (inter)active format. As this was my first attempt using this teaching format, I know that it did not run perfectly. Some of the problems were related to being not as savvy with emacs as I should be, and others were to do with allowing student questions to take me too far from my script. I know I can do better.

What are some guidelines for giving lectures (and other demonstrations) using live coding lectures?
What are the pitfalls to avoid?

  • 2
    $\begingroup$ I have my reservations about live coding (mostly concerning throughput and the illusion of understanding). Nevertheless, two suggestions: 1) Have you considered using classroom response systems for structuring questions? 2) I have no idea how practical that is, but using something like ideone.com may be interesting because students can access your code after lecture and run it without having to install stuff. $\endgroup$
    – Raphael
    Commented Jan 20, 2014 at 14:47
  • $\begingroup$ @Raphael: I had their attention much better than before, which is certainly a plus. Your two suggestions are very good. 1) Currently only the people really following offer any kind of feedback. 2) My language is not on the list. That said, all of the code is available in slides (which I ignored). $\endgroup$ Commented Jan 20, 2014 at 14:53

1 Answer 1


Here are some tips and pitfalls I've collected after using live coding for a week, and from talking to a colleague.


  • Prepare a script to follow and try to stick to it.
  • Clear the buffers frequently to focus on relevant part.
  • Start afresh for each new topic.
  • Use a bigger font.
  • Master the tool you are using, to avoid wasting too much time on trivialities.
  • Have background functions precoded. If not particularly relevant, ensure they can be imported, rather than appearing in the working file.
  • Ideally work in a language that give you immediate feedback. Languages with an interactive shell are best in this regard.
  • When using a typed, give the expected type of the function you are writing. This provides a guiding light for the students.
  • Freely make mistakes (though not too many). Step through how these should be fixed.
  • Don't forget – a picture paints a thousand words: interleave slides and black/whiteboard work with your coding session.
  • Have summary slides for the points you've covered
  • Sometimes, when modifying code, maybe make a copy and modify the copy. This provides a point of comparison.
  • Clean up code periodically.
  • Accept that you will make mistakes and openly allow students to correct you --- this makes your job easier and empowers them.
  • Write code in your own style. For example, you may have copied the code from elsewhere. But this will be hard to reproduce. Better to write it in your own style. For instance, I always write curried functions, because I program mostly Haskell. But Standard ML uses the idiom less frequently. Expecting curried functions is the most common error I make in class.
  • Physically, make sure you have your space set up well. Good keyboard, at the right height, cables all in the right places, physical obstacles out of the way, etc. Take a minute before you start to get your space working for you, not against you.
  • One approach is to write whatever students say, even if it is wrong. This get students to do the coding, and the fixing. It is a good idea to clean the code up at the end. This approach can create a classroom model of attention and interaction, because students need to pay attention to follow what is going on.


  • Don't optimise your code on the fly and break it in such a way that you cannot fix it.
  • Avoid talking to the computer. Talk to the students!
  • Avoid too much typing, especially of boilerplate code. Utilise your environment to help you spit out the templates for you.
  • If you use a text editor, avoid constantly scrolling around. It will cause motion sickness it those trying to follow.
  • If you use a text editor, before making radical changes to your code, warn students that you are going to do so, so that they can track what is going on.
  • 1
    $\begingroup$ How many students are in your class? I like your DOs towards interactivity but wonder how that scales to 50, 100, 250 students. $\endgroup$
    – Raphael
    Commented Jan 25, 2014 at 16:34
  • 1
    $\begingroup$ Do you publish your code after class? I imagine a Github repository where students can browse through different versions you created (maybe including a polished, comment version that never appeared in class) and look at the differences. They could also clone the repository to easily use once written algorithms as subroutines in their homework (if that's desirable). $\endgroup$
    – Raphael
    Commented Jan 25, 2014 at 16:36
  • 1
    $\begingroup$ Do you prepare unit tests to run your code against? I'm not sure whether that's appropriate in every class (is the focus on learning the principles of programming languages, software development or algorithms?) but it might teach some best practices along the way. $\endgroup$
    – Raphael
    Commented Jan 25, 2014 at 16:38
  • 2
    $\begingroup$ 1) 128 people registered for the class, though about 60-80 turn up. 2) I have the code already on slides, but I don't use the slides. So the students have a version of what I do, never any of the intermediate steps. I'm not really sure how interesting it is to have all variations. 3) No I don't, though they do write informal specifications. The focus is on learning a first programming language and some algorithms/data structures. I agree, though. Unit tests are something we'll consider integrating more heavily into the course. Thanks for the questions/implicit tips. $\endgroup$ Commented Jan 25, 2014 at 20:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.