Teaching Statement

As a member of multiple search committees for professors and lecturers, I have had to read more than a few “teaching statements”. Most were empty of meaningful content, a few made claims I couldn’t agree with and a few had something interesting to say about teaching. Every time I read one such statement, I am reminded that I never wrote one. Maybe it’s time I should, hence this page.

I have been teaching for more than 20 years now, and I have always taken my teaching very seriously, so I suppose I should have some sort of a “teaching philosophy” by now. I’m not sure what it is, but I’m sure it has evolved over time (at a minimum, from being a student, a TA and an instructor in France before moving to the US, some adjustment was needed…).

One thing I have started to realize is how different our situation in science and engineering is compared to the humanities. The work of professors there is in many ways more difficult (and more rewarding) than ours. If one thinks about it, helping students make sense of some of the fundamental principles underlying our human nature and helping them find meaning to their lives is a much grander occupation than to teach programming or algorithms. The “Professor so and so changed my life” stories can be trite or genuine, but they belong more to those fields than to ours. On the other hand, humanities professors can fail miserably at their job and start to teach complete nonsense (many of them do these days) and get away with it. It’s more difficult for us, or screens will go dark, bridges will collapse and planes will crash. In other words, I’m not sure what we do deserves something as ambitious as a “teaching philosophy”, but we still need to get it right.

I think I can identify a few attributes of my teaching style, whether they amount to a “teaching philosophy” or not. My focus here is on classroom teaching, not mentoring of graduate students, which is a topic for another day.

• Substance. I’m somewhat old fashioned in the belief that the focus of my teaching is on students learning something. This view is probably at odds with modern notions of students learning how to learn, discovering their inner selves, becoming good citizens, feeling good about themselves, etc. (I haven’t looked at them recently, but last time I checked the course evaluation forms used at UNH, there still wasn’t a single question about learning anything.) Again, it might be different in the humanities, but I see my role as helping students figure out some of the tricky things I have come to understand in the field of computer science, no more, no less.

• Expertise. I think that expertise in a domain is critical in order to teach it and should come first, before any concerns with style and teaching methods. There is sometimes this idea that any (CS) professor can teach any (CS) topic. This might be true to a certain extend, but certainly not a good idea in practice. Our department might decide tomorrow that I should handle the machine architecture course and that Arvind should teach formal verification and model-checking. I’m sure we both can do it. I’m also convinced it would be a terrible idea.

  Note that expertise doesn’t necessarily mean “research expertise” (I never did any research in model-checking and it’s been a long while since I did research in formal verification), but still implies an understanding of the subject matter that goes well beyond what is required of students in the class. Typically, I would not trust a student who passes my course with a perfect score to teach it the following semester.

• Alternatives. I had a professor as an undergrad whose explanations were not always very clear (to say the least). Sometimes, the whole class would stare at him with frowns and open mouths, until he stopped and ask us if we were lost. We’d say that we were. He would then proclaim: “Je répète” and repeat exactly his previous explanation, word for word! It was an amazing thing to watch.

  I claim no expertise in perfect explanations. I don’t know if such a thing exists. Until education theorists figure this out, I consider it risky to stick to one explanation. So, as was the case with my old French professor, there is a lot of repetition in my teaching, but I try to vary the explications and examples as much as possible. I also encourage students to read alternate formulations from books or from the web, especially if they found all my variants equally confusing.

• Difficulty. Going back to the idea of substance, one of my responsibilities as a teacher is to choose which topics to cover and which to ignore. This is crucial because the CS curriculum is getting crowded and there isn’t enough time to cover everything worth knowing.

  When selecting topics for inclusion in a course, I like to think of them as ranked in a two-dimensional space of usefulness and difficulty. The two are certainly not independent (useful knowledge tends to be more complex) but neither are they tied in a monotonic progression from useless and easy to useful and difficult. Let’s consider the four corners of the diagram shown right:

  • Bottom-left: There is a priori no reason to cover useless topics. However, I am of the opinion that most CS curricula include material that is not very useful but has been there for a long time and is staying out of habit and inertia. Without going into any specifics (I certainly don’t want to alienate colleagues from this or other departments), we need to be careful not to teach something simply because we learned it as a student, we know it, it has always been part of the course, other professors are teaching it and the ACM/NSF/ABET seem to like it.

  • Top-left: Worse than bottom-left is top-left, the area of useless but difficult topics, where effort is needed to learn pointless information. I sometimes worry that more useless topics are found there than in the bottom-left corner, due to the prestige of difficulty (this is hard to understand, therefore it must be deep). One must be especially careful with theoretical topics, which tend to “age” better than applied things that have lost their utility—if there is no use in learning COBOL anymore, then COBOL naturally goes away; that may not be the case with more abstract course content.

  • Bottom-right: This is where things get dicier. It is tempting to think of topics in both right corners as equally worthy of being taught on account of their usefulness. There can even be a temptation to privilege the bottom-right corner: simpler things are easier to explain, more of them can be covered in a single course, they can be taught to a wider range of students and, as long as the material can be used for practical purposes, students (and their employers) will tend to like it.

    The problem I see with bottom-right topics is that they are not always the best use of faculty and (tuition-paying) students time. It’s not that they are not useful (they are), but more that they can be learned outside the classroom more easily than top-right corner topics. This is even more true in an age where online resources (courses, tutorials, interactive presentations, etc.) are available to complement the age-old textbook.

  • Top-right: This is the good stuff! It includes those topics that are important but complex enough that they require more effort and/or time to learn on one’s own. This is where I feel my help is most valuable to students. Accordingly, my courses tend to drift toward this top-right corner and at times have earned me a reputation for teaching hard courses. Still, I think this is where our teaching belongs, especially if, as an institution, we aim to keep an edge over cheaper alternatives, both online and “brick-and-mortar”. I don’t know if the higher education bubble will ever burst (it’s certainly overdue), but if and when it does, we professors will be in a better position if we have something to offer that is hard to find elsewhere. (This also means that it might be a good idea for us to focus on those topics least amenable to online teaching, but that’s a discussion for another day.)

• Maturity. This is not part of my teaching style per se, but is more an admission of limitations. I enjoy teaching students who show a high level of maturity; in other words, I’m not very good with immature students. I’m also not very good at spoon-feeding students or at being their friend/father/mother because they need me to. At the risk of sounding politically incorrect, I’ve noticed a personal preference in teaching female students and older students, not because they are necessarily better students, but because they tend to show higher levels of maturity.

  Some professors don’t mind immature students. I remember reading an award-winning professor’s description of how he chose to tell a joke every fifteen minutes to offset his students’ short attention span. As a student in his class, I would have felt insulted. I’ve been known to joke in the classroom, but never on a schedule. I try to be respectful to students by treating them like responsible adults.

All in all, I don’t think my teaching style is off the charts. CS761/861 may not be the most typical programming languages course and CS745/845 the most typical theory course, but they cover material that is present, in one form or another, in many CS curricula. And appart from a French accent and an occasional odd choice of English words, I consider myself a fairly conventional teacher. (It’s all relative: imagine a professor who is pacing the classroom as he teaches, but without touching the floor, stepping from student desk to student desk; I had one as an undergraduate.)