Gendered Language: Feature or Bug in Software Documentation?

How open source enforces male domination through shaming and hostility.

by Tim Chevalier on February 24th, 2014

If the programmer wishes to uphold the invariant, he must satisfy the function’s preconditions.

And then this guy over here pushes the packet onto the socket queue.

I wonder if the compiler guys have thought about this problem.

We’ve all seen sentences like these in software documentation and heard them in technical talks and casual conversation. Non-sexist language has been a topic of discussion for English speakers since at least since 1980, when Casey Miller and Kate Swift published The Handbook of Nonsexist Writing, and likely decades, if not centuries, before. The tech community is just beginning to catch up. In recent years, more people have been speaking up about changing language that excludes and erases the participation of women and people who don’t identify within the gender binary. But they have encountered significant backlash.

Screenshot of the section of the libuv pull request comments. In it, bnoordhuis comments: Sorry, not interested in trivial changes like that. User coderanger comments: +1 for merging this change. Alex, who opened the request, comments: I'm sorry to hear that. I don't really see why you wouldn't merge it if it's so trivial though. Surely making the library less hostile is worth a few seconds of our time to press the merge button?

For example, a one-line pull request that removed a gendered pronoun from a single line of documentation comment in an open-source project was initially rejected, and received 227 comments. Christie Koehler’s blog post from 2012, “Language Matters: Stop Using “Guys” to Address Mix-Gender Groups”, received 48 comments. In 2008, a bug report about changing the name that the Ubuntu project was using to refer to its contributors from a name with masculine connotations – “Ubuntero” – to a non-gendered name received 83 comments. In 2013 and 2014, a post on the Rust subreddit from its moderator, asking people to respect the subreddit’s code of conduct (based on the Rust project’s code of conduct), received 85 comments, most of which were debating the merits or lack thereof of using “guys” to address a mixed-gender group.

A lot of attention has been devoted already to the reasons why we should care about language that presents every programmer as a man, every abstract object as male. I’m going to assume that you, the reader, already care. Let’s invert the question: why is it so important to some men and women (I would include non-binary-gendered people in this, but I don’t know of any who defend binarist language) that they preserve the ways in which casual use of English serves to uphold maleness as the norm and femaleness as the exception? In the supposedly neutral and logical realm of software and computer science, what is so compelling about male domination that brings them to do this? What are the techniques and tactics with which people who like the status quo defend it, and how can those of us who the status quo harms dismantle it?

What Is Non-Trivial in Open Source?

I posit that when open-source people call a community problem “trivial”, this word serves as a proxy for respectability: it implies that people who do work that is worthy of respect in open-source would not waste their colleagues’ time with such queries.

In November 2013, when Alex Gaynor submitted a patch to the libuv project, a cross-platform asynchronous I/O library, that changed a documentation comment, it was initially rejected by a maintainer, Ben Noordhuis, who commented, “Sorry, not interested in trivial changes like that.” The original sentence was “The user needs to know that some data has already been sent, to stop him from sending it twice,” and Gaynor’s one-line patch changed “him” to “them.” The patch was subsequently accepted by a different maintainer, Isaac Schlueter; but Noordhuis then reverted it back, and also publicly criticized Schlueter for accepting it. Eventually, the patch was merged and Noordhuis left the project.

It would have taken the same amount of time to merge the pull request as the time Noordhuis spent closing it. In fact, it would have taken less time: merging it would not have required a justification. As of this writing, the pull request has comments from 110 different people. Even if the goal here was to redirect attention to more important issues, Noordhuis failed spectacularly. It’s a neat trick to explicitly characterize a move towards less sexist language as “trivial”, while implicitly characterizing his own defense of sexist language as non-trivial. Noordhuis’s claim that this is not worth his time was obviously false. What he actually meant was that something else very much was worth his time: boundary policing.

The software community expends great amounts of time and effort debating gendered language. Back in 2008, the Ubuntu community discussed the merits, or lack thereof, of “Ubuntero,” a word that the Ubuntu Community Council had adopted in 2005 to refer to members of the Ubuntu community. When Matthew Smith filed a bug report about the name, many commenters invoked the language of triviality. Sarah Kowalik (who notes in her comment that she’s a woman) wrote, “I would hope that people could focus on something more productive, and helpful to Ubuntu, than things like this.”

Screenshot of the Ubuntero bug report. The title says: Ubuntero inappropriate for female contributors. It includes a description of the bug, which states: The term Ubuntero, which is presumably of Spanish derivation, is only applicable for male contributors. A female contributor should be called an Ubuntera, which is impossible currently as a contributor is not asked his or her sex.

The 2008 “Ubuntero” bug report

Defenders of the status quo in both libuv and Ubuntu seem to be saying, “This is trivial, I don’t care, why are you wasting my time.” But the amount of time and energy that many people invested in defending the status quo communicates a different, implicit message. The majority of the “it’s trivial” commenters in these issues are men. Is controlling the conversation a way in which men perform their gender? No one ever seems to say that men’s desire to protect the status quo is “trivial” or unworthy of attention – triviality only gets used to characterize challenges to the status quo. Perhaps this asymmetry is the crux of the problem: men cannot bear to be told by women that they, themselves – their masculinity represented through gendered pronouns – are trivial. A minority of the defenders are women – maybe they felt that agreeing with male domination would serve their own interests by positioning themselves as reasonable women who had the right priorities (e.g. masculine ones), or even maybe they even felt coerced into doing so (as a condition on being accepted in their professional community).

Ultimately, whatever the underlying motivation, when you compare the tacit messaging with the explicit messaging, you can see that these dismissals are false. While the explicit message says that the work of redressing sexism is “trivial” and therefore not worth doing, the tacit message — that is, the sheer volume of responses attempting to establish the “triviality” of anti-sexist conversation — says otherwise.

Shaming: The Threat of Being Off-Topic

In open source, there are no formal penalties for discussing gendered language, but the community frequently imposes informal penalties in the form of shaming, a well-documented technique for silencing dissenting speech. As I’ve written about before, the notion of “being off-topic” is a powerful shaming mechanism in open source (and Internet culture in general).

The comment from the Ubuntero dispute that “People should focus on something more productive than this” is a statement that implicitly claims the right to decide which issues are productive and helpful, and implicitly shames those with different concerns for caring about issues that the speaker has deemed not to be “productive and helpful.” Who gets to decide which issues are productive and helpful? Asserting the right to make this distinction amounts to asserting oneself as part of the in-group, the subjects who get to decide what people should focus on and not the objects who “should focus on” something else.

The notion of relevance (or lack thereof) to a project arose in the conclusion to the libuv dispute as well. Ben Belder added a contributor’s guide to the project, which Noordhuis approved. In part, the guide reads: “When documenting APIs and/or source code, don’t make assumptions or make implications about race, gender, religion, political orientation or anything else that isn’t relevant to the project.

Surely, though, the claim that gender isn’t relevant to the project is an aspirational one. If gender was not relevant to the project, then 227 comments wouldn’t have been posted on the Github pull request that Gaynor submitted. In fact, race, gender, religion, and politics arerelevant to open-source projects. Community issues are not off-topic; they are central to any project that is bound together by voluntary ties rather than (as in projects that are part of traditional companies) economic coercion.

The powerful social pressure that exists in open source to be fun and interesting is also a boundary enforcement mechanism. Open-source people who openly acknowledge that they work on projects for any reason other than the sheer euphoria of writing, debugging, and refactoring programs are often viewed as morally suspect; the trope of being “passionate” about one’s work rules the discourse about open source. Accusing someone of bringing up an issue for reasons that are not fun or interesting (according to you) can thus be a powerful shaming mechanism, and a way of enforcing in and out-group dynamics.

Hostility

Anti-sexism work frequently gets derailed in less subtle ways. There is no bright line dividing shaming and subtle belittling from outright and sometimes sexualized insults. Each enables the other.

Until November 2013, I worked for Mozilla as a contributor to the Rust programming language, an open-source project that is overwhelmingly male-dominated. Two weeks ago, I attended a Rust meetup at the Mozilla community space in San Francisco; in the room, I observed between 30 and 40 men and one woman. During the two and a half years I worked on Rust at Mozilla, there was not a single female engineer employed permanently (i.e. not as an intern) by Mozilla Research, the department that the Rust team is part of; in the three summers that this time included, there was a total of two female interns working on either Rust or Servo (a related project). These statistics are not particularly anomalous for a programming language project, but it’s still worth noting.

