TITLE: SIGCSE Day 1: Teaching Tips We Wish We'd Known...
AUTHOR: Eugene Wallingford
DATE: March 08, 2007 4:36 PM
DESC:
-----
BODY:
Once again, things that could've been
brought to my attention yesterday!
-- Adam Sandler, in "The Wedding Singer"
After a long day driving and a short morning run, I joined the
conference in time for the first set of parallel sessions. I
was pleased to see a great way for me to start, a panel session
called "Teaching Tips We Wish They'd Told Us Before We Started".
That's a great title, but the list of panelists is like a Who's
Who of big names from SIGCSE:
Owen Astrachan,
Dan Garcia,
Nick Parlante,
and
Stuart Reges.
These guys are reflective, curious, and creative, and one of the
best ways to learn is to listen to reflective masters talk about
what they do. The only shortcoming of the group is that they
all teach at big schools, with large sections, recitations,
and teaching assistants. But still!
The session was a staccato of one-minute presentations of teaching
tips across a set of generic categories. Some applied to all of
us: lecturing, writing exams, designing projects and homework
assignments, and grading. Some applied only to those at big
schools: managing staff and running recitation sections. Most
were presented in an entertaining way.
(This is a bit long... Feel free at any time to skip down to the
section on "meta" tips and be done.)
Lecturing
Some of these tips are ideas that I've found to work well in
my own courses. I love to write code on the fly, and I've
pretty much lost my reluctance to make a mistake in front of
the students. Students are pretty good at understanding that
everyone makes mistakes, and they like to see the prof make a
mistake and then recover from it. They can learn as much from
the reaction and recovery as from the particular code we write.
Owen has long championed showing student code in class, but I
have done so only under limited circumstances, such as code
reviews of a big CS II program. I should try collecting some
student code and using the document camera soon.
Nick's tips were more about behavior than practice. First,
don't roll your eyes about any part of the course. If the
instructor displays a bad attitude about some part of the
curriculum, the student may well learn the same. What's worse
in my mind is that students often learn to dismiss the instructor
as limited in understanding or as a jingoistic advocate for
particular ideas. That loss of respect diminishes the positive
effect that an instructor can have on students.
My favorite tip from Nick was "a mistake I've made, recast as a
tip": don't be lulled by your own outline. I've done this, too.
I pullout the old lecture notes for the day, give them a quick
scan, and think to myself, "Oh, yeah, I remember this." Then I
go in the classroom and fall flat. Scanning your outline !=
real preparation. It is too easy to remember the surface
feelings of a lecture without recapturing the details of the
session, the depth of the topic, or the passion I need to make
a case.
Dan's tips may reflect his relative youth. First, show video on
the screen during the set-up time between sessions. He suggests
videos from SIGGRAPH
to motivate students to think beyond what they see in their
intro courses to what computing can really be. Second, try
podcasting your lectures. He pointed us to
itunes.berkeley.edu,
which allows you to go Apple's iStore and download podcasts of
lectures from a variety of Berkeley's courses, among them his
own CS 61C Machine Structures. Podcasting may sound more difficult
to do than it is... One of my colleagues has experimented with
a simple digital voice recorder and the free, open-source editing
software
Audacity.
This approach doesn't produce sound studio-quality casts, but
it does make your work available to students in a new channel.
Dan gave one extra tip: think about what audiocasting means for
how you present. "Like this" and "here" loose their value when
students can't see what you are doing!
Perhaps the best quip from this part of the panel came from the
omnipresent Joe Bergin. Paraphrase: "The more finely crafted and
perfected your lecture, and the message that you want to communicate,
the worse you will do." Amen. That perfect lecture is perfect
for you, not your students. Go into class with an idea
of two to communicate, have a plan, and then be prepared for
whatever may happen.
Writing Exams
Lots of good advice here. We all eventually learn important
lessons in exam writing by doing it wrong, like to do
every problem before putting it on an exam (every
problem -- no problem is so straightforward that you can't be
wrong about it, and you will), and not to overestimate what
students can do in 50 minutes (guilty as charged). But there
were some nice nuggets that expose the idiosyncrasies of these
good teachers:
- Bring your laptop to the exam. (Dan) You can use it to
display the time left in the period, or to display real-time
corrections and clarifications.
- Write the rubric for your question first. (Owen) You'll
learn a lot about what the questions should be doing, which
helps you to write it better. (If this isn't
test-driven programming,
I don't know what it is!)
- When writing a CS1 exam, allocate 60% of the points to
mechanical questions, 30% to problem solving, and 10% to
a "super hard" question. (Stuart) The first part of the
exam gives every student a chance to succeed through hard
work and practice; the second gives all students to demonstrate
the higher-order skills that go beyond mechanical tasks,
and the third challenges and engages the best students without
punishing those students who haven't reached that level of
understanding yet.
- Use "program mystery" questions. (Stuart) These questions
are like mental calisthenics that ask students understand
algorithmic ideas beyond the surface. I liked his example:
What is the effect of the expression b = (b == false)
for the boolean b?
- Distribute sample questions. (Stuart) When you do, you'll
get an extra week of learning out of your students. They
take sample exams seriously enough to do them!
- Omit the backstory. (Nick) The complex set-up may work on
a homework assignment, where students have time to think and
chance to ask for clarifications. But on an exam, the story
is just cognitive overload, and as likely to interfere with
student performance as to help.
Someone in the audience offered a practice I sometimes use. Let
students take home their graded exam and correct their answers,
and then give them 25% credit toward their grade. I usually only
do this when exam scores are significantly lower than I or my
students expected, as a way to build up morale a bit and to be
sure that students have an incentive to plug the gaps in their
understanding with a little extra work.
Designing Projects and Homework Assignments
Don't belittle student work. Even if you mean your comment as
separate from person, students see the belittling of their work
as belittling them. And definitely take care how you
comment on student work in public! Work hard to provide
constructive feedback.
Use real examples wherever possible. Watch for the real world
"intruding" on old standards. Owen gave the example of his old,
boring "count the occurrences of words in a text file" problem,
which has now become hip in the form of sites such as
TagCrowd.
Make every assignment due at 11:59 PM. This eliminates the sort
of begging for extensions during the daytime that often leads
to a loss of dignity, while giving students extra time in the
evening when they have one last chance to work. But even if the
students work right up to the deadline, they will still be "on
cycle" for sleep. I've been in the habit of using 8:00 AM for
my deadlines in recent semesters, but I think I might try
midnight to see if I notice any effect on student behavior.
Do not assign too many math problems. "Math appeals to a certain
tribe. You are probably in the tribe, so you don't 'hear the
accent'.")
Grading
Use an absolute grading scale, with no curve. (I do that.)
At the end of the semester, bump up grades at the margins if
you think that gives a fairer grade. (I do that.) Never
bump grades down. (I do that.) Allow performance on later
exams to "clobber" poor performance on earlier exams. I do
this, but with a squooshy "I'll take that into account" policy.
Stuart reminded us not to kill our CS1 students. If you are
going to bump students' grades upward, do it right away. That
takes away some of the uncertainty and fear associated with
that grade, and they are already feeling enough uncertainty
and fear. When you do mess up, say, with an exam that is too
hard or too long (or both), be honest, admit your mistake,
and make amends.
Students will forgive
almost anything, if you are honest and fair.
From the audience,
Rich Pattis
offered a bit of symmetry on grading grace periods. Many
instructors allow students to submit assignments late, with
a penalty. Rich suggests that we offer bonuses for early
submission. In his experience, even a small bonus encourages
many students to start doing their work earlier. Implicit in
this suggestion is that when they don't get done early for the
bonus, because they need more time to get it, they have more
time to get it! I'm adding this to my toolbox effective
today.
I won't say much about the tips for managing staff and
designing recitation sections. But the big lessons here were
to value people. Undergraduates are an underutilized yet
powerful resource. (We've found this in our CS I, II, and
III labs, too.) Empower your TAs. Be human with them.
Going Meta
The last section was general advice,
going meta.
Most teachers in most disciplines can learn from these tips
science.
Team teach. An instructor can learn so much from working with
another teacher and watching another teacher work. Even better
is to debrief with one another. (If this isn't
pair programming,
I don't know what it is!)
Make notes as you learn how to teach your course. Keep a
per-lecture diary of ideas that you have in class. I have been
doing this for a decade or so. When I leave a session with a
new idea or a feeling that I could have done better, I like to
make an entry in a log of ideas, tagged with the session number,
or the assignment or exam number. The next time I teach the
course, I can review this log when prepping the course, to help
me plan ahead for last time's speed bumps, and then use it when
prepping the session or assignment in question during the semester.
The rest of these meta tips are from Owen Astrachan. I admire
his concrete ideas about teaching, and his abstract lessons as
well.
Stop being driven by the need to cover material. Your students
won't remember most of the details anyway. How many details
do you remember from any particular course you took as an
undergrad? Breaking this habit frees you to do more.
Owen gave three tips in the same vein. Know your students'
names. Eat where your students eat occasionally. Cultivate
relationships with non-CS faculty. The vein: People matter,
and being a person makes you a better teacher.
Learn something new: a whole new area, such as computational
genomics; a new hot topic in computing, such as
Ruby on Rails
or
Ajax;
or even a relatively little technique you don't already know,
such as
suffix arrays.
Learning new things reminds you what it's like to learn something
new, which is where your students are every day. Learning new
things lets you infuse your teaching with fresh ideas, maybe
ideas that are more relevant to today's students. Learning new
things lets you infuse your teaching with fresh attitude, which
is an essence of good teaching.
----
From this panel I can conclude at least two things. One is that
I'm getting old... I've been teaching CS long enough to have
discovered many of these practices in my own classroom, often
from my students. The other is that I still have plenty to learn.
Some of these ideas may show up in one of my courses soon!
If you'd like to learn more of these teaching tips, or add your
own to the collective wisdom, check out the community wiki
via this link.
-----