Wednesday, June 14, 2006

Teach America

This is a follow-up to Chris's post whose attending some kind of seminar on teaching and technology.

There's something ironic about the use of technology in the classroom for computer science courses. Computer science teachers don't use a lot of it. You would think they would be on the forefront of teaching technology, but they're not.

There are several reasons. First, many computer scientists, ironically enough, are not technologists. They're mathematicians. They're old-school science folks. They believe that real understanding comes with deep knowledge of proofs and mathematics. They believe they have mastered a skill and it should last a lifetime. They think Pascal is a fad. C++ is a fad. Java is a fad. Heck, all programming languages are a fad! So it's not worth learning that.

Much of that thinking was because computer science wasn't that mature in the 70s, and the department often grew out of mathematics (and electrical engineering), so many of the early practitioners were mathematicians, who saw technology as something that was trendy, and not worth any intellectual power.

To be fair, even if a computer science teacher were plenty happy as a technologist (a hacker in Paul Graham's words), there was still something of a problem. Ten years ago, reliable presentation hardware wasn't available. Even if you had Powerpoint, it often took a bit of magic to get it to show up on a screen to present it. In the last 5-10 years, things have gotten a lot better, with standard setups that most anyone with a laptop and Powerpoint can put up a presentation.

And since this is the most common way to present at conferences, which professors gear up for, especially if they still are trying to get tenure, they can apply the same technology to teaching.

Indeed, this has become increasingly popular, especially among the younger teachers who often do their own presentations (I recall a professor who wouldn't touch software, despite having a Ph.D. in electrical engineering. His students typed up his papers and his presentations. He corrected it by hand.)

However, many students find Powerpoint presentations rather poor. There are several reasons. Some presenters cram way too many slides. Say, 60 slides in an hour. At that rate, it's too hard to pay attention. Often, it goes so fast, students can't even take notes, and some learn merely by the act of writing (or at least, remember). But really, where it's become highly problematic is the borrowing of other people's slides.

Most people who borrow slides are barely familiar with it. It's much like being an actor in a play, while holding the script and reading it aloud. You're that much better if you practice, and you're even better if you write your own words (maybe you're not a more effective writer, but you know your stuff better and why you wrote the words, and what they mean to you).

But there are all sorts of other technologies people could use. Chris mentions podcasting. There are message boards. There are live IM sessions.

This is all fine.

But I'm going to tell you to do something simpler, less technical, and it comes from a lesson that seems obvious, but isn't.

Teaching is a cooperative experience.

In order to teach, you make assumptions about students. How many people think students, once they are in college, ought to be mature? If you tell them to read something, they read it. And they don't just read it, they try to understand. They learn to ask good questions. They learn what is important, and what is not.

While this may describe the best students, it hardly describes all students. Many are simply not prepared to be college students. By learning where students are coming from, you can adjust your assumptions about where students ought to be.

Indeed, many of the assumptions teachers make about students are not something that's fully conceptualized in the heads of teachers. Here's an exercise. Write down what you expect the students to know before classes start. Then, try to find out what students do know. Write down trivial stuff, like be able to write a program, compile and run it. It seems silly, but if you haven't programmed in a while, you forget this. And this is even after taking two or three classes! It's shocking.

If you have students like that, and you feel they can still achieve, it's time to have a crash course sometime in the first week. Tell the students if they're not ready to do the crash course (and I mean, coming outside of class at some point) then maybe they should seek another major. You don't mean to be harsh, but they are basically so far back, they should be in the first course.

Now, I've suggested something that is not very politically correct, so you may have to massage it a little. On the one hand, you don't want to explain how things are in the real world, at least, not in full detail, or you'll really scare people off, but you need to talk about what programming is like in the real world, and see if people are prepared to learn that or not, or to find something else they can be good at.

If you want to bring up a sports analogy, Michael Jordan tried to play baseball. Unlike Deion Sanders who was succesful at football and baseball, Jordan was not good at baseball. Imagine if he had chosen not to come back to basketball. Would that have been a mistake? Most people would say so. He had far more talent for basketball, already acknowledged as the best. To leave what he was best at would have been a waste of his talent.

In order to get a sense of where students are, so you can revise your assumptions, you need to talk to them, get a sense of where they're coming from. You don't have to be their best buddies, but they shouldn't be so remote that you know nothing of them either. I used to ask each student to tell me one interesting thing about them, and I used that as a point of reference when talking to them. Believe me, students like it when you remember who they are.

These are all low-tech things, requiring no technology, but they can work remarkably well. Much of what people suggest technically is presentation oriented or it's student oriented. But it doesn't give the feedback loop you need to have some idea of where they are and where they need to be. Indeed, you may find you're helping them discover where they need to be.

In a software environment, we often have progress reports indicating how we're doing week to week. This might be something useful to do once a week or so. People can highlight what happened in class, what they've done outside of class, and so forth. Often by getting a sense of what everyone else does, they can see where they need to be.

You can see, much of this is beyond the actual mechanics of learning a particular subject, and moves to metalearning, learning how to learn. And some people in college need to know that before they learn real stuff.

No comments: