When Apple’s new credit card went online, it immediately caused a gender controversy. Women were being approved for much lower credit lines than men. The defence Apple gave was that their algorithm for deciding credit lines is gender-blind. Many pointed out that this was the exact problem with the algorithm. Without being coded to recognise gender, the algorithm was able to discriminate based on other factors, such as shopping location, which is often associated with gender.

The Apple credit card controversy is just one in a long line of troubling instances where gender and code come into conflict—we speak of Alexa and Siri, not Alex and Simon. Much of this conflict might come down to the very simple fact that all code is binary and made up of a combination of 1s and 0s. Gender, on the other hand, is not binary, and many gender-queer or gender-nonconforming people have begun to speak out about the difficulties they have expressing gender online. But does the conflict come down to binary code itself?

The expression of gender is not a problem related solely to coding languages. It is a linguistic problem we face with spoken languages, too. Code has many of the linguistic elements that other languages do, and can be examined linguistically. Language learners are often told that humans are prisoners of language. We are only able to express what a language allows us to, this sentiment suggests. I do not think this is remotely the case. There are contingents within language communities who find workarounds for linguistic tough-spots, and thought processes often take us beyond the limits of the grammar of the languages we know.

Take the issues of gender and spoken languages. Some, like Mandarin and Finnish, have evolved to exclude gender completely while some, such as Spanish, Portuguese, French, and Arabic, are heavily gendered languages that rely on a gender binary even when discussing inanimate objects or abstract concepts. There are movements, though, that are pushing for more flexibility in these languages. A gender-neutral French textbook was published in 2017, and there is a decades-long movement to open up Arabic to more affirming expressions of sexualities and genders. The same sort of movement needs to happen in the computing industry, even though there might be as much backlash as there was over the French and Arabic movements.

Recently, Meredith Broussard, a professor of data journalism at NYU, wrote about the difficulty of expressing gender through binary code and some of the changes that the computing industry needs to make to accommodate non-conforming individuals. She says that “in the 1950s, when modern computer systems were first designed, gender was generally considered fixed.” However, even though our notions and experience of gender have changed radically since then, the fixed-gender binary informs the way applications are written.

The concern Broussard has is the limited options users have for expressing gender in editable fields. While some companies like Facebook, which requires users to identify a gender when they join, allow for some fifty gender options, the problem remains with how that data is stored. When one’s gender data is stored, packaged, and sold to third parties (that’s a whole other issue), it is expressed simply “as male, female, or null.” It all comes down, Broussard says, to “whose values are encoded in the system.”

Can coders, many of whom are at the forefront of challenging gender norms, write more inclusive code? Or is the problem even with code itself—language itself? To find out if gender is really that difficult to code for, Screen Shot talked to Kyle Gorman, a computational linguist at the CUNY Graduate Center. Computational linguistics focus on how computers can be used to address the common structures of language and how to build speech and language technology.

Gorman agrees with Broussard’s complaints about the computing field. He says, “In the computing world there is a cult of simplicity, and the complication of code is a design challenge.” That challenge is further complicated because of the aversion to complexity embedded within the field. However, Gorman does not see binary code itself as the primary problem. Instead, he blames “the laziness and normativeness of our society.” There are two solutions Gorman provides as answers to our computational gender woes. First, we can regulate laziness out of the system. The EU has had some success with its policies on gender that could be used as a model. Second, the computational field can model other linguistic movements such as the solution to the gendered Latino and Latina designation that has seen a successful grassroots movement to use the simplified and gender-neutral Latinx. Technology, in Gorman’s opinion, is not doomed to repeat the historical linguistic exclusion of language.

If gender and language are both social constructs, then we can change language to more accurately express gender. And we must, since language, whether spoken or coded, is the way we make sense of the world and it of us. Broussard challenges the aesthetic standards—the cult of simplicity Gorman references—the computing world has set when she criticises the field’s inclusivity. “Elegant code,” she says, relies on giving users “as few opportunities as possible to screw up the program with bad data entry.” This is a problem if you want to design a program with as many options for users to express their identity. She goes so far as to call this “data violence” against trans and non-conforming individuals. “Language itself,” says Gorman, “is a technology, because it allows me to get thoughts from my head into your head.”

If those designing computing technologies are going to open up users’ ability to express their gender, then they need to do away with the notion of the primacy of simple, elegant code and give the user, whose identity is increasingly tied to that code, as much agency as possible for expressing it.