TITLE: Passing Out the Final Exam on Day One
AUTHOR: Eugene Wallingford
DATE: November 30, 2012  3:49 PM
DESC: 
-----
BODY:
I recently ran across an old blog posting called
<A HREF="http://tdunning.blogspot.com/2008/12/students-learn-what-they-need-not-what.html">
   Students learn what they need, not what is assigned</A>,
in which a Ted Dunning described a different sort of
"flipped course" than is
<A HREF="http://en.wikipedia.org/wiki/Flip_teaching">
   usually meant</A>:
He gave his students the final exam on Day 1, passed out the
raw materials for the course, and told them to "get to work".
They decided what they needed to learn, and when, and asked
for instruction and guidance on their own schedule.

Dunning was happy with the results and concluded that...

<BLOCKQUOTE><EM>
... these students could learn vastly more than was expected
of them if they just wanted to. 
</EM></BLOCKQUOTE>

When students like what they are doing, they can surprise most
everyone with what they will do to learn.  Doing something
cool like building a robot (as Dunning's students did) can be
all the motivation some students need.

I'm sometimes surprised by just what catches my students'
fancy.  A few weeks ago, I asked my sophomore- and junior-level
OOP class to build the infrastructure for a Twitter-like app.
It engaged them like only graphical apps usually do.  They've
really dug into the specs to figure out what they mean.  Many
of them don't use Twitter, which has been good, because it
frees them of too many preconceived limitations on where they
can take their program.

They are asking good questions, too, about design:  Should this
object talk to that one?  The way I divided up the task led to
code that feels fragile; is there a better way?  It's so nice
not to still be answering Java questions.  I suspect that some
are still encountering problems at the language level, but they
are solving them on their own and spending more time thinking
about the program at a higher level.

I made this a multi-part project.  They submitted Iteration 1
last weekend, will submit Iteration 2 tomorrow, and will work
on Iteration 3 next week.  That's a crucial element, I think,
in getting students to begin taking their designs more seriously.
It <EM>matters</EM> how hard it easy to change the code, because
they have to change it now -- and tomorrow!

The point of Dunning's blog is that students have to discover
the need to know something before they are really interesting
in learning it.  This is especially true if the learning process
is difficult or tedious.  You can apply this idea to a lot of
software development, and even more broadly to CS.

I'm not sure when I'll try the give-the-final-exam-first strategy.
My compiler course already sort of works that way, since we assign
the term project upfront and then go about learning what we need
to build the compiler.  But I don't make my students request
lectures; I still lay the course out in advance and take only
occasional detours.

I think I will go at least that far next semester in my programming
languages course, too: show them a language on day one and explain
that our goal for the semester is to build an interpreter for it
by the end of the semester, along with a few variations that
explore the range of possibilities that programming languages offer.
That may create a different focus in my mind as I go through the
semester.  I'm curious to see.
-----