[Bluej-discuss] Programming as random process ...

[Stephen Edwards]

Jay Fenwick wrote:
> This term I have been giving a 10-12 minute quiz (microAssignment) almost
> every class session.

I'm not sure it helps with the "radom walk" method of
programming, but we've also had very good experiences
with daily quiz activities.  We usually do ours on-line using
a course management system, with students completing them
before class instead of during, but many variations are
possible.  Our evaluative results indicate that students generally
don't like the idea, however, they *do* get a lot of value out of
them and students even recognize that fact.

As for Gordon's original question about how to address
the problem of students treating programming as a problem
of randomly rearranging the elements until "the compiler is
happy" or whatever, I have two things to mention.

First (warning, semi-shameless plug alert), teaching software
testing along side programming can be a big help.  See my
SIGCSE paper called "Using Software Testing to Move Students
from Trial-and-Error to Reflection-in-Action" at:

http://doi.acm.org/10.1145/971300.971312

If you don't have access to ACM DL papers, feel free to request
an e-copy off-list.

Second, use pair programming.  Quite a few publications
have been written about successes with pair programming in
intro courses, and how it helps with performance, retention,
and success of members of underrepresented groups.  It turns
out when two students are working together, and asking questions
about "what's that?" or "why did you do that?" or "I don't think
that will work ...", it really does a lot.  One thing that happens is
that students end up articulating, in their own words, what they
are trying to do.  Sometimes they even end up explaining why
they are writing the code a particular way.

When they are sitting alone typing away at code, they don't
have to explain anything to anyone.  There is little cost to
"try and see", and students who start down the "random"
path often don't have a lot of built-in incentives to "think
it through".  However, as soon as you put them in a social
situation (even if it is with just one other person), there is
an in-built desire not to look like too much of an idiot, and
an in-built need to frame at least some modicum of justification
for your actions.  The natural dialog of pair programming works
to a bit of an advantage here, since students need to explain
things to each other.  Sure, some times "let's try it and see"
will certainly happen, but you'll also have other times when
it doesn't.

In our university CS1-level courses (actually, all the way through
our first three courses), students have a two-hour closed lab
session every week with required attendance and a deliverable
lab assignment each time.  We use pair programming in these
labs, so they have regular coding practice on a weekly basis
working with someone else.  There are lots of approaches in
the literature for how to do this--our approach is to randomly
pair students so they work with a different person each week,
no repeats; students spend half of the lab period in the role of
"driver" at the keyboard, and half the lab period as the "navigator",
looking over the driver's shoulder to spot potential bugs, ask
questions, make suggestions, etc.

As the SIGCSE paper above mentions, I believe strongly that
the more often and more regularly you can get students to
articulate in their own words "why" this is the way the code
should be, or "what" they expect the code to do, or "how"
they expect the statements to interact, the better off you'll
be.  IMHO, having students write tests themselves is one way
to force them to articulate their understanding of what is
going on.  Using pair programming in another way to force
them to articulate their understanding.  Neither works perfectly,
but the more opportunities you provide, the better.

Note the big difference here: asking them to "write a program"
doesn't force them (ever) to articulate their understanding of
why/what/how.  It only requires them to "come up with" working
code, somehow.  Also, asking quiz questions, particularly with
multiple choice questions or with micro-level programming
questions, does not usually force them to articulate their own
understanding in their own words.  Repeatedly putting the student
"on the spot" to write down or say what they *understand about*
the code (not just write/say the code itself) is very important.
There are other in-class active learning exercises you can use to
do this, too (and most are fairly non-confrontational and students
rarely feel like they are behind the eight ball, which is also
important).

                                 -- Steve

--
Stephen Edwards            604 McBryde Hall          Dept. of Computer Science
e-mail      : edwards at cs.vt.edu           U.S. mail: Virginia Tech (VPI&SU)
office phone: (540)-231-5723                         Blacksburg, VA  24061
-------------------------------------------------------------------------------