Monday, August 29, 2011

On Peer Teaching/Learning

Since we are having the FB/iPad application seminar this evening, it seems fitting that I take some time to explain what we are trying to do with this exercise.

This is the 4th year that we're teaching CS3216 and also the 4th time that we're doing this seminar.

Obviously, I didn't quite get it right the first year and the seminar in its current manifestation is the result of several iterations.

It turns out that the seminar is not random assignment, but it is a specially designed component for CS3216 to promote peer learning.

First, since students are learning how to develop apps in CS3216, it is natural to study existing apps in order to learn the good, the bad and the ugly.

While it is easy for me to come up with a set of lecture slides articulating what is good, bad and ugly (and I did exactly that in my first year teaching CS3216), it quickly occurred to me that such an approach made little to no sense. That list is pretty common sense. Students would listen to me lecture, agree with me and I suspect would hardly remember a thing or be able to apply what they heard.

The FB seminar is the chance for students to come together to do a case study of an existing application to figure out what is good or bad about it. We hope that the very act of coming together to discuss would promote what's called "peer learning."

Thereafter, the act of presenting what each group had figure out further promotes peer learning and also helps students practise their presentation skills. It turns out that CS3216 typically have good presentation skills which is something that is helpful to learn through demonstration.

One of the mistakes I made for the first 2 years was not to control the duration of the presentations, and students then tended to ramble on and on. The seminar ran over time and learning was not optimal.

Since last year, we introduced Pecha Kucha, and the groups were "forced" to keep their talk to just 7 minutes. It turns out that this time limit has two advantages: (i) helped to ensure that class ended on time; and (ii) students are forced to think harder about what's important. :-)

Rambling is easy. Getting to the crux of what's important is hard and promotes learning.

Finally, the students are forced to focus on all the presentations because they are required to write a critique about one of the presentations (but not their own). This final act of "forced" reflection would hopefully encourage reflection and deeper learning. Students are also required to engage each other in the blogs for a week to promote further discussion.

We have no illusions that not every student would necessary learn what they are supposed to be learning in this process, but we try. While we ideally teaching to be highly uniform, information transfer is not the same as education. The efficient transfer of information is completely useless if students cannot actually apply what they learnt.

It is much more effective if students learn less but are able to apply, and more importantly, LEARN HOW TO LEARN in the process. The following lecture by a famous Harvard prof Eric Mazur probably explains what I'm trying to say in a more articulate way (for those who have the time and patience to watch the full lecture).

1 comment:

  1. I think the assignment was in particularly interesting. When developing applications, I tend to analyse what other people have done and try to come up with something new and fresh. However, there is a limit to how many applications any one person can analyse. With this seminar, you get to see a wide range of views, perspectives and analysis which is important in developing a developer's sense of what is good.