TITLE: Programming Behind the Curtain
AUTHOR: Eugene Wallingford
DATE: August 31, 2009  8:20 PM
DESC: 
-----
BODY:
Greg Wilson wrote a nice piece recently on the
<A HREF="http://softwarecarpentry.wordpress.com/2009/08/21/the-big-picture/">
   big picture for his Software Carpentry course</A>.
His first paragraph captures an idea that is key
to the notion of "programming for all" that I and
others have been talking about lately:

<BLOCKQUOTE><EM>
One of the lessons we learned ... is that most
scientists don't actually want to learn how to
program--they want solve scientific problems.
To many, programming is a tax they have to pay
in order to do their research. To the rest,
it's something they really would find interesting,
but they have a grant deadline coming up and
a paper to finish.
</EM></BLOCKQUOTE>

Most people don't care about programming.  If they
do care, they don't like it, or think they don't.
They want to do something.  Programming has to be
a compelling tool, something that makes their lives
better as they do the thing they like to do.  If
it changes how they think about problems and solutions,
all the better.  When we teach programming to people
who are non-CS types, we should present it as such:
a compelling tool that makes their lives better.
If we teach programming <EM>qua</EM> programming,
we will lose them before we have a chance to make
a difference for them.

It turns out that all this is true of CS students,
too.  Most of them want to
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-14T14_47_54.htm">
   do something</A>.
And several of the lessons Wilson describes for
working with scientists learning to program apply to
CS students, such as:
<UL>
<LI> When students have never experienced the pain
     of working with big or long-lived programs that
     benefit from good abstractions, effective
     interfaces, and tools such as version control
     systems, "no amount of handwaving is going to
     get the idea across".  </LI>

<LI> The best way to reach students is to give
     them programming skills that will pay off for
     them in the short term.  This motivates better
     than deferred benefit and encourages them to
     dig in deeper on their own.  That's where the
     best learning happens anyway.  </LI>

<LI> Students are often surprised when a course is
     able to "convey the fundamental ideas needed
     to make sensible decisions about software
     without explicitly appearing to do so".  </LI>
</UL>

This issue is close to the surface for me as I work
on my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-08.html#e2009-08-28T19_28_08.htm">
   work on my software engineering course</A>.
Undergraduate courses don't usually expose students
to the kind of software development projects that
are likely to give the right context for learning
many of the "big picture" ideas.  An in-course
project can help, but contemporaneous experience
often runs out of sync with the software engineering
content of the course.  Next semester, they will
take a project course in which they can apply what
they learn in this course, but little good that does
us now!

(Idea for later:  Why not teach the project course
<B>first</B> and follow with course that teaches
techniques that depend on the experience?)

Fortunately, most students trust their professors
and give them some leeway when learning skills
that are beyond their experience to really grok
-- especially when the skills and ideas are a
known part of the milieu in which they will work.

Software Engineering this semester offers another
complication.  There is a wide spread in the level
of software and programming experience between the
most and least experienced students in the course.
What appeals to students at one end of the spectrum
often won't appeal students on the other.  More fun
for the professor...

In closing, I note that many of specific ideas from
Wilson's course and Udell's conception of
computational thinking apply to a good Software
Engineering course for majors.  (Several of Wilson's
extensions to the body of CT apply less well, in
part because they are part of other courses in the
CS curriculum and in part because they go beyond
the CT that every person probably needs.)  I should
not be surprised that these basic ideas apply.
Wilson is teaching a form of software engineering
aimed at a specific audience of developers, and
computational thinking is really just a distillation
of what all CS students should be learning throughout
their undergraduate careers!
-----