TITLE: Express Yourself
AUTHOR: Eugene Wallingford
DATE: September 15, 2012 10:04 AM
DESC: 
-----
BODY:
One of my CS colleagues gives only multiple-choice and
true/false tests.  He swears by how well scores on them track
with performance on programming assignments, which he views
as a valuable form of consistency.  And, boy, are they easy
to grade.

I'm not a fan.  I can't recall the last I time used them.  If
I ever did, it was surely for a narrow purpose, say, to test
quickly the student's familiarity with vocabulary.  "Choose
one" questions are too limiting to be used wholesale, because
they test only recognition, not recall.  They certainly can't
test the synthetic skills we need as programmers and solvers
of problems, and those are the most important part of computer
science.

My course this semester has brought this idea to the forefront
of my mind again.  I've helped students a lot on their first
two programming assignments, as they learn a little Java and
revisit the concept of modularity they learned in their Data
Structures course.  I've been struck by how often they cannot
talk about their code.

When I ask "What is this statement doing?" or "Why are you
<x>?", many struggle.  They want to answer in terms of
the code they have written, either reading it back to me in
English or telling me the code that surrounds it.  This is
true for almost any value of <x>.  This week, "assigning
a value to this variable" and "using an <B><TT>if</TT></B>
statement" were common topics.

Most of these students had a reason that they wrote the code
they did, even if it was merely a reaction to a specific
behavior they observed in the compiler or executable.  But
even in the best cases the idea is usually not clear in their
minds.  Unclear ideas are nebulous and rambling.  This is
why the students have so much trouble trying to express them
at all, let alone concisely.

Perhaps it's not surprising that students at this level
struggle with this problem.  Most are coming directly out of
their first-year courses, where they learned a single
programming language and used it to build data structures
and small programs.  They are often able to solve the tasks
we set before them in these courses without having to
understand their own programs at a deep level.  The tasks
are relatively simple, and the programs are small enough
that bits of code cobbled together from examples they've
seen get the job done.

It takes practice to learn how to think at a higher level,
to express ideas about solutions and code without speaking
in terms of code, or even the solutions they have settled
on.

To learn learn such skills, students need practice.  The
professor needs to ask open-ended questions in class and
out.  Asking good questions outside of class is especially
important because it's in the hallway, the lab, and office
hours where students find themselves one on one with the
professor and have to answer the questions themselves.
They can't fall back on the relative anonymity of even a
small class to avoid the hard work of forming a thought and
trying to say it out loud.

They also need practice in the form of homework questions,
quizzes, and even tests.  Each of these exacts an increasing
level of accountability, which creates an increasing sense
of urgency for their efforts.  One of my favorite experiences
as a teacher is when students visit after a course is over
and tells me the pride they felt while taking the final exam
and finally -- finally! -- feeling like they could express
the thoughts they had in their minds.  That's a proud moment
for the teacher, too.

The first four weeks of this course reminds me that one of
the essential goals for the intermediate computing course
is to strengthen the skills needed to reason about ideas and
express them clearly.  When students make the move to a second
programming language and a second programming style, they have
to come to grips with the fact that programming is not just
about Python or Ada anymore.  In fact, it never was.
-----