Gender-Paired Programming

Our College offers a variety of CS1 sections, including the fully flipped, active learning, team-based, media-computation version that I designed (with the help of Bruce Long). All CS1 sections have a lab component, but in our version, we do gender-paired programming. There’s a lot to unpack when you talk about this, and in this post I will explain our rationale for doing this and detail how it works.

Learning how to program is a skill. Think about something that you are really good at, and you will realize that the way you became good at it is by doing it a lot. In order for students to become good at programming, they need to do a lot of programming. Now, this might be an argument for forcing students to do programming labs by themselves, but the research has shown that pair programming, when done well, is really helpful. By talking through the programming tasks with another person, a student is forced to think about why a particular solution may or may not work. With two people, there is less of a chance of getting totally stuck. Sharing multiple perspectives helps students see that there are often multiple ways to approach a programming problem. So, having students pair program theoretically gives them half the practice they need, but also gives them the benefits of multiple perspectives and discussion.

But, a problem happens when one person in the pair takes over and does all the programming, and the other person just sits and watches. Of course, this can happen with any two people, but what I observed and had several people report to me, is that this often happens in intro programming courses when a guy and a girl are paired up together. In this situation, the guy takes over the keyboard and the girl sits on passively watching the guy do the programming exercises. This is highly problematic for a number of reasons. Typically, women come into our program with less programming experience and exposure then men (not always, but typically). So, when this happens, the guy gets more practice and exposure and the girl gets less. So, the experience gap between them widens instead of shrinking.  Over time, that experience gap becomes worse and worse. I’ve met female CS majors who have told me they don’t know how to program because this happened to them.

Now, one can ask all sorts of questions about this phenomenon. Why is it happening? Why don’t the female students demand their fair share of time? Why are the male students acting this way? Here are my thoughts:

  1. Females are socialized to be less assertive and more passive. So, if a guy takes over a work task that is supposed to be shared, we tend to just let it happen. It seems rude to fight about it or protest.
  2. The guys are sometimes trying to show off, which is something they are socialized to do. Male programming partners tend to assert, as one female student described, “their very masculine programming skills”.
  3. The freshmen female students tend to be under-confident in their programming skills, and the freshmen male students tend to be over-confident in their programming skills (again, not always – but this is fairly typical). So, it makes sense that the more confident student would tend to dominate the keyboard.
  4. The students all want to get finished and do well. If the guy says something like, “Hey, I know how to do this, so we can be done quickly and get full points”, why would his female lab partner argue with that?
  5. The guys are NOT intending to do damage to their female lab partner’s career in tech. I don’t believe that this is typically done with an intention to harm. I have a lot of trouble imagining male CS students thinking to themselves, “Hmm. I think I want to derail her career in tech, so I’m going to purposefully not share the keyboard.” Most male CS students are probably pretty happy to have any girls in their classes.

To avoid these issues, we pair students up by gender in our CS1 lab. We don’t do this in later classes. This is not about keeping the guys and girls separate forever, after all, that wouldn’t reflect the real world. We do this only in the first class. It’s a chance to get everyone comfortable working on pair programming and sharing the load. We hope that after the first semester experience, the programming ability is a bit more evened out and the female students have more confidence in their abilities.

How does it work? We assign lab partners every week. Students work with the same partner for two weeks in a row. The two-week duration is to give students a chance to get to know each other enough to possibly develop a friendship, but it is not so long that if the two students don’t really hit is off, there is tension, or there is too much of an ability gap between the two students, it won’t be damaging or annoying. So, we keep a roster of female students and a roster of male students and pair them up with partners of the same gender. If a student is gender fluid, they get to choose which group they would be most comfortable with.

We need more research in this area. And, I would contend that this phenomenon happens sometimes between two male programming partners and between two female programming partners, typically when there is a wide experience gap. As faculty wandering around in labs, we should be watching for this and talking to the partners about the importance of really sharing the keyboard.

2 thoughts on “Gender-Paired Programming

  1. I wonder if you have any rules for pair-programming that you state up front? I have never understood how this works productively, but think it would be a great way to keep my students engaged.

    Like

    • So, my general rules for pair programming are as follows:
      1. I always have the lab instructions printed out on paper. One copy per pair, so they have to share this and go through it together. If you give them electronic lab instructions, then one person pulls them up on a second laptop, and is inclined to get sucked in to other activities on their laptop and stop paying attention to the lab activity.
      2. There are two roles: driver and navigator. The person at the keyboard is the driver, and the person not at the keyboard is the navigator. The navigator holds on to the lab instructions, and keeps track of progress. The driver is coding.
      3. The lab is usually split up into 3-4 sections. At the beginning of each section, students are told to switch roles. Frequent switching of roles is a best practice in pair programming.
      4. The general idea is that the pair should talk about the problem they are solving and agree on each line of code before it is typed. This requires a lot of talking. I tell the students that at any point, I may ask them what they are doing and they should both be able to explain the last line of code typed.

      Here’s a link to ISTE’s best practices on pair programming: https://www.iste.org/explore/articleDetail?articleid=221

      Liked by 1 person

Leave a comment