TITLE: Two Very Different Kinds of Student
AUTHOR: Eugene Wallingford
DATE: April 07, 2017  1:33 PM
DESC: 
-----
BODY:
The last sentence of each of these passages reminds me of some
of the students over the years.

First this, from Paul Callaghan's
<A HREF="https://pragprog.com/magazines/2012-10/thinking-functionally-with-haskell">
   The Word Chain Kata</A>:

<BLOCKQUOTE><EM>
 One common way to split problems is via the "generate and test"
 pattern, where one component suggests results and the other one
 discards invalid ones.  (In my experience, undergrad programmers
 are experts in this pattern, although they tend to use it as a
 [software development] methodology--but that's another story.)
</EM></BLOCKQUOTE>

When some students learn to program for the first time, they
start out by producing code that looks like something they have
seen before, trying it out, and then tinkering with it until it
works or until they become exasperated.  (I always hope that
they act on their exasperation by asking me for help, rather
than by giving up.)  These students usually understand little
bits of the code locally, but they don't really understand the
program or function as a whole.  Yet, somehow, they find a way
to make it work.

It's surprising how far some students can get in a course of
study by programming this way.  (That's why Callaghan calling
the approach a methodology made me smile.)  It's unfortunate,
too, because eventually the approach hits a wall when problems
and domains become more challenging.  Or when they run into a
course where they program in Racket, in which one misplaced
parenthesis can cause an otherwise perfect piece of code to
implode.  Lisp-like languages do not provide a supportive
environment for this kind of "programming by wandering around".

And then there's this, from Andy Hertzfeld's
<A HREF="http://www.folklore.org/StoryView.py?project=Macintosh&story=Inside_Macintosh.txt">
   fun little story</A>
about the writing of the classic manual <EM>Inside Macintosh</EM>:

<BLOCKQUOTE><EM>
 Pretty soon, I figured out that if Caroline had trouble
 understanding something, it probably meant that the
 design was flawed.  On a number of occasions, I told
 her to come back tomorrow after she asked a penetrating
 question, and revised the API to fix the flaw that she
 had pointed out.  I began to imagine her questions when
 I was coding something new, which made me work harder
 to get things clearer before I went over them with her.
</EM></BLOCKQUOTE>

In this story, Caroline is not a student, but a young new
writer assigned to the Mac documentation team.  Still, she
reminds me of students who are as delightful to work with
as generate-and-test programmers can be frustrating.  These
students pay attention.  They ask good questions, ones that
often challenge the unstated assumptions underlying what we
have explained before.  At first, this can seem frustrating
to us teachers, because we have to formulate answers for
things that should be obvious.  But that's the point: they
aren't obvious, at least not to everyone, and us thinking
they are obvious is inhibiting our teaching.

Last semester, I had one team of students in my compilers
class that embodied this attitude.  They asked questions no
one had ever bothered to ask me before.  At first, I thought,
"How can these guys not understand such basic material?"
Like Hertzfeld, though, pretty soon I figured out that their
questions were exposing holes or weaknesses in my lectures,
examples, and sample code.  I began to anticipate their
questions as I prepared for class.  Their questions helped me
see ways to make my course better.

As along
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2017-03.html#e2017-03-29T16_16_44.htm">
   so many other dimensions</A>,
part of the challenge in teaching CS is the wide variation in
the way students study, learn, and approach their courses.  It
is also a part of the great fun of teaching, especially when
you encounter the Carolines and Averys who push me to get better.
-----