Removing Racist Terminology from Code Itself
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!
What’s a Rich Text element?
H1 example
H3 example
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
.png)