[plt-scheme] Scheme projects in my undergrad CS course

I don't do anonymous reviews but in-class IBM-style reviews where
pairs present to a panel (1st reader, 2nd reader, secretary). The
panel conducts the code walk and the class is called on when the
panel fails to see obvious flaws. The goal is to review code in
class and to show everyone what can go wrong. This is for a semester- 
long
project that ends in 10-12Kloc of Java or 4K Scheme (free choice of
language).

I subject myself to this review, though w/o a partner. I use Scheme.

These code walks greatly improve the students' sensitivity to
design, rationale, and many real-world issues.

There's nothing like public pressure to bring across such topics.
I recommend it.

-- Matthias






On Jan 12, 2009, at 2:47 PM, Shriram Krishnamurthi wrote:

>> Shriram: since you suggest then yes, I'd be interested in reading  
>> about
>> those anonymous code walks.
>
> A bit stream-of-consciousness:
>
> There's a set of terms out there -- inspection, review, etc. -- that I
> don't really know.  Whatever the terms, you can't do the one that has
> the programmers respond in a class period.  It can be traumatic for
> them if you get critical; it's useless if you don't; and there may be
> some privacy issues as well.  So the way I run them is do them in
> camera with nobody but course staff (in addition to the students)
> present.  I warn them it will be hell, and I deliver on the promise.
>
> Since it can get exhausting (40 students = 20 teams = 10 hours of
> codewalks, sometimes done in just one day), I let my TAs take over for
> me after some time (eg, I do the first 10, then let them run one while
> I eat lunch, etc).  Either way, I'm always in the room, and I assign
> the grade, not the TAs.
>
> But, there is an alternative, which is doing this in-class.  Though I
> don't do it (because I can do the more personalized form), one of my
> colleagues does in his class.  The idea is to remove any and all
> identifying traces, then print the code on transparencies (or these
> days use PPT or PDF -- but make sure it's easily readable!), and talk
> through it in class.  Better still, of course, have the students
> critique it: get them started, then let them push through, then resume
> critiquing when they run out of things to say.
>
> This is a great way to lay down your law.  Do it early in the semester
> -- even for a very rudimentary assignment -- so students understand
> what you think good programs are, starting all the way from elementary
> style (indentation, etc).  This is even more important at a school
> where a particular language's culture isn't already in the air.
>
> Make sure you do 2-3 different projects, not just one.  It keeps that
> one group from feeling singled out.  It also gives you room to do one
> really good one, so students get positive examples in addition to
> negative ones.  Plus, nobody can get too cocky -- thinking their
> project won't be "singled out" -- until the end, so reminding them of
> this keeps their classroom behavior a bit better controlled, too.  Mix
> up the order so they can't just guess you're going from worst to best,
> so they have to stay on their toes.  Etc.
>
> Shriram
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme