Pride Month is an annual celebration for the month of June that is dedicated to celebrating Lesbian, Gay, Bisexual, Transexual, and Queer people and culture. It is also a time to reaffirm support for the LGBTQ+ community's continued struggle for equal rights and treatment in society.
The first Pride celebration was in New York in 1970 to remember the 1969 Stonewall Uprising, a demonstration oppose to the hate-fueled police raids on the Stonewall Gay club. Many historians view this and the following Pride celebration as a tipping point in the United States Gay Liberation Movement.
Educative is committed to building a better, more inclusive future for LGBTQ+ people, both in the developer community and the world at large. One way we can all do this is to think critically about how we write coding tutorials and examples.
Today, we'll explore how you can make your educational content more approachable for Queer and Non-Male identifying readers and increase the performance of your content at the same time!
Here’s what we’ll cover today:
Never miss Educative content again
Sign up for our free, bi-monthly newsletter to receive the latest in tech news and trends, right in your inbox.
Learn more about our Newsletter
How gendered language hurts content
Many online coding tutorials default to male pronouns. The most common instances of this are when discussing functionalities or when providing a hypothetical example. While the writers likely do not intend to offend, this gendered language can make Non-Male readers feel unwelcome in the developer space.
For example, it's common to find articles that say something like:
"A developer can use an array to store integers. This will allow him to access these integers in the future."
Here, we can see that the writer began with a gender-neutral term, "developer", but has then included a male pronoun, "him". The writer has therefore implied, perhaps unintentionally, that developers are inherently male.
Similarly, many writers will default to writing hypothetical examples using male pronouns exclusively. This is especially common for examples that discuss management or administrative positions.
For example, a tutorial may include sections like:
"Imagine we have a Product Manager that wants to connect his app to a database. He knows the database uses a NoSQL schema."
Like the first example, this hypothetical example implies that Product Managers are inherently male because it is an unspoken assumption.
Most male readers may not notice this because it matches their experience; they are a male developer so the developer being referred to as male seems natural. However, this type of implication is very disheartening for Non-Male readers because it can make them feel like an outcast or an exception within the developer community.
While a single instance of gendered language will not hurt the reader's sense of belonging in the community, these individual instances culminate over time to steady wear down the Non-Male developer's comfort as a member of the community.
We should avoid this because it excludes groups of people from the community and profession based on their natural-born characteristics.
From a content writer's perspective, the success of your content relies on the reader's passion for the profession and comfort level within the community. Readers who do not feel welcome in the community or feel out of place as a developer are not going to read community-made coding tutorial content. These are valuable readers that have been lost but could be easily retained with just a few changes to how we write tutorials as a community.
Simple changes to make tutorials more inclusive
We can easily avoid these problems by paying attention to the implications of gendered language and replacing it with a gender-neutral alternative.
Writing in gendered language is a hard habit to break so don't worry if you have to write first then revise when just starting out. Just making these small changes bit-by-bit will make a big difference to Non-Male readers.
Functionality explanations
The functionality of a coding concept is the same regardless of the gender of the user.
Therefore, we don't have to specify gender when explaining the concept and can simply use impersonal, gender-neutral language like "the developer" or "a developer". We can also replace any pronouns with "they/their", which are gender-neutral and can be used as a single or plural pronoun.
We can revise our previous example to instead be:
"A developer can use an array to store integers. This will allow them to access these integers in the future.
When discussing multiple people, use their titles in place of pronouns to avoid confusion:
The developer designed the app to learn from the user's in-app behavior. The user can limit the type of data tracked by the app.
Here, it's better to use "The user" instead of "they" because it makes it clearer which of the two established people we're referring to.
Both examples leave the developer as a blank slate to explain the topic and allow readers of all kinds to interface with the topic.
Hypothetical examples
Hypothetical examples are more specific and human-focused than explanations of abstract concepts. It's therefore even more important to use gender-neutral language to avoid making implicit claims.
Let's look back at our original hypothetical example and make it better:
"Imagine we have a Product Manager that wants to connect their app to a database. They know the database uses a NoSQL schema."
We can replace all male pronouns with gender-neutral pronouns to avoid making assumptions about the gender of the product manager. Since there is no second person in this example, we have no risk of confusing the reader by using only pronouns.
The problem with "he/she"
Many tutorials will use "he/she" and "his/her" in place of pronouns to try to include all readers.
For example, it's common to see a sentence like:
"The developer can use Azure services to access cloud storage. He/she will instantly gain access to many gigabytes of space and can access his/her data anywhere with an internet connection."
While this comes from a good place, using these either/or pronouns unintentionally excludes Non-Binary readers.
Similar to "he", "he/she" implies that only people that identify within the traditional gender binary are welcome within the community. This format has a history of being used for transphobic and queer gatekeeping and can offend Non-Binary readers.
Instead, it's better to use "they", "them", or just titles. Doing so not only invites more demographics of readers to engage with your content but also reduces visual clutter by cutting the forward-slash from the sentence.
Wrapping up
While it can be difficult to break the habit of using gendered language, it makes a big difference to Non-Male members of your audience and keeps them engaged with your content. It can be tricky to get into the habit of writing with gender in mind but you don't have to make sweeping changes at once.
In the end, what's important is that you're doing your best to welcome all kinds of developers to the community and improve your community engagement skills one article at a time.
Top comments (11)
While I agree in principle, I think this post blows things out of proportion quite a bit.
There's a meaningful difference between referring to an example developer, and addressing the reader. The latter is when it's really important to be gender-neutral.
Great advice, I wholly agree.
When I read 'he' or 'he/she' in coding tutorials or posts, I find it jarring. Using 'they' is more inclusive, and less distracting.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.