At Indeed, inclusion extends beyond employee resource groups and celebrations. Diversity of background, experience, and thought makes for a stronger workforce, more effective decision-making, and powerful innovation. To foster inclusion, we want to build a psychologically safe environment at every level and in every area of the business. That’s why we’re removing terminology that works against such inclusion from our codebase.
Diversity and inclusion are ingredients for success. Leaders of Indeed Amsterdam’s Women at Indeed employee resource group (l-r): Edwin Moses, Trudy Danso-Osei, Freek van Schaik, Renske van der Linden, and Valerie Sampimon.
What does technical terminology have to do with inclusion?
Like all words, technical terms have connotations that give them immense expressive power. Some connotations are well known and generally understood. Others depend on context and are understood differently by people with varying lived experiences. The original etymology of a term often has little to do with the connotations it accrues over time.
Computer science and software engineering employ many terms that are convenient, meaningful, and useful. However, some terms ask groups of people to ignore the powerful negative and exclusive connotations they carry.
The terms “master” and “slave” exemplify this. Some engineers see these words and are privileged to deduce a benign connotation—a slave is a subordinate process that acts in accordance with the demands of the master. However, for many people, particularly people of color, these terms immediately conjure images of human slavery’s horrors. This connotation doesn’t just exist in the context of one country’s history, such as American slavery. With an estimated 21-45 million people currently enslaved worldwide, the terms master and slave represent both an historic and current global humanitarian crisis.
Many other terms have similar negative connotations. Words that associate colors with value judgments, such as “blacklist,” and language around the exploitation or denigration of cultures, such as “tribal knowledge,” represent just a couple. Ableist language such as “lame” and “blind” used in the wrong context can negatively impact people with disabilities. People continually fight bigotry and prejudice based on these characteristics, and these terms invoke and perpetuate those injustices.
Some of these terms might surprise those of us who don’t share the lived experiences of marginalized individuals. But when our colleagues tell us we are using terms that exclude or hurt them, we should trust them and find new words to use.
Starting the conversation
Even before Indeed officially introduced inclusion and belonging as one of our company values in 2019, our engineers began removing problematic terms from our technology.
We started by opening up the discussion on our internal wiki, with internal blog posts and a dedicated content hub for identifying and deprecating exclusive terminology. All engineers can contribute to and comment on the Inclusive Terminology wiki page. From contributions made there, we created a non-exhaustive quick reference guide to help each other make responsible terminology decisions.
| Instead of | Use | Why |
|---|---|---|
| master* | primary, main, trunk | These terms represent an inherently oppressive relationship.
*The removal of “slave” from the set in common usage does not remove the implied oppressive relationship. Historically, the usage of the term “master” in relation to a Git branch stems from a master / slave relationship. |
| slave | replica, secondary | |
| whitelist | allowlist, unblocklist | These terms imply a culturally specific binary of good versus evil. |
| blacklist | denylist, blocklist, banned | |
| backlog grooming | backlog refinement | “Grooming” is a term with specific legal meaning in British English. |
| tribal knowledge | institutional knowledge | “Tribe” is a loaded term with negative connotations for First Nations and African communities. |
| grandfathered | legacy, pre-existing | Grandfather clauses originated from Jim Crow era discrimination laws in the United States. |
Each engineering team chose how to implement the new language in their code. Then, teams shared best practices and processes. We continue these conversations today.
Case study: Replacing “master” with “primary” in a Git project
Renaming the master branch of a Git project is not a trivial exercise, especially for projects with lengthy histories. Recently, our Design Systems team completed this work for one of their projects. To do this, the team:
- Cloned the master branch and named the clone “primary.”
- Updated the default branch in GitLab from master to primary.
- Locked down the master branch. It still exists for historical purposes, but it can no longer be used.
- Applied the former settings for the master branch to the new primary branch.
A couple of issues could arise in this scenario. For example, a user could create a branch off master before the team created the new primary branch. Because primary and master share a common history, the user could theoretically merge the feature into primary. To mitigate such issues, the team enacted a code freeze while they made the change. They also tested their process on a smaller project before renaming the main project.
Tangible results
To track this work, Indeed engineers leaned on Atlassian’s Jira, our tool for software development tracking. We added a label to Jira tickets that involve inclusive terminology so we can filter and sort them. This gives us a high-level view of where exclusive language exists, our ongoing efforts to remove that language, and our progress. To date, we’ve closed 97 of 113 issues and counting.
Pie graph showing the number of Jira issues labeled “inclusive-terminology” by status, with 97 closed, 1 deferred, 9 on backlog, 1 pending review, 2 pending triage, and 3 in wish list status
Challenges to making this happen
This work sparked lots of discussion among our engineers. The last thing we wanted to do was turn these language changes into a policing and shaming process. So, we decided to make this a grassroots effort instead of a top-down mandate. That way, everyone is empowered to respectfully discuss terminology changes while learning from one another. Leadership provides support and guidance when necessary and actively participates in the conversation.
One subject that came up in these discussions was cost and level of effort. Changing terminology throughout all our products is a long-term project that requires many engineer hours. In fact, as of today we still need to remove over 5000 instances of the term “slave” from our codebase. We’re committed, and the psychological safety generated by this work far outweighs the time and effort required to remove exclusive terminology.
A way forward
Language constantly evolves to meet the needs of those who use it, and words fall out of fashion as we progress. Because of this, we know changing the terms in our codebase is an ongoing practice, not a one-time effort.
We continue to document words we want to replace and offer suitable alternatives. We avoid using those terms in any new code and ask our vendors to avoid those terms in their products as well. As we change our codebase, we methodically and carefully locate and replace the existing usages.
We still have work to do. We constantly increase our awareness of exclusive terms and their implications, and we engage in respectful conversations about these topics with each other. Together, we want to create a work environment that is psychologically safe, inclusive, and welcoming for all people at Indeed. By sharing these practices, we hope to model inclusivity and improve the tech industry as well.