Demographics in Programming Teams in Early CS Courses

Question

I frequently teach CS1 and CS1-and-a-half in a very diverse, working-class, commuter public sector college. I have my students to work in small groups (2 or 3) on their larger homework programming projects. The students rarely know each other from outside class, and I take it upon myself to assign them to the groups. With the best of intentions and considerable misgivings I use demographics and to-date academic performance to construct the teams: same gender, different ethnic background, similar academic performance. This seems to "work" but maybe that sense is merely expectation-fullfillment.

Do others use these criteria, or opposite ones? I'm curious to learn of others' experiences and possibly perspectives I haven't considered.

Answer 1

I avoid using protected characteristics for any kind of group/class allocation. Personally, I apply a similar approach that I use in experimental research: the randomized block design. Typically, I use levels of prior relevant experience, either self-reported by the students at their point of admission or their grade for their pre-requisite class, as the blocks.

Answer 2

An interesting approach, which I have both used, and experienced as a student, is to make it truly random, and obviously so. Use a deck of playing cards split to match class size and how you want the divisions to be. For groups of 2-4, use the the face values with the correct number of suits and numbers removed to make the division equal. If it's a large class and you want groups of larger sets you can group the results some other way, say even red suits, odd red suits, even black suits, and odd black suits, to make 4 teams. Have the cards pre-selected for that class, but shuffle in class, and allow the students to select their cards one by one.

Grouping the students by knowledge can have negative effects two ways. First the "advanced" students don't get to see how others might think, and secondly the less advanced students receive the message that they aren't as good as the other students. Mixing them helps the "behind" students learn from the "advanced" ones, and the advanced students learn more by "explaining" it to the others. The benefit to both is that they get to see how other people view the project, and get insights into different modes of thinking, and probably programming.

Answer 3

Uniformity of groups is not good practice, for a variety of reasons. You need to find some means of assuring variety of experience and viewpoint in any project. If that is hard to do (as it is with such small groups) then don't let those pairs and triples stay together over many assignments, but re-shuffle the groups. It is normally easier with larger groups.

The issue is larger than just the course itself. The students need to become comfortable working with other not like themselves as it will be the norm in their later education and certainly in the workplace.

Here are some reasons:

There is research to the effect that the presence of a woman on a team improves the team performance. However, there is also research evidence that if a woman is the only woman on a team, she will be unhappy. Sorry, but I can't remember the source. I likely heard of it at either SIGCSE or one of the Agile conferences. The lesson that I generalize is that diversity is good, and isolation is bad. But the key is that diversity is good for the team's product, not just for the team's members.

If a team is too uniform, you will get the same sorts of ideas from everyone, lessening any creativity. This is especially true if teams are formed by the students themselves. They will likely choose friends. That might seem like a good thing, but it is likely to come at the expense of uniformity of thought.

People learn in different ways and the lessons learned in even technical subjects go beyond the subject matter itself. An advanced student working with a relative novice, provided you can make it safe for both, gives the advanced student an opportunity to learn more deeply than he/she might otherwise do just from having to guide the partner. The novice will start to see how he/she might think more like the mentor.

Here are some ways to go about it:

Others answering this question have suggested randomizing. This works pretty well and I second the advice.

While it is generally a bad idea to let groups form themselves from their friends, there is a technique that works well for larger groups, though it requires that the students know something about one another so it may not work in your precise circumstances. In sandlot baseball, teams are often formed as follows. Captains of the teams are chosen somehow; one per team. You can choose the captains or they can be randomly chosen. I usually named the (say) three best students in my estimation as captains. The captains would then choose their team mates in rotation, each captain choosing one person in each round. Yes, someone will be chosen last. It may be that they are just less known to the captains or it may be that there is some perception about their abilities. But the "last person chosen" may, in fact, wind up as a solid contributor to the team for reasons that seem orthogonal to the technical aspects.

If you want to make it more elaborate, you can even have each person write out on an index card what they think their main contribution to a team might be. This could be technical or not. It is like a mini CV. The captains have access to this information in the choosing process. This would be useful if the students know less about one another than otherwise.

Another option is for you to choose the teams. Write each person's name and something about them on a card. Then move the cards around in such a way that you get diversity on some measure in each team. But take into account that if a person assigned to a team is likely to feel isolated in the team it is probably not a good matching. If the size of the group and the characteristics of the people make this especially difficult, then you can give people the necessary experiences by having the teams short lived rather than persist through the course. The characteristics you use needn't involve protected classes (race, gender, ...). You can use past performance. You can use the fact that a person asks a lot of questions vs none at all. If the students form cliques outside class you can use those. If students are also employed, you can use employer. Lots of possibilities to find diversity of background and insight.

Final thoughts

Team work like this should also be combined with peer evaluation. Each team member should provide at least two things. First they should be able to name the top contributors to the team effort and to say why those were chosen. Second they should detail what they believe their own chief contribution was. They need to know before the teams are chosen that this will be a requirement and that it will be taken into consideration as part of the grading/evaluation process. If the questions are positive (who helped most?) rather than negative it is less risky for the students. The non-contributors stand out, as they aren't mentioned positively, rather than that someone said negative things about them.

Even in pairs (teams of two), you can ask each student for their partner's main contribution as well as for their own.

You will often learn surprising things from this peer evaluation, especially if their work is done outside you view. I've had people boosted by their peers beyond what I would have guessed.