From early on, Rust has had a strong code of conduct. Anecdotally, people often seem to remark about how friendly and welcoming the Rust community is. But as the community has grown and the language has received more widespread interest, the code of conduct by itself has not sufficed to make the community open and welcoming to all contributors. In August 2013, Lindsey Kuper — a two-time Rust intern and contributor since early 2011 — reported that another user on the #rust IRC channel, “daise”, directed the words “boobs or GTFO” at her as a result of a very polite request on her part to think about how “guys” comes across when addressing a group of people of mixed gender. Kuper also received further hostility just for documenting this incident: a number of comments attempted to re-center the discussion to be about concern for imaginary “people banned for their first offenses” rather than for people experiencing harassment, and on a related Reddit thread, many were hostile towards the concept of a code of conduct, or towards Kuper herself for having the nerve to talk about what she experienced.

Browsing through the IRC logs for #rust reveals hundreds of uses of “hey guys”, “you guys”, and similar phrases that passed without comment. I personally called out these phrases a number of times, but thanks to the default assumption of maleness, none of the times when I called out this language elicited a rude or vulgar response from anyone. Kuper, who called out this language fewer times than I did, nevertheless was the target of a much higher degree of intensity of reaction.

Around the same time, another woman who frequents #rust reported to me that she had received a private /msg from someone else on the channel that was a sexual come-on. She told me that #rust was generally really nice; that as a woman using technical IRC channels, she received a message like this at least once a day (just not as a result of using #rust before) and that it was really no big deal to her. Research shows that IRC users with feminine nicknames receive 25x the harassing and malicious private messages as users with masculine nicknames.

While one might be tempted to categorize both these incidents as isolated ones, the reaction of various other people on the core Rust team when I proposed edits to the code of conduct for the project to make it clearer that this behavior wasn’t acceptable shows otherwise. I was told “We don’t need to make policy changes every time someone is offended.” In general, there was more concern that someone would think a single unsolicited private message on IRC was grounds for banning than there was about harassment.

The Trifecta of Gendered Language in Open Source

The three themes — triviality, shaming, and hostility — are all intertwined. The first two are more common, but the excessive concern that men in tech show about reactions to misogynist hostility, and their relative lack of concern about that hostility itself, speaks volumes. For me, this point was underscored when I announced that I was leaving the Rust team. Though I didn’t mention code of conduct issues as a reason, one of my colleagues nevertheless told me that my attempts to encourage gender-neutral language “harmed the community” and “made people uncomfortable” – implying that encouraging gender-neutral language harms the community, but excluding women does not harm the community.

And in fact, the themes are three faces of the same emotion: anger. Tech anger looks like cool belittling and dismissal when the speaker is sure that his peers will back him up; more like disdain and contempt (for those who transgress the unwritten rules of what is on-topic) when he feels a bit more threatened. Only when the speaker knows he has no logical leg to stand on, and when he is operating without regard for his own respectability, does he resort to outright hostility. But in all three cases, the underlying feeling is the same: anger, and not a little bit of fear, to defend something that is being threatened, out of fear that male programmers will lose something that they value. That something, I believe, is masculinity itself.

The sorry institution of tech masculinity is a precarious one. And because white male nerds aren’t very imaginative about gender, tech masculinity is just a slight variation on cisheteronormative masculinity as known across Western society. That is to say that men, especially white men, are taught two things: First, that being a man is the most valuable thing they have. Second, that to show that they are men, they must show that they are not women. They are taught that they’re not born male, that their maleness doesn’t come from within, but rather, that they must prove it over and over. One of the easier ways to prove that is to be an engineer, a programmer, a “Real Hacker.” This works at least as long as most people believe that Real Engineers are men.

Thus, excluding women is not an “honest mistake” in open source; it’s deliberate. Gendered language performs some of the work of exclusion by reinforcing the message that female programmers are exceptions. Since no one can pretend that all programmers are male, the next best thing is to treat non-male programmers as non-representative examples of the category. An exception isn’t quite real and can be disregarded: consider the “fake geek girl” trope. Solely using “he” in examples dovetails neatly with dismissing women programmers as “fake geek girls” – denying representation restricts all of our imaginations and narrows the boundaries of what we find acceptable or even conceivable. Joseph Reagle, in “Free as in sexist?”, wrote about ways in which even the most mundane aspects of geek culture serve as markers of spaces that are not for women.

