Racist Language in Software
Last year, amid renewed racial reckoning, organizations around the world took a sharper look at their own practices and habits to weed out those unknowingly rooted in racism and bigotry. Unfortunately and yet unsurprisingly, many problematic processes were unveiled that most people would have previously never even considered to be questionable. While reflection efforts are certainly a step in the right direction, there is still so much more for the tech community to do.
It’s clear that software as a field is deeply lacking in diversity. Much introspection and effort has been invested to change this reality in recent years, but it wasn’t until mid-2020 that these examinations turned inward onto the core of software itself: the code.
Removing Racist Terminology from Code
There has been a widespread movement amongst big software players like Git, Apple, Linux, and Google Chrome to remove racist terminology from code. There are two offending term pairs used most frequently that are the main points of discussion.
The first pair of terms is “master” and “slave,” used to imply a relationship between one software entity (the master) that controls the workflow of other entities considered to be subservient (the slaves). For example, you may have one “master” database and several “slave” databases which serve as backup duplicates of the master’s data. Appropriate alternatives that have been suggested include “leader” and “follower,” or “primary” and “secondary.”
The second pair of terms is “blacklist” and “whitelist.” Items on a blacklist are implied to be disallowed or dangerous, and items on a whitelist are implied to be allowed or safe. For example, websites with malicious scripts may be “blacklisted” by search engines so that they don’t appear for users, or trusted tools may be “whitelisted” by a laptop’s security interface which indicates that they are safe to use and allowed access to more parts of your machine. A suggestion for replacing these terms is “allowlist” and “denylist,” which is also debatably more straightforward.
The racist implications of these terms are clearly displayed here. Considering that the majority of employees at the world’s top tech companies are white and male, however, historically there may not have been the awareness to see these words for what they are — exclusionary and discriminatory. Unfortunately, even today the efforts to remove these terms from code has received pushback from some developers, who usually argue something along the lines of it being “more effort than it is worth.” But for people of color, having to develop using these terms could be considered daily, harmful microaggressions.
Racism in Tech Doesn’t Stop at Code
If racial biases are built into the language of a product, how can that product truly serve to combat systemic racism? It’s important to consider the language we use, both with each other and within the code we write, to ensure we are creating an inclusive space and products that serve everyone. Removing biased language in code — but not actually working to bring more diversity into tech — is just barefaced virtue signaling. It’s not enough to just change our language. We also need to act.
As members of the tech community, we are largely afforded great comfort, wealth, and privilege. There are many critical actions that should be taken to use our position of privilege to combat racism within our teams, our products, and the communities we serve.
We know that anti-racism work is ever-evolving, and there is no “done.” We have a lot more to unpack and unlearn:
- Educating ourselves and each other about the implications of our language
- Defining and reinforcing appropriate alternatives
- Norming around anti-racist language with our partners
- Continuously holding ourselves accountable
What changes has your team made to address racism within products? I’d love to hear about your experience of leading these conversations: reach out!