…but I don’t like programming: gender and our division of labor

As last semester wound down, Cecilia and I  committed ourselves to honing our skills with Ruby.  During our first study session, we found ourselves talking about gender issues and the emerging role of each member within the Praxis team.  It is looking increasingly like the men will be more involved with programming, while the women of our group will focus on user interfaces, linking with social media, and management of the project.   During the last few meetings of our Ruby Boot Camp with Wayne, I’ve been aware of this emerging division, noticing that the women (perhaps mostly Cecilia and myself) have a tendency to ask more questions and to lay bare our lack of programming skills by joking about it or blatantly declaring our confusion.  In contrast, the men in our group are able to engage in two-way dialogue with Wayne in a vocabulary that is still largely foreign to me.

Despite my sense of unease and disappointment in this stereotypically gendered division, I had been comforting myself by insisting that such a division of labor within Praxis was a result of coincidence.  In general, the men in our group came to Praxis with some previous experience in programming, while the women did not.  Both Cecilia and I are still in coursework and teaching, which meant that we had different scheduling difficulties from some of the others.  As Ruby boot camp amped up at the end of the semester, so too did the demands from coursework.  As a result, both Cecilia and I struggled to find time for our Ruby homework.  And finally, I don’t find myself drawn to programming.  While it is incredibly satisfying to solve a puzzle and get the program to complete some task, it is not the kind of work I would like to do all day long.

Some of these circumstances actually are merely coincidences, but most are themselves structured results.   There are structured reasons why men often have more programming experience than women.    There are even structured reasons whyI have no great desire to be a programmer.  Gendered structures and practices work on us both externally and internally, shaping our desires, personalities, and goals.  (For more on these issues, check out this article on Forbes and one from the Chronicle of Higher Ed.)

So, the question is, what do we do now?  From a practical sense, it seems reasonable to let those who already know how to program to do their job.  The rest of us will find other ways to contribute.  This is certainly the most practical and efficient way to complete the set of ambitious goals that we are developing for the coming semester.   But—-as some might recall, I wrote a blog post earlier this semester suggesting that Praxis had the potential to challenge norms within academia.  Shouldn’t we also try to undo gender stereotypes and stop the perpetuation of gendered structures?   Is there a way to make use of the skills we have brought to this team (gendered and otherwise) without perpetuating such norms?  My hope is to start a conversation about this issue.  I’m looking forward to your thoughts.


  1. Just a quick note for people who may be following this great thread — the conversation is continuing on Cecilia’s post, over here.

  2. Claire, I’m incredibly glad that you and Cecilia have both written about this issue. As you note, the ways that systems and structures intertwine with our own motivations and desires is often frustrating, and it can be difficult (if not impossible) to differentiate between them. I often find myself in the same boat of feeling annoyed by my preferences if they happen to fall along typical gender lines.

    I just left a lengthy comment on Cecilia’s post, and much of the same applies here. I’d just add that I think it’s important to recognize and value the ways that various elements contribute toward the end result (ugly or unusable design will doom a project just as surely as faulty code). I also like Brandon’s idea of paired roles (not just programming), which could give everyone a chance to teach from their points of strength while also developing new skills in their weaker areas.

    I hope that this sparks much continued conversation, both within Praxis and beyond it.

    • Hey Katina–I just read your comments on Cecilia’s post. I completely agree that programming and code are not the only essential elements of our project. If I seem to be suggesting otherwise in my post, it was mostly a stylistic effort to get across a point. Often the “softer” roles from team projects are treated as having lesser importance (although not by the SLab staff!). This is part of the gendered world that we bring with us to this project. I wonder if this sense of lesser value assigned to management, design, etc isn’t part of what is creating our anxiety. Thanks so much for voicing the value of these roles.

  3. A good post, Claire. I’d love to hear more on gender and programming, and ways to practically bridge that gap, especially for female students or professionals who live at a long distance from a college campus!

  4. These are all really great points, Claire. Thanks for bringing them up!

    Paired programming seems like a great way to go about things, but what about paired design? Paired managing? We’ve stressed fluidity of roles a lot, as well, so maybe floating between jobs will help alleviate the gendered division somewhat. Maybe each person could focus on two jobs rather than just one – one they’re good at and one they’re bad at, a sort of apprenticeship. That could be a helpful way to distribute tasks in such a way that keeps both efficiency and learning high.

    In terms of the efficient use of skills and the division of labor: I think it is important to keep in mind that this is a learning process for all of us. I imagine that the SLab gurus would welcome us to take on roles that don’t come naturally to us and that push our skill set. I certainly hope so. It might also helpful to think about what you want to get out of the fellowship for your own future. If you feel like you need/want programming skills then I say go for it, regardless of how comfortable you are with it.

    And to be fair, I am always at sea with the vocabulary that Shane and Chris use to talk with the SLab folks. I tend to laugh at the conversations without really knowing what they are talking about.

    • Thanks Brandon–it seems like this paired roles thing is something we should talk about this week. It is an interesting idea!

    • And as an addendum, the hidden motive/implication to the above suggestions is that I feel quite terrible at design, but I would love to learn more and to improve.

  5. I think we might be on the right track with pair programming—which we got a taste of at the end of last term with Eric’s workshop on test-driven development. Researchers have suggested that pair programming helps female computer science students by combatting the negative stereotype that developing software is primarily a solitary, competitive activity. Our team is quite a bit different than an introductory computer science class, but it still might make sense to stick with pair programming, and perhaps to also insist on coed teams. I thought pair-programming with Cecilia in December was very productive, and if we stuck with it to the end of our new version of Prism, I bet it would give us a lot of opportunities to engage with the questions you raise in this post.