How we’re making our software teams inclusive at Linktree

By Marcus Turewicz and Kaitlin Walsh

At Linktree, us engineers are working hard behind the scenes. Not just to write awesome code, but also to foster and create an inclusive environment for our teammates. Part of this is to ensure we use inclusive language day-to-day. If you need a little definition of what inclusive language actually is, we’ve got you:

But why is this important to us? Well, it feels only natural to create an environment where each and every one of us feels included, supported, and respected for who we are. At the end of the day, we are still humans with diverse and exciting lives and backgrounds. So, we did a presentation for our team and now we have written this article to discuss what we are doing to make Linktree’s engineering team super inclusive and welcoming of everyone.

At the core of inclusive language is the need to ensure that everyone is seen and heard regardless of physical, social, or cultural differences. Being conscious of the language we use is key to ensuring that no one is excluded. Let’s dive into how we do this.

The first step is to update any insensitive terminology you might be using. This includes anything in the codebase and documentations, but this also includes maintaining awareness of your day-to-day vocabulary. 

Consider the layers of meaning

The history of a term matters, but connotations gained since the coining of the term matter even more. Therefore, even though a word’s origin might not be traced back to an offensive meaning, its contemporary impact is what’s important.

For example, though the software terms “whitelist” and “blacklist” aren’t necessarily tied to racial distinction, the terms and their technical impact reinforce the idea that black is associated with “bad” and white is associated with “good.” These kinds of terms are segregating and, as such, we have replaced these terms with “allowlist” and “blocklist”.

Here are some more examples:

USE – DON’T USE

allowlist –  whitelist

blocklist –  blacklist

clear box testing – white box testing

functional testing – black box testing

core concept – first-class citizen

maintenance, upkeep – housekeeping tasks

Avoid metaphors

Favour direct descriptions of actions and roles. Metaphors can have hurtful hidden meanings and can have different interpretations depending on the context in which they’re delivered. In other words,

The purpose of using metaphors is to simplify complex technical concepts, but using the wrong metaphor does more harm than good. 

For example, people use the phrase “off the reservation” without considering its origin. The reservation system — and being “off the reservation” — stem from the history of Indigenous communities across North America being legally and forcibly restricted to reservations by government bodies. So, it is clear how the casual use of the phrase can be hurtful, as it undermines the experiences of Indigenous communities.

Some other terms that you may often see in computing are “master” and “slave” — with roots in slavery and anti-Blackness, it’s quite obvious why you should stop using them. 

The list below shows possible replacements for offensive metaphors like the ones mentioned above.

USE THIS – NOT THIS

primary/secondary – master/slave

main branch – master branch

lead, manager, expert – master

against the grain, counterproductive – off the reservation

Focus on people

When referring to people with disabilities, we should always focus on their abilities first. We want to see people for who they are and so we avoid using categorical terms as a way of defining who someone is. 

Many prefer the term “people with disabilities” over “disabled people.” Moreover, you should avoid focusing on the person’s circumstances if it’s not relevant to the topic of discussion. 

It’s important to be aware of your own biases and assumptions. If you’re unsure how to address different communities or individuals you’re working with, it’s both respectful and helpful to ask about their identity and preferred language.

USE THIS – NOT THIS

creator/visitor – user/consumer

creator/visitor who uses a screen reader – user with visual impairment, blind users

deaf or hard of hearing – hearing impaired

flagship, established, rollover, carryover – grandfathered, grandfathering, legacy

person who uses a wheelchair – wheelchair person

Avoid ableist language

Ableism refers to any type of prejudice towards people with disabilities. Ableist language includes words or phrases that convey judgement, bias, or dismissal. It also includes using disability-related terminology metaphorically and making unnecessary, inaccurate assumptions.

Ableist language is harmful regardless of whether it is used to directly or intentionally insult or dismiss people. Even when referring to tasks or situations, it’s important to avoid ableist terms and we want to avoid it when discussing business practices, social situations, and software. 

For example, the phrase “sanity check” is sometimes used to describe a quick review. Even though it is not being used to describe a person, the term still carries harmful connotations. Instead, you can ask a teammate to perform a “logic check.”

