Tips for teaching using Live Coding

Question

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?

Answer 1

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

DOs

• 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'Ts

• 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.