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
<A HREF="http://www.cs.washington.edu/~reges/">
   Stuart Reges</A>
(more information at his
<A HREF="http://www.cs.arizona.edu/people/reges/">
   old web page</A>)
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
<I>better</I> programmers.  For me, the first step
is a renewed commitment to having students write
programs to solve problems before having them
<I>talking about</I> writing programs.

This train of thought was set off by a
<A HREF="http://www.43folders.com/2004/11/hack_your_way_o_1.html">
   quote I read</A>
over at
<A HREF="http://www.43folders.com/">
   43 Folders</A>.
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:

<BLOCKQUOTE>
On the other hand, remember Laurence Olivier.

<P> One day on the set of
<A HREF="http://www.imdb.com/title/tt0074860/">
   Marathon Man</A>,
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?"
</BLOCKQUOTE>

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
<A HREF="http://www.imdb.com/name/nm0000163/">
   Dustin Hoffman</A>
to Stuart's
<A HREF="http://www.imdb.com/name/nm0000059/">
   Olivier</A>.
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 <I>merely</I>
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.
-----