TITLE: Grading and Learning in the Age of Social Media
AUTHOR: Eugene Wallingford
DATE: September 23, 2011  3:52 PM
DESC: 
-----
BODY:
Yesterday morning, I was grading the first quiz from my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-09.html#e2011-09-13T19_17_56.htm">
   programming languages course</A>
and was so surprised by the responses to the first short-answer
question that I tweeted in <EM>faux</EM> despair:

<BLOCKQUOTE><EM>
Wow.  We discussed a particular something every day in class
for three weeks.  Student quiz answers give no evidence of this.
</EM></BLOCKQUOTE>

Colleagues around the globe consoled me and commiserated.  But
I forgot that I am also followed by several of my student, and
their reaction was more like... panic.  Even though I soon
followed up with a tweet saying that their Scheme code made me
happy, they were alarmed about that first tweet.

It's a new world.  I never used to grade with my students watching
or to think out loud while I was grading.  Twitter changes that,
unless I change me and stop using Twitter.  On balance, I think
I'm still better off.  When I got to class, students all had
smiles on their faces, some more nervous than others.  We chatted.
I did my best to calm them.  We made a good start on the day with
them all focused on the course.

We have reached the end of Week 5, one-third of the way through
the course.  Despite the alarm I set off in students' minds, they
have performed on par with students in recent offerings over the
first three homeworks and the first quiz.  At this point, I am
more concerned with my performance than theirs.  After class
yesterday, I was keenly aware of the pace of the session being
out of sync with the learning curve of material.  The places
where I've been slowing down aren't always the best places to
slow down, and the places where I've been speeding up (whether
intentional or unintentional) aren't always the best places to
speed up.  A chat with one student that afternoon cemented my
impression.

Even with years of experience, teaching is hard to get right.
One shortcoming of teaching a course only every third semester
is that the turnaround time on improvements is so long.  What I
need to do is use my realization to improve the rest of this
offering, first of all this unit on recursive programming.

I spent some time early this week digging into Peter Norvig's
<A HREF="http://blogs.scientificamerican.com/at-scientific-american/2011/08/23/systems-analysis-look-back-1966-scientific-american-article/">
   Prescient but Not Perfect</A>,
a reconsideration of Christopher Strachey's
<A HREF="http://www.scientificamerican.com/article.cfm?id=system-analysis-and-programming-christopher-strachey">
    1966 <EM>Sci Am</EM> article</A>
and in particular Strachey's CPL program to play checkers.
Norvig did usual wonderful job with the code.  It's hard to
find a CPL compiler these days, and has been since about 1980,
so he wrote a CPL-to-Python translator, encoded and debugged
Strachey's original program, and published
<A HREF="http://norvig.com/sciam/checkers.py">
   the checkers program</A>
and
<A HREF="http://norvig.com/sciam/checkers-complete.html">
   a literate program essay</A>
that explains his work.

This is, of course, a great topic for a programming languages
course.  Norvig exemplifies the attitude I encourage to my
students on Day 1: if you need a language processor, write
one.  It's just another program.  I am not sure yet when I
will bring this topic into my course; perhaps when we first
talk in detail about interpreters, or perhaps when we talk
about parsing and parser generators.  (Norvig uses
<A HREF="http://theory.stanford.edu/~amitp/yapps/">
   YAPPS</A>,
a Python parser generator, to convert a representation of
CPL's grammar into a CPL parser written in Python.)

There are some days when I had designed all of my course
sessions to be 60 minutes instead of 75 minutes, so that we
had more l&uuml;ft for opportunistic topics like this one.
Or that I could design a free day into the course every 2-3
weeks for the same purpose.  Alas, the CS curriculum depends
on this course to expose students to a number of important
ideas and practices, and the learning curve for some of the
material is non-trivial.  I'll do my best to provide at least
a cursory coverage of Norvig's article and program.  I hope
that a few students will turn out to his approach to the
world -- the computer scientist's mindset.

If nothing else, working through his paper and code excite
me, and that will leak over into the rest of my work.
-----