DEV Community

loading...
Cover image for Celebrating Pride: How to write gender-neutral coding tutorials
Educative

Celebrating Pride: How to write gender-neutral coding tutorials

Ryan Thelin
Just a tech writer and coder striving to get better every day.
Originally published at educative.io Updated on ・5 min read

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.

Cartoon checklist

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.

X to checkmark

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.

Continue reading about social justice in tech

Discussion (7)

Collapse
brojenuel profile image
Jenuel Oras Ganawed

I think using the "He/She" is not a problem.

Collapse
javacode7 profile image
JavaCode7

Same here. The problem only arises when using the #lgbtq tag.

Collapse
organicaudio profile image
Scott Eh?

You both should take a moment to learn about the place of bias your coming come and the privilege you have.

@javacode7 the fact that you have correlated that problems arise only when the queer community is involved is concerning.

It all comes down to respect. Respecting someone for being their true self. Respecting someone by addressing them by how they choose to be addressed. Respecting someone's thoughts, skills, and what they can contribute.

LWhat is the value in alienating and potentially devaluing someone that could be a colleague, customer, or employer with terminology that doesn't add value to content and often when verbally communicated sounds extremely awkward.

It's like the coding principle of DRY. Why make create situations for yourself where you would potentially need to localize your content to multiple audiences to achieve the same impact and results you want?

That makes no sense.

I haven't even touched on the idea that networking is crucial in tech and being able to interact positively with all types of people, your are going find yourself missing out on opportunities that being an ally could have awarded you.

Thread Thread
javacode7 profile image
JavaCode7 • Edited

This makes sense. I apologise for what I said and I am starting to see where this article is coming from... 🤔. What is the "privilege" you mean though?

Thread Thread
organicaudio profile image
Scott Eh?

Diversity and ethnics aside, if you simplify the task down to inputs and outputs the amount of additional effort needed to use the suggestions outlined in the article is negligible (I'd argue even zero). But on the flip side, the dividends can be huuuge.

Therefore: It makes economic sense not to be a jerk to people. 😆

Thread Thread
javacode7 profile image
JavaCode7

I see your point.

Collapse
ruthmoog profile image
ruthmoog

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.