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: As Brian mentions, the value of practice has been a consistent theme of Richard Gabriel's over the last few years, and Dick has inspired a lot of software people to think more about practice. One of the things I've been thinking about in this regard is what Chad Fowler called valueless software. As a piano student, I often practice things that are not ever intended for performance. I play scales. I work through a set of Finger Power books to improve my dexterity and hand position. I play pieces that were written solely to help students learn to read notes and intervals. Indeed, some days much of my practice consists of pieces that are just for practice. The goal is that I'll be a better player of performance pieces (and I use 'performance' loosely here -- I'll never be a concert pianist!) Chad is more of a musician than I, and he says that this sort of practice is essential. The italics are mine.
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.) -----