Predicting Live Coding

This week I was at the WCCCE 2012 conference, where one of the keynotes was given by Mark Guzdial (and very enjoyable it was, too). I sent this twitter message at the time:

Recommendation: before running program during live coding, get students to make a prediction of what it will do, to improve learning

(For those who don’t know: live coding is the process of writing code “live” at the front of a class/lecture, as an interactive way of exploring/writing code with students.)

I was paraphrasing Guzdial, who was in turn talking about an ICER 2011 keynote speech by Eric Mazur (got that?). Guzdial has already written a nice summary of the speech, but in short: Mazur and his co-authors found that practical demonstrations had poor outcomes in later exams — noticeably poorer than having no demonstration! This is worrying, considering that live demonstrations are generally held to be good teaching practice. This harmful effect was only avoided if the students were encouraged to first make a prediction about the outcome of the demonstration.

Guzdial’s observation was that live coding is in effect a demo, and thus we should get students to make a prediction in order to improve learning. Hence the tweet.

However, it is a good idea to start from a skeptical position in research: the ICER 2011 keynote concerned seven physics demonstrations — you can view descriptions of the seven online. Until these results are replicated in a computing education study on live coding (any volunteers?), whether we believe the make-a-prediction advice rests largely on whether we believe the concept of a demo in physics is analogous to live coding in computing. Live coding is clearly a form of demonstration, but it is as much about writing the code as it is about running it. Predictions helped students to remember the outcome of the experiment, but I suspect that in computing the process of writing the code is the more important part to remember, not the outcome of running it. When I do live coding, it’s not because I want students to understand what it does in terms of the plain outcome, but rather that I want students to understand what I am writing and why. Live coding involves a building element that the physics demonstrations did not, and I think this may well distinguish the two practices.

So although I passed on the recommendation, in retrospect I am skeptical as to whether the physics demonstration finding will transfer to live coding. You could take the approach that there’s no harm in getting students to make the prediction — but the physics teachers thought there was no harm in giving a demonstration, and it turned out there was! Education is a tricky beast at the best of times, and research into education is no exception.

One thought on “Predicting Live Coding

  1. I completely agree — live coding is more about process as it is outcome, and we *absolutely* should run the experiments to see what would happen. We can’t just assume that physics maps to CS. But I’d bet that the condition where you get students to predict what’s going to happen when you run the program, before running the program, would still have more learning value than just running the program. The work on self-explanations (e.g., Van Lehn, Chi, Pirolli) suggests that the average student doesn’t actually ask themselves, “Now, why did it work like that? How did I *think* it was going to work?” But we know that such self-explanations do students whole bunches of good with respect to learning. Prompting them to predict is likely triggering similar cognitive processes, getting them to analyze and explain a situation to themselves.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s