Mark Guzdial just posted some of his pedagogical advice for teaching beginning programmers in How to Teach Computer Science with Media Computation | Computing Education Blog. I decided to check how much of this I follow in my applied electronics course, which is aimed at a similar level of student (college students with no previous exposure to the content, and perhaps a belief that the material is not relevant or over their heads).
Over the last 10 years, we have learned some of the approaches that work best for teaching Media Computation.
- Let the students be creative. The most successful Media Computation classes use open-ended assignments that let the students choose what media they use. For example, a collage assignment might specify the use of particular filters and compositions, but allow for the student to choose exactly what pictures are used. These assignments often lead to the students putting in a lot more time to get just the look that they wanted, and that extra time can lead to improved learning.
I’ve not allowed students much room for creativity in the course. Of the 20 3-hour lab sessions, only one is a “tinkering” lab that allows students to explore several different things. It may be the most fun of the quarter, and I should look into more ways to let students play with electronics design.
- Let the students share what they produce. Students can produce some beautiful pictures, sounds, and movies using Media Computation. Those products are more motivating for the students when they get to share them with others. Some schools provide online spaces where students can post and share their products. Other schools have even printed student work and held an art gallery.
I’ve not had the students share their work. This is difficult to do with the small electronics projects they do—unlike media computation, there isn’t an art by-product of the design process. The electronics, being hardware and often on breadboards, is much harder to share than software, and the output is generally not easy for average students to appreciate. (EKG traces, though interesting, are not really art-gallery material.)
- Code live in front of the class. The best part of the teacher actually typing in code in front of the class is that nobody can code for long in front of an audience and not make a mistake. When the teacher makes a mistake and fixes it, the students see (a) that errors are expected and (b) there is a process for fixing them. Coding live when you are producing images and sounds is fun, and can lead to unexpected results and the opportunity to explore, “How did that happen?”
I have always coded live in my classes. All my lectures are extemporaneous improv performances with audience participation. I certainly show debugging when doing gnuplot scripting live! For the electronics design, it is a little harder to show debugging, as most of the problems that occur are difficult to debug at the lectern (I don’t usually carry oscilloscopes and voltmeters around with me, though I have taken out my Swiss Army knife to reseat a loose wire in a screw terminal). Design errors are also hard to show how to debug—introducing fake errors in a design just confuses students, rather than clarifying the debugging process. Real errors don’t get caught until the circuits are actually built, which takes more time than is available in a 70-minute lecture.
- Pair programming leads to better learning and retention. The research results on pair programming are tremendous. Classes that use pair programming have better retention results, and the students learn more.
I have students work in pairs for every lab, and I force them to change partners every week. This frequent partner changing prevents the common problem of one student carrying another through the course, and allows me to deconvolve performance into individual grades (which I have to issue at the end of the quarter). I do see evidence that students working in pairs do a better job on doing the designs than students working alone, though a big part of that may be just that max(a,b) is better than average(a,b)—that is, that the pair does as well as the better of the two students.
- Peer instruction is great. Not only does peer instruction lead to better learning and retention outcomes, but it also gives the teacher better feedback on what the students are learning and what they are struggling with. We strongly encourage the use of peer instruction in computing classes.
The students do help each other learn in lab—particularly in the afternoon section. As long as I’m around enough that they check confusing points with me, rather than propagating wrong ideas, the peer instruction works well. I think that the afternoon lab section has been better about checking with me when they are confused. A lot of the morning section still seems caught in “answer-getting”, asking their friends for the “answer” rather than for help with the method—that sort of sharing interferes with learning, rather than aiding in learning.
- Worked examples help with learning creativity. Most computer science classes do not provide anywhere near enough worked-out examples for students to learn from. Students like to learn from examples. One of the benefits of Media Computation is that we provide a lot of examples (we’ve never tried to count the number of for and if statements in the book!), and it’s easy to produce more of them. In class, we do an activity where we hand out example programs, then show a particular effect. We ask pairs or groups of students to figure out which program generated that effect. The students talk about code, and study a bunch of examples.
I’ve not developed a good set of worked examples. Part of the problem is that I have trouble coming up with good design exercises, and I’ve ended up using almost all I’ve come with as assignments, leaving very little for use as worked examples. I see this as the biggest hole in my book and in my course, and I hope to try to fill it in a bit over the summer.
Another problem with worked examples is that I’m using this course to try to “descaffold” the students, who have been getting far too much fill-in-the-blank sort of labs and homework. I’m trying to get them from having their hands held for everything to being able to solve many-step design problems in only 10 weeks, which is probably an impossible task. I just wish that other teachers would do less scaffolding, so that the students were used to doing some problem solving and not just rote procedure following.
So I need to come up with worked examples that give students an idea how to solve multi-step problems (subdividing a system into parts, calculating sensitivity of sensors, working out needed gain by working from input and output constraints, … ) without solving the specific problems that they will address for them.