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: 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. -----