TITLE: Talking and Doing
AUTHOR: Eugene Wallingford
DATE: July 20, 2009  6:29 PM
DESC: 
-----
BODY:
I often find myself at meetings with administrator types,
where I am the only person who has spent much time in a
classroom teaching university students, at least recently.
When talk turns
to teaching, I sometimes feel like a pregnant woman at an
ob-gyn convention.  They may be part of a university and
may even have taught a workshop or specialty course, but
they don't usually know what it's like to design and teach
several courses at a time, over many semesters in a row.
That doesn't always stop them from having deeply-held and
strong opinions about how to teach.  Having been a student
once isn't enough to know what it's like to teach.

I have had similar experiences as a university professor
among professional software developers.  All have been
students and have learned something about teaching and
learning from their time in school.  But their lessons
are usually biased by their own experiences.  I was a
student once, too, but that prepared me only a bit for
being a teacher...  There are so many different kinds of
people in a classroom, so many different kinds of student.
Not very many are just like me.  (Thank goodness!)

Some software developers have taught.  Many give half-
or full-day tutorials at conferences.  Others teach
week-long courses on specific topics.  A few have even
taught a university course.  Even still, I often don't
feel like we are talking about the same animal when we
talk about teaching.  Teaching a training course for
professional developers is not the same as teaching a
university course to freshmen or even seniors.  Teaching
an upper-division or graduate seminar bears little
resemblance to an elective course for juniors, let
alone a class of non-majors.  Even teaching such a
course as an adjunct can't deliver quite the same
experience as teaching a full load of courses across
the spectrum of our discipline, day in and day out for
a few years in a row.  The principle of sustainable
pace pops up in a new context.

As with administrators, lack of direct experience
doesn't always stop developers from having deeply-held
and strong opinions about what we instructors should
be doing in the classroom.  It creates an interesting
dialectic.

That said, I try to learn whatever I can from the
developers with whom I'm able to discuss teaching,
courses, content, and curricula.  One of the reasons
I so enjoy PLoP, ChiliPLoP, and OOPSLA is having an
opportunity to meet reflective individuals who have
thought deeply about their own experiences as students
and who are willing to offer advice on how I can do
better.  But I do try to step back from their advice
and put it into the context of what it's like to teach
in a real university, not one we've invented.  Some
ideas sound marvelous in the abstract but die a grisly
death on the banks of daily university life.  Revolution
is easy when the battlefield is in our heads.

When it comes to working with software developers, I
am more concerned that <EM>they</EM> will feel like
the pregnant woman when they discuss their area of
expertise with me and my university colleagues.  One
of my goals is not to be "that guy" when talking about
software development with developers.  I hope and
prefer to speak out of personal and professional
experience, rather than a theory I read in a book or
a blog, or something another professor told me.

What we teach needs to have some connection to what
developers do and what our students will need to do
when they graduate.  There is a lot more to a CS
degree than just cutting code, but when we do talk
about building software, we should be as accurate
and as useful as we can be.  This makes teaching a
course like
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-07.html#e2009-07-03T08_31_32.htm">
   software engineering</A>
a bigger challenge for most CS profs than the more
theoretical or foundational material such as algorithms
or even programming languages.

One prescription is the same as above: I listen and
try to learn whatever I can from developers when we
talk about building software.  Conferences like PLoP,
ChiliPLoP, and OOPSLA give me opportunities I would
not have otherwise, and I listen to alumni tell me
about what they do -- and how -- whenever I can.  I
still have to sift what I learn into the context of
the university, but it makes for great raw material.

Another prescription is to write code and use the
tools and practices the people in industry use.
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-04.html#e2009-04-13T19_36_10.htm">
   Staying on top</A>
of that fast-moving game gets harder all the time.
The world software is alive and changing.  We professors
have to keep at it.  Mostly, it's a matter of us
staying alive, too.
-----