There are also more subtle and indirect forms of ableism in language. For example, if something is only designed to be easy for people with specific abilities, it would be incorrect and ableist to broadly label it as “easy.”

Here are some terms to implement that can help you avoid ableist language and assumptions.

USE THIS – NOT THIS

quick check, logic check – sanity check

baffling – crazy

placeholder value, placeholder variable – dummy value, dummy variable

hinder – cripple

person without disabilities, neurotypical person – normal person, healthy person

neurodivergent person – mental/mentally ill person, mentally disabled person

Avoid violent language

You should always avoid using violent language, as it’s unnecessary and distracts from your meaning. 

For example, avoid using the terms STONITH (shoot the offending node in the head) or STOMITH (shoot the offending member/machine in the head). Instead of using these violent and graphic depictions, you can simply use a phrase like “stop the failed nodes.”

Avoid using terms like “hang,” “hit,” “nuke,” “kill,” and other unnecessarily aggressive terms. Remember that in addition to these phrases being uncomfortable, you could be interacting with someone whose life has been directly impacted by these different forms of violence.

The following are some violent words you should stop using and their possible replacements.

USE THIS – NOT THIS

perimeter network – demilitarized zone (DMZ)

stop responding – hang

stop/isolate failed nodes – STONITH/STOMITH

halt, stop – kill (a process)

call – hit (an API)

delete – nuke

Avoid idioms and slang

Using idioms and slang excludes groups whose first language isn’t English or whose cultural context is different from your own. For instance, saying “it’s about to go down” might mean one thing in English, but it could mean something else entirely when translated literally. 

In some instances, the direct translation of slang and idioms may be offensive in other languages. To successfully and respectfully communicate your ideas, it’s best to use clear and literal language.

How can you implement inclusive language?

As these examples have highlighted, it’s extremely important to be conscious of our words.

As you begin to implement inclusive language into your workplace (and life), start by using the inclusive terms included in this article. You can apply these terms to both verbal and written communication. 

It’s important to acknowledge that you might sometimes slip up and make mistakes, especially when using culturally or technologically normalised words. When this happens, the best thing to do is to apologise, take note, and consider what word you may use next time. Outwardly acknowledging a mistake to the group is a great way to help reinforce the language changes that are needed and this way your teammates can learn and grow with you.

Where possible, update existing code and documentation to use inclusive language. Use the examples we’ve shown above, consult the references section at the end of this post, and start building your own inclusive language guide!

Even though issues surrounding inclusivity can be difficult to talk about, it’s important that we continuously learn how our word choice can be harmful to others. Furthermore, call out non-inclusive language. Don’t be afraid to correct someone if they use an offensive word, whether intentionally or not.

What is Linktree doing?

Linktree has taken steps to implement inclusive language both internally and for developers. As a first step, we’ve worked through our source code repositories and documentation to replace any instances of a “master” branch to read “main” branch. While this change may seem insignificant, developers working with these repositories and documentation can see the word “master” many times a day. Removing this language is one step we’re taking to denormalize this commonplace reference to slavery, and support developers who may be deeply impacted by the casual use of this term.

Additionally, we’re continuing to develop an internal Inclusive Technical Terminology guide that our engineers can use. This guide (which includes all of the terms and phrases highlighted in this article) is a resource to ensure we are writing inclusively when it comes to repository names, branch names, variable and function names, documentation, use cases, user stories, architecture, and during technical meetings.

Conclusion

Inclusive language is one of the ways we can create a more diverse community in software engineering. It’s important to be conscious of the words and phrases we use — even when it comes to the development process — and their impact.

Some of the terms we should avoid are culture-specific metaphors, ableist language, violent language, idioms, and jargon. Always focus on the person and their abilities first before their circumstances. When describing processes, opt for straightforward words with no cultural context, and ensure they aren’t unnecessarily violent. 

By removing words that deliberately outcast certain groups, we create an environment where everyone feels welcome, respected, and safe. 

References

There are lots of great resources out there that provide guidance on maintaining Inclusive Language in technical contexts. We could not have developed our Inclusive Technical Terminology guide without the help of the following references and we encourage you to read them too!

• UCI Inclusive IT Language Guide
• Microsoft Bias Free communication
• Apple Style Guide
• Google Write Inclusive Documentation