TITLE: Programming a lá Hoffman or Olivier AUTHOR: Eugene Wallingford DATE: December 14, 2004 9:16 AM DESC: Some end-of-semester doubts have me thinking about what these fine actors might teach me about teaching programming. ----- BODY: As I write final exams and begin to think ahead to next semester, I've been thinking about how I teach programming and software development. Sometimes, I get so busy with all of the extras that can make programming interesting and challenging and more "real-world" -- objects and design and refactoring and GUIs and unit tests and frameworks and ... -- that I lose sight of the fact that my students are just trying to learn to write programs. When the abstractions and extra practices get in the way of learning, they have become counterproductive. I'd like to streamline my approach to programming courses a bit. First, I'll make some choices about which extras are more distraction than contribution, and eliminate them. Second, I'll make a conscious effort to introduce abstractions when students can best appreciate them: after having concrete experience with problems and techniques for solving them. My colleagues and students need not fear that I am going back to the Dark Ages with my teaching style. My friend Stuart Reges (more information at his old web page) isn't going quite that far, but he is in the process of redesigning his introductory courses on the model of his mid-1980s approach. He seems to be motivated by similar feelings, that many of the ideas we've added to our intro courses in the last 20 years have gotten in the way of teaching programming. Where Stuart and I differ is that I don't think there is anything more "fundamental" about what we did in Pascal in the '80s than what we should do with objects and messages in, say, Java. The vocabulary and mindset are simply different. We just haven't quite figured out the best way to teach programming in the new mindset. I wish Stuart well in his course design and hope to learn again from what he does. But I want to find the right balance between the old stuff -- what my colleagues call "just writing programs" -- and the important new ideas that can make us better programmers. For me, the first step is a renewed commitment to having students write programs to solve problems before having them talking about writing programs. This train of thought was set off by a quote I read over at 43 Folders. The article is about "hacking your way out of writer's block" but, as with much advice about writing, it applies at some level to programming. After offering a few gimmicks, the writer says:
On the other hand, remember Laurence Olivier.

One day on the set of Marathon Man, Dustin Hoffman showed up looking like shit. Totally exhausted and practically delirious. Asked what the problem was, Hoffman said that at this point in the movie, his character will have been awake for 24 hours, so he wanted to make sure that he had been, too. Laurence Olivier shook his head and said, "Oh, Dusty, why don't you just try acting?"

I don't want all the extras that I care about -- and that I want students to care about -- to be affectations. I don't want to be Dustin Hoffman to Stuart's Olivier. Actually that's not quite true... I admire Hoffman's work, have always thought him to be among the handful of best actors in Hollywood. I just don't want my ideas to become merely affectations, to be distractions to students as they learn the challenging and wonderful skill of programming. If I am to be a method teacher, I want the method to contribute to the goal. Ultimately, I want to be as comfortable in what I'm doing in the classroom as Hoffman is with his approach to acting. (Though who could blame him if he felt a little less cocksure when chided by the great Olivier that day?) The bottom line for now is that there are times when my students and I should just write programs. Programs that solve real problems. Programs that work. We can worry about the abstract stuff after. -----