What does make tech masculinity different from hegemonic masculinity is its construction of power as grounded in demonstrating logical or intellectual superiority, rather than in superior physical strength. In both cases, it’s only the appearance of superiority that’s necessary. If you can win a fight by not getting into one because your opponent thinks you’ll surely kick his butt, you’ve won. And if you can win a fight by citing an online list of logical fallacies, often, you’ll also win. So, violent enforcement of masculinity in tech usually looks like words. As people whose job it is to literally change reality by building systems that are made of language, programmers know that language shapes reality, even as they dismiss criticism of their language as triviality or as “political correctness.”

But it’s not only words; this kind of violent enforcement of masculine norms is one of the things that guarantees that tech conferences — some of the rare occasions where people in a given tech community meet face-to-face — will continue to be “dark alleyways”, as Nóirín Plunkett put it.

Disrupting Gender

We know that programmers don’t really think language is trivial from how many of them react to criticism. Perhaps one misplaced pronoun might be a mistake. Digging in one’s heels and defendingone’s mistakes against all criticism, in the way that Ben Noordhuis did, or responding to criticism with a torrent of sexualized abuse, in the way that the IRC interlocutor on #rust and so many others have done, is never an accident. It’s a political decision and needs to be addressed politically.

We need fewer well-intentioned essays addressed to bros with good intentions about why sexist language might seem good but is bad. In the tech feminism community, we’ve been writing these essays for most of a decade. The systematic use of abuser tactics to control conversations and shut down criticism continues. These conversations go on and on, and happen over and over, each one seemingly unencumbered by the lessons of the previous one — what’s happening isn’t a conversation at all, but rather, a power struggle.

To me, all the defensiveness and fear that many men in tech exhibit about masculinity, and their use of their profession to shore up their gender identities, is all the more poignant because what they’re defending is just one big lacuna. The only way for these men to escape — for all of us to escape the war that they’re waging — is for them to redefine their own masculinity, to define themselves in terms of what they are instead of what they’re not. For some men, this will be challenging, but it will take less effort in the long run than the alternative does – that is, constantly lashing out at women as well as any men who are classed as gender traitors. It will also take less effort than living in fear that one will be unmasked as an impostor, exposed as something short of a real man.

To get to a better place, I also think we’ll have to look harder at something that’s perhaps even more of a taboo in tech than sexism: racism. Whiteness is another identity that is defined based on what it is not. And while not all nerds are white, Mary Bucholtz’s article “The Whiteness of Nerds: Superstandard English and Racial Markedness” shows the extent to which at least in the United States, the white majority in nerd-dom builds its identity around maintaining themselves apart from African-American vernacular and other influences on culture.

As I’ve shown, part of the shaming directed at people who talk about sexism in tech is that they are diverting discussions in order to “make everything about gender.” Who really makes everything about gender in tech? Women don’t. Feminists don’t. In fact, women and feminists are for the most part tired of talking about gender in tech, and wishing they could stop talking about it so that they could get some work done that they enjoy. The people who make everything about gender are that subset of men who need to make their participation in technical communities a way to perform their masculinity, and who suffer from that failure of imagination that makes them believe that to be a man, it’s both necessary and sufficient to prove you’re not a woman.

Disowning oppositional sexism, which means disowning masculinity as we know it, is a project that ultimately needs to be pursued at every level of society. But that shouldn’t be an excuse not to work on it in the context of tech. Changing people’s hearts and minds is hard, and ultimately can only happen when they want to change. But that doesn’t mean there aren’t visible markers we can work on. Expecting and insisting on gender-neutral language is a place to start: it’s an actionable and measurable goal.

People of all genders can interrogate their own language so that they can better serve as a model for others; men, in particular, also have the power to influence other men about their use of language. This will take courage — even feminist men often have internalized fear that to speak up in this way will take away some of their privilege, or at least expose them to embarrassment. But you can’t dismantle kyriarchy while hanging onto your own male privilege, so this work will have to be done. We need to stop choosing the safe approach: not making waves, not disrupting the way in which men use gendered language to dominate and control. I don’t know exactly how to do that, but I hope that what I’ve shown is that representation is worth working for.