Charlie McDowell – Teaching Statement 2000-01
Professor, Computer Science

Most of the courses I have been teaching in recent years involve extensive computer programming. At the undergraduate level this includes the first programming class taken by all undergraduates in the School of Engineering, and two upper division courses. I have also taught a large "computer literacy" course and a programming course for non-majors. At the graduate level I teach a course that examines a variety of different types of programming languages.

I think computers are really amazing devices. To the uninformed it must seem like magic. I find it fun to try and imagine how a person from as recently as a few decades ago might respond if you showed them a modern computer. If you push the time back just one or two centuries, you would certainly be viewed as some type of conjurer or prankster. Although young people today aren't particularly "amazed" by computers, because they have been surrounded by them since birth, the operation of computers remains "magic" to most.

In most of the undergraduate computer science classes I teach, my goal is to make some of the magic go away. Once you know a magician's trick, you never see that same trick in the same way again. No matter how hard you try, some of the magic is gone. You can still marvel at the skill of the magician's slight of hand, but the magic is gone. When I teach students about how you program a computer, I want to make the magic go away. I want them to say, "Oh, that's how it does that."

The current popularity of computer science as a major is very much a mixed blessing. Larger enrollments mean more faculty colleagues, but they also mean larger classes. In recent years the classes I have been teaching have been steadily increasing in size. One of the biggest challenges I face as a teacher is making the most of the time in the classroom.

More and more I hear people talking about how "lecturing is an outdated and ineffective way to teach." We are supposed to be using "active learning," not passive listening, as in a standard lecture format. I, for one, am not ready to give up entirely on the lecture. I agree that most of the learning probably takes place outside of the lecture hall. In fact, most of the student effort is expended outside of the lecture hall, and that is as it should be. In a typical programming class I expect my students to spend roughly 20 percent of their time in the lecture hall, 20 percent of their time reading and studying the text, and 60 percent of their time developing programs (doing active learning).

I would like to ask the question, "how is explaining a complex topic in the classroom, different from explaining the same complex topic to a student one-on-one in my office or in the computer lab?" I havenÕt heard anyone suggesting we should give up office hours or stop helping out in the lab, providing one-on-one assistance to our students. I believe the difference is that in my office or the lab, the student has a specific question they would like answered, while many students come to class, not seeking an answer, but simply expecting to be "taught." The students that benefit most from the in-class experience are those that come to class with questions they want answered. Those are the students that have read the text, done the homework, and need some clarification. If they can all read the text and fully understand it, then I would have to agree that the lecture is unnecessary (although in that situation the lecture could still be used to present an alternative perspective). Unfortunately, many students simply do not come to class prepared.

So how is the above reflected in my teaching? I believe my first goal, especially in large classes, is to motivate the students to want to learn the material. If they believe the material is interesting and valuable, then they will come to class with questions. So what do I do to motivate the students? To know for sure I suppose you would have to ask them. I am earnestly excited about the material I am covering (at least most of the time) and I believe they see this. I give them biweekly quizzes to help them pace themselves and not fall behind. I try to learn their names. In a large class I canÕt learn them all, but I enjoy trying to at least learn some, and I believe the students appreciate this. It helps to prevent the classroom from turning into a big anonymous "lecture hall." I encourage questions, often stopping to ask for a show of hands to see who understands a certain point. Getting them to be honest about whether they understand a difficult point is tricky in a classroom setting. Undergraduates are not quick to admit ignorance in front of their peers. A solution to this is that I often pose a multiple-choice question to the class, asking them to raise their hand on their choice of answer. Of course some will always refuse to ever vote, but many participate, even when they get the wrong answer. Even if I get them to make the wrong choice because it was a "trick" question, at least I have them engaged and thinking.

Outside of the classroom, I am attempting to change the way students work on their programs. In Winter 2000, I introduced pair programming into an upper division programming class and last fall I introduced the use of pair programming in our introductory programming classes here at UCSC. In pair programming, two programmers work together on a problem. They do not divide the problem into two parts, solve the separate parts individually and then combine the results (divide and conquer). Instead, they work together, with one partner "driving" and the other partner "reviewing." While coding, the driver is the one sitting at the workstation keyboard, with the partner looking over their shoulder, performing a continuous code review. It is important that each partner of the pair spend roughly equal time driving and reviewing.

Traditionally, students in most programming classes are required to complete their programming assignments alone. Even in classes that do allow small groups of students to work together, they often use a divide and conquer strategy, where each student is responsible for a different part of the project. Pair programming is different, with the students working closely together on the entire program.

In the academic literature, cooperative or collaborative learning models involve two or more individuals taking turns helping one another learn. The consensus from numerous field and laboratory investigations is that academic achievement (i.e., performance on a test) is enhanced when an individual learns information with others as opposed to when she or he is alone. By having the students use pair programming, I hope to improve their enjoyment as well as their comprehension of the material. The most obvious risk is that weak students, in a strong-weak pair, will learn less because their strong partner does the work for them. I believe that with proper instructions about how to do pair programming, both students will benefit. The strong student can act as a tutor helping the weaker student achieve a better level of understanding. The strong student, through this tutoring process, will also gain a deeper understanding of the material. It is important to understand that pair programming is not "divide and conquer." Both students work together in a collaborative effort to learn the material and solve the problem.