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.
-----