TITLE: Practice for Practice's Sake AUTHOR: Eugene Wallingford DATE: July 16, 2004 10:46 AM DESC: on practicing that matters by not mattering ----- BODY: A few days ago, I wrote about the difference between practice for piano students and practice for CS students. As I noted then, this has been a popular topic for software bloggers in recent years. Here are some links:
Something I learned as a saxophonist is that the less valuable the direct output of that which you practice, the more emphasis you will place on the act of practicing. I can learn more, for instance, from making horrid noises for 30 minutes than I can from learning a Charlie Parker solo and playing it from memory. Why is this? I'm so focused on the output of the Charlie Parker solo--making it sound good, feeling good as a result--that I forget to focus on the process of learning it, and important bits of information are liable to fall through the proverbial cracks.Computer science students don't usually get this sort of practice: many, many repetitions of a low-level skill that strengthens the muscles and mind for the "real" task, but which themselves are not useful as products. Can you imagine asking your CS1 student to write 100
for
-loops
for tomorrow's class? Our students tend to do fewer repetitions, and for
the most part we try to make those few "real", in an effort to motivate.
(Well, if you count assignments like the Fahrenheit-to-Celsius conversion
program as real tasks.)
I'm not sure if there is any reason to seek a direct analog to the music
scenario for learning to programming. We do have an analog, though not
quite so low level. It is a venerable practice in computing to reimplement
classic programs as learning exercises: a calendar manager, Tetris, a web
server -- all have been done to death, and these days we all have ready
access to source code for these programs. Yet students write their own
for many reasons. Sometimes it's to learn a new language or OS API.
But the value lies, in part, in the fact that the student understands the
ideas in the app so well that he can focus on the learning task!
My good friend Joe Bergin has
created an object-oriented programming exercise inspired by the idea of
practice for practice's sake, which he likens to the musical etude: Write
a particular program with a budget of n if
-statements or less,
for some small value of n. Forcing one's self to not use an
if
statement wherever it feels comfortable foces the programmer
to confront how choices can be made at run-time, and how polymorphism in the
program can do the job. The goal isn't necessarily to create an application
to keep and use -- indeed, if n is small enough and the task challenging
enough, the resulting program may well be stilted beyond all maintainability.
But in writing it the programmer may learn something about polymorphism and
when it should be used.
This reminds me of Kent Beck's "Three Bears" pattern, which I revised as
a part of some patterns of
built-in
failure.
(These patterns appeared as part of
Patterns for Experiential Learning,
which was workshopped at EuroPLoP
2001.)
-----