A Report on Worked Examples and Self-Explanations in Media Computation
I should give you a little report on how my worked examples/self-explanation intervention worked in my Media Computation class. I have nothing close to real data, and you shouldn’t believe me if I offered any. This is a rarified class: 22 students, meeting four days a week for 90 minutes, plus office hours for 90 minutes twice each week (that most of the students have come to), and the teacher (who is the author of the textbook) attends breakfast and dinner with the students. I think it would be hard to get more student-teacher interaction than in this model.
That said, I would definitely do it again. I was quite surprised at how seriously the students took the task of explaining these programs! In retrospect, I shouldn’t have been surprised. In most classes, aren’t students asked to analyze and explain situations, even asked to make sense of some text? That’s exactly what I asked these students to do, and they really worked at it. I had students coming to office hours to ask about their assigned programs, so that they could write up their one paragraph of explanation. There were things that I had to teach them about this process, e.g., teaching them to try a program with different data sets, to make sure that the odd result they got wasn’t an anomaly. I gave them feedback (every single student, on every single program) about the quality of their explanations, and the explanations definitely got better over time.
The real benefit was that they were trying to understand some relatively complicated code before it was their own code that they were trying to understand (while also designing and debugging it, all before a deadline). With the worked examples tasks, they were just trying to understand. There clearly was a reduction in cognitive load. Variations on the below program had lots of students coming to see me — combining sounds at different rates was a challenging idea, but students did a good job of getting a grasp on it:
def modifysound2(sound): retsound = makeEmptySound(2*getLength(sound)) newsound = makeSound(getMediaPath("bassoon-c4.wav")) trgi = 0 nsi = 0 for i in range(getLength(sound)): value = getSampleValueAt(sound,i) if nsi < getLength(newsound): nsvalue = getSampleValueAt(newsound,int(nsi)) else: nsvalue = 0 setSampleValueAt(retsound,trgi,value+nsvalue) trgi = trgi + 1 nsi = nsi + 0.5 return resound
Because there four labs (that just involved explaining programs) and two homework’s (that involved typing in, executing, and explaining programs), the first real programming assignment was the collage assignment. Everybody did it. Everybody turned in a working program. And some of these were huge. This one (by Savannah Andersen) was over 100 lines of code:
This one, by Julianne Burch, is over 200 lines of code. I’m posting shrunk versions here: Julianne’s is about 4000 pixels across, representing the travel portion of this study abroad program.
I suspect that the worked examples and self-explanations gave the students more confidence than they normally have when facing their first programs. It’s unusual in my experience for students to be willing to write 50-200 lines of working code for their first programming assignment.
But some of these students were also getting it. A few of my students realized that they could make their collages more easily by using a copy() method to reduce the complication of composing pictures. I did prompt them to do that, and a few did — most just went with hard-coded FOR loops, because that was easier for them to understand. When I described how to do that, one student asked, “Aren’t you just naming some of those lines of code?” Yes! Nice way to start thinking about functions and abstract: it’s about naming chunks of code. One of my students, without prompting, also decided to create a copy() method for her sound collage. They’re starting to grapple with abstraction. Given that this is the third week of class, when none of them had any previous programming experience (all my students are liberal arts and management students), I think that they’re doing quite well at moving from notation into abstraction.
They’re working on their first midterm exam now, a take-home exam (to save classroom time.) I think it’s significantly challenging for a first exam, but it doesn’t have much coding. It has a lot of analysis of code, because that’s one of the key learning objectives. I want them to be able to look at a piece of code and predict its behavior, to trace (if necessary) what’s going on. For me, that’s a more important outcome from a first course than being able to write a lot of code.