Lloyd Hugh Allen wrote:
On Wed, 23 Mar 2005 14:02:15 +0200, Linda Grandell <lgrandel@abo.fi> wrote:
I wonder if letting the students pair up for themselves could work? That would more or less be a variant of the second alternative above. Or does this introduce the risk of weaker students pairing up with strong students doing less work? Even learning less?
Generally, I would say that letting students on the K-12 level pair themselves in a totally, totally free fashion leads to less learning. This strategy often leads to a classroom management nightmare.
With all heterogenous groups (perhaps all groups), it's a good idea to have assigned tasks (for instance, if the program has already been flowcharted, then this person is responsible for this area and this other person is responsible for this area) or differentiated assessment (in my bf/gf example, to have the weaker student lead you through the code in order to ensure that even if they didn't come up with the code, at least they are able to read it)
I don't have experience with pre-college students, so take this advice with a grain of salt. I use pair (even group) programming frequently in my classes. Educational studies have shown that groups of 2 or 3 help students learn better than just having them work alone. One of the real advantages of pair programming is that students can pick up techniques and useful habits from each other. In order to gain the greatest advantage of this, it's important that teams rotate around. That way students end up working with many others during the course of the term, not just their "favorite". I wouldn't worry too much about the weaker students "coasting". They will learn a lot from assisting stronger students, and if the teams change frequently, they will at some point be the stronger student where they can pass on what they've seen others do. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle@wartburg.edu (319) 352-8360