TITLE: Learning From Others
AUTHOR: Eugene Wallingford
DATE: May 20, 2011 11:55 AM
DESC: 
-----
BODY:
I've been reading through some of the back entries in
<A HREF="http://blog.vivekhaldar.com/">
   Vivek Haldar's blog</A>
and came across the entry
<A HREF="http://blog.vivekhaldar.com/post/1243047026/coding-blind">
   Coding Blind</A>.
Haldar notes that most professionals and craftsmen learn
their trade at least in part by watching others work,
but that's not how programmers learn.  He says that if
carpenters learned the way programmers do, they'd learn
the theory of how to hammer nails in a classroom and
then do it for the rest of their careers, with every
other carpenter working in a different room.

Programmers these days have a web full of open-source
code to study, but that's not the same.  Reading a novel
doesn't give you any feel at all for what writing a
novel is like, and the same is true for programming.
Most CS instructors realize this early in their careers:
showing students a good program shows them what a
finished program looks like, but it doesn't give them
any feel at all for what writing a program is like.  In
particular, most students are not ready for the false
starts and the rewriting that even simple problems will
cause them.

Many programming instructors try to bridge this gap by
writing code live in class, perhaps with student
participation, so that students can experience some of
the trials of programming in a less intimidating setting.
This is, of course, not a perfect model; instructors
tend not to make the same kind of errors as beginners,
or as many, but it does have some value.

Haldar points out one way that other kinds of writers
learn from their compatriots:

<BLOCKQUOTE><EM>
Great artists and writers often leave behind a large
amount of work exhaust other than their finished
masterpieces: notebooks, sketches, letters and journals.
These auxiliary work products are as important as the
finished item in understanding them and their work.
</EM></BLOCKQUOTE>

He then says, "But in programming, all that is shunned."
This made me chuckle, because I recently wrote a bit
about my experience having students maintain
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-05.html#e2011-05-10T16_32_07.htm">
   engineering notebooks</A>
for our Intelligent Systems course.  I do this so that
they have a record of their thoughts, a place to dump
ideas and think out loud.  It's an exercise in "writing
to learn", but Haldar's essay makes me think of another
potential use of the notebooks: for <EM>other</EM>
students to read and learn from.  Given how reluctant
my students were to write at all, I suspect that they
would be even more reluctant to share their imperfect
thoughts with others in the course.  Still, perhaps I
can find a way to marry these ideas.

<A HREF="http://www.dreamsongs.com/Books.html">
   <IMG SRC="http://www.cs.uni.edu/~wallingf/blog-images/books/writers-workshop.jpg"
        ALT="cover of rpg's Writers' Workshops"
        WIDTH="200"
        ALIGN="right" />
</A>

This makes me think of another way that writers learn from
each other, writers' workshops.  Code reviews are a standard
practice in software, and
<A HREF="http://www.hillside.net/plop/">
   PLoP</A>,
the Pattern Languages of Programs conference, has adapted
the writers' workshop form for technical writers.  One of
the reasons I like to teach certain project courses in a
studio format is that it gives all then teams an opportunity
to see each other's work and to talk about design, coding,
and anything else that challenges or excites them.  Some
semesters, it works better than others.

Of course, a software team itself has the ability to help
its members learn from one another.  One thing I noticed
more this semester than in the past was students commenting
that they had learned from their teammates by watching them
work.  Some of the students who said this viewed themselves
as the weakest links on their teams and so saw this as a
chance to approach their more accomplished teammates' level.
Others thought of themselves as equals to their teammates
yet still found themselves learning from how others tackled
problems or approached learning a new API.  This is a team
project succeeding as we faculty hope it might.

Distilling experience with techniques in more than just a
finished example or two is one of the motivations for the
software patterns community.  It's one of the reasons I
felt so comfortable with both the literary form and the
community: its investment in and commitment to learning
from others' practice.  That doesn't operate at quite the
fundamental level of watching another carpenter drive a
nail, but it does strike close to the heart of the matter.
-----