TITLE: When Opportunity Knocks AUTHOR: Eugene Wallingford DATE: November 14, 2006 4:32 PM DESC: ----- BODY: When teaching a class, sometimes a moment comes along in that is pregnant with possibilities. I usually like to seize these moments, if only to add a little spice to my own enjoyment of the course. When the new avenue leads to a new understanding for the students, all the better! A couple of weeks ago, I was getting ready to finish off the unit on manipulating sound in CS 1. The last chapter of that unit in the textbook didn't excite me as much as I had hoped, and I had also just been sensitized by a student's comment. The day before, at a group advising session, one of my students had commented that the media computation was cool and all, but he "data to crunch", and he was hoping to do more of that in class. My first reaction was, isn't processing a 1-megapixel image crunching enough data? Sure, he might say, but the processing we were doing at each pixel, or at each sample in a sound, was relatively simple. With that in the back of my mind somewhere, I was reading the part of the chapter that discussed different encodings for sound, such as MP3 and MIDI. My stream of consciousness was working independent of my reading, or so it seemed. "MP3 is a way to compress sound ... compression algorithms range from simple to complex operations ... we can benefit greatly by compressing sound ... our Sound uses a representation that is rather inefficient ...". Suddenly I knew what I wanted to do in class that day: teach my students how to compression sound! Time was short, but I dove into my new idea. I hadn't looked very deeply at how the textbook was encoding sounds, and I'd never written a sound compression algorithm before. The result was a lot of fun for me. I had to come up with a reasonable encoding to compress our sounds, one that allowed me to talk about lossy and lossless compressions; I had to make the code work. Then I had to figure out how to tell the story so that students could reach my intended destination. This story has to include code that the students write, so that they can grow into the idea and feel some need for what I ask them to do. I ended up creating a DiffSound that encoded sounds as differences between sound samples, rather than as samples. The differences between samples tend to be smaller than the sample values themselves, which gives us some hope of creating a smaller file that loses little or no sound fidelity. This opportunity had another unexpected benefit. The next chapter of the text introduced students to classes and objects. While we had been using objects of the Picture, Pixel, Sound, and SoundSample classes in a "bottom-up" fashion, but we had never read a full class definition. And we certainly hadn't written one. The textbook used what was for me an uninspiring first example, a Student class that knows its grades. What was worse than not exciting me was that the class was not motivated by any need the students could feel from their own programming. But after writing simple code to convert a sound from an array of sound samples into an array of sample differences, we had a great reason to create a new class -- to encapsulate our new representation and to create a natural home for the methods that manipulate it. When I first embarked on the compression odyssey, I had no idea that I would be able to segue so nicely into the next chapter. Serendipity. After many years of teaching, bumping into such opportunities, and occasionally converting them into improvements to my course, I've learned a few lessons. The first is that not all opportunities are worth seizing. Sometimes, the opportunity is solely to my benefit, letting me play with some new idea. If it produces a zero sum for my students, then it may be worth trying. But too often an opportunity creates a distraction for students, or adds overhead to what they do, and as a result interferes with their learning. Some design patterns work this way for OOP instructors. When you first learn Chain of Responsibility, it may seem really cool, but that doesn't mean that it fits in your course or adds to what your students will learn. Such opportunities are mirages, and I have to be careful not to let them pull me off course. But many opportunities make my course better, by helping my students learn something new, or something old in a new way. These are the ideas worth pursuing. The second lesson I've learned is that such an idea usually creates more work for me. It's almost always easier to stay on script, to do what I've done before, what I know well. The extra work is fun, though, because I'm learning something new, too, and getting and chance to write the code and figure out how to teach the idea well. A few years ago, I had great fun creating a small unit on Bloom filters for my algorithms course, after reading a paper on the plane back from a conference. The result was a lot of work -- but also a lot of fun, and also an enrichment to what my students learned about the trade-offs between data and algorithm and between efficiency and correctness. That was an opportunity well-seized. But I needed time to turn the possibility into a reality. The third lesson I've learned is that using real data and real problems greatly increases the chances that I will see an unexpected opportunity. Images and sounds are rich objects, and manipulating them raises a lot of interesting questions. Were I teaching with toy problems -- converting Fahrenheit to Celsius, or averaging grades in an ad hoc student array -- then the number of questions that might raise my interest or my students' interest would be much smaller. Compression only matters if you are working with big data files. Finally, I've learned to be open to the possibility of something good. I have to take care not to fall into the rut of simply doing what's in my notes for the day. Eternal vigilance is the price of freedom, but it is also the price we must pay if we want to be ready to be excited and to excite our students with neat ideas lying underneath the surface of what we are learning. -----