Saturday, September 20, 2008

A simple and bad algorithm for teaching

This term I'm teaching an undergraduate course in Artificial Intelligence (AI). I got the job just as the semester started, and so I didn't get a chance to develop my own approach to the teaching of this very splendid and worthwhile subject. Of course, as a mixed blessing, there came the inevitable recourse to Russell & Norvig, who've shepherded thousands of similar courses over the last 10 years, and all over the place.

Book and lecture notes in hand, I've been so far following my first pass at a teaching algorithm:

1. Read the chapter. Make sure you understand it.
2. Prepare lecture slides.
3. Do a couple of exercises. Choose a couple for the next problem set.
4. Go over the slides a couple of times, mumbling things you want to say that are not explicitly written on the slide.
5. Enter classroom; deliver lecture; forget to use all your little "pedagogical devices"; watch students yawn...
6. Goto 1

This is as boring for the poor souls in my class as it is unsatisfying for me. I've "only" lost 4 students so far (out of a high point of 19), mostly due to a harsh problem set early on. But I need to come up with a better algorithm.

At least I have a nice subroutine in the "deliver lecture" department. At the beginning of each class, I call on random students to tell me, in their own words, about the concepts we discussed last time. In the spirit of modularity and reuse, I took this feature from a library of little gems by a senior faculty in my department. Thank you, senior faculty!

2 comments:

Joanna Bryson said...

Two thinks I found useful:

1) you have to put the motivation up front. for some reason the first time I taught I put all the cool stuff you could derive from the lesson at the end as a reward, as I thought it would keep people awake at the hard part of the talk. But by then they are asleep so you can't *keep* them awake. Giving them cool data they can't explain & don't entirely believe in the first few minutes makes them pay attention all the way through.

2) after every lecture, rewrite your lecture notes or slides the way you wish they had been. This makes you feel less frustrated if anything went wrong (as you've done something) and is a huge win the next year if you give the lecture again (or someone else uses your lecture notes or slides.)

Note -- I avoided using slides for programming -- I think the students learn more about processes if they see them happening rather than having them just flashed up (even with "builds") I wrote my lecture notes in HTML and posted them with supplemental links on my course website.

gavastik said...

The 1) is very good! For 2) although I'm feeling like re-writing the whole lecture structure, so of course I won't do that until next time :-).

Another thing I've just thought of and haven't done yet: to post handouts in complete-idea form and not in "this is what we've seen today" form they're in now, because I do go overtime and continue from the same spot the next time occasionally (often?).

You (I) live and learn.