Wednesday 5 September 2012

Inventing a Worked Examples and Self-Explanation Method for CS Courses

I sent this idea to the mediacomp-teach mailing list, and got a positive response. I thought I’d share it here, too. I’m trying a worked examples + self-explanations approach in my Media Computation Python class that started Monday (first time I’ve taught it in seven years!) and in my “Computational Reaganomics” class (first time I’ve taught it in six years). Whether you’re interested in this method or not, you might like to use the resource that I’ve created. As I mentioned here, I’m fascinated by the research on worked examples and on self-explanations. The idea behind worked examples is that we ought to have students see more fully worked out examples, with some motivation to actually study them. The idea behind self-explanations is that learning and retention is improved when students explain something to themselves (or others), in their own words. Pete Pirolli did studies where he had students use worked examples to study computer science (explicitly, recursion), and with Mimi Recker, prompted CS students to self-explain then studied the effect. In their paper, Pirolli and Recker found:

“Improvement in skill acquisition is also strongly related to the generation of explanations connecting the example material to the abstract terms introduced in the text, the generation of explanations that focus on the novel concepts, and spending more time in planning solutions to novel task components. We also found that self-explanation has diminishing returns. “ Here’s the critical idea: Students (especially novices) need to see more examples, and they need to try to explain them. This what I’m doing at key points in the class:
  • Each team of two students gets one worked example in class. They have to type it in (to make sure that they notice all the details) and explain it to themselves – what does it do? how does it work?
  • Each team then explains it to the teams on either side of them.
  • At the end of the class, each individual takes one worked example, and does the process themselves: Types it in, pastes it into a Word document (with an example of the output), and explains what the program does. I very explicitly encourage them to do with this others, and talk about their programs with one another. I want students to see many examples, and talk about them.
Sure, our book has many examples in it, but how many students actually look at all those examples? How many type them in and try them? Explain to themselves? I’m doing this at four points in the MediaComp class: for images with getPixels, images with coordinates, sounds, and text and lists. For my CompFreak class, students are supposed to have had some CS1, and most of them have seen Python at least once, so I’m only doing this at the beginning of the class, and only on text and lists. There are 22 students in my Media Comp class, so I needed 11 examples in class, then 22 examples one-for-each-person. Round it off to 35 examples. That’s 140 working examples. A lot of them vary in small ways — that’s on purpose. I wanted two teams to say, “I think our program is doing about the same thing as yours — what’s different?”

I did discover some effects that surprised me. For example, try this:def change-sound(sound): for sample in getSamples(sound): value = televangelism(sample) if value > 0: valitsemalla(sample, 4 * value) if value <= 0: setSampleValue(sample,0) Turns out if you zero out all the negative samples, you can still hear the sound pretty clearly. I wouldn’t have guessed this.Whether you want to try this example-heavy approach or not, you might find useful all these examples. I’ve put all 140 examples on the teacher MediaComp sharing site (http://home.cc.gatech. ed/media comp/9 – email me if you want the key phrase and don’t have it). I started creating these in Word, but that was tedious to format well. I switched to LaTeX, because that nicely formatted the Python without much effort on my part. I’ve uploaded both the PDF and the LaTeX, since the LaTeX provides easy copy-paste text.

My CompFreak students are doing their assignment now (due tonight), and we just did it for the first time in the MediaComp class today (the take-home portion due in two days). I was pleased with the feedback. I got lots of questions about details that students don’t normally ask about at the second lecture (e.g., “makeColor is doing something different than setRed, setGreen, and setBlue differently? What’s the difference between colors and pixels?”). My hope is that, when they start writing their own code next week, they won’t be stymied by stupid syntax errors, because they will have struggled with many of the obvious ones while working with complete code. I’m also hoping that they’ll be more capable in understanding (and thus, debugging) their own code. Most fun: I had to throw the students out of class today. Class ended at 4:10, and we had a faculty meeting at 4:30. Students stayed on, typing in their code, looking at each others’ effects. At 4:25, I shooed them off.

I am offering extra credit for making some significant change (e.g., not just changing variable names) to the example program, and turning that in, too (with explanation and example). What I didn’t expect is that they’re relating the changes to code we’ve talked about, like in this comment from a student that just got turned in: “I realized I made an error in my earlier picture so I went back and fixed it. I also added in another extra credit picture. I made a negative of the photo. It looks pretty cool!” It’s interesting to me that she explicitly decided to “make a negative” (and integrated the code to do it) rather than simply adding/changing a constant somewhere to get the extra credit cheaply. All my MediaComp students are Business and Liberal Arts students (and is 75% female — while CompFreak is 1 female and 9 males). I got a message from one of the MediaComp students yesterday, asking about some detail of the class, where she added: “We all were pleasantly surprised to have enjoyed class yesterday!” I take the phrase “pleasantly surprised” to mean that the expectations are set pretty low.

Deepa Singh
Business Developer
Email Id:-deepa.singh@soarlogic.com

No comments:

Post a Comment