TITLE: Learning via Solutions to our Limitations
AUTHOR: Eugene Wallingford
DATE: November 13, 2009  2:18 PM
DESC: 
-----
BODY:
Yesterday I introduced refactoring in my software
engineering course.  Near the beginning of my code demo,
I got sidetracked a bit when I mentioned that I would
be using JUnit to run some automated tests.  We have
not talked about testing yet, automated or otherwise,
and I thought that refactoring might be a good way to
show its value.

One student wondered why he should go to the trouble;
why not just write a few lines of code to do his own
testing?  My initial response turned too quickly to
the idea of automation, which seemed natural given the
context of refactoring.  Automating tests is essential
when we are working in a tight cycle of code-test-refactor-test.
This wasn't all that persuasive to the student, who had
not seen us refactor yet.  Fortunately, another student,
who has used testing frameworks at work, jumped in to
point out the real flaw in what the first student had
proposed: interspersing test code and production code.
I think that was more persuasive to the class, and we
moved on.

That got me to thinking about a different way to
introduce both testing frameworks and refactoring next
time.  The key pedagogical idea is to focus on students'
current experience and why they <EM>need</EM> something
new.  Necessity gives birth not only to invention but
also to the desire to learn.

Somedays, I think the web is magic.
<A HREF="http://blog.mrmeyer.com/?p=5085">
  This</A>
popped into newsfeed when I refreshed this morning:

<BLOCKQUOTE><EM>
whenever possible, introduce new skills and new knowledge
as the solution to the limitations of old skills and old
knowledge
</EM></BLOCKQUOTE>

Meyer, who teaches HS math, has a couple of images
contrasting the typical approach to lesson planning
(introduce concept, pay "brief homage to workers who use
it", work sample problems) to an approach based on the
limitations of old skills:
<OL>
<LI> summarize briefly relevant prior skills </LI>
<LI> show a "sample problem that renders those skills
     pretty well useless" </LI>
<LI> describe the new skill </LI>
</OL>

I like to teach design patterns using a more active
version of this approach:
<OL>
<LI> give the students a problem to solve, preferably
     one that looks like a good fit for their current
     skill set </LI>
<LI> as a group, explore the weaknesses in their
     solutions or the difficulties they had creating
     them </LI>
<LI> introduce a pattern that balances the forces in
     this problem, and the discuss the more general
     context in which it applies </LI>
</OL>

I need to remember to use this strategy with more of
the new skills and techniques.  It's hard to do this
in the small for all techniques, but when I can tie
the new idea to an error students make or a difficulty
they have, I usually have better success.  (My favorite
success story with this approach was helping students
to learn selection patterns -- ways to use <TT>if</TT>
statements -- in CS1 back in the mid-1990s.)
-----