I am sure many of us have recently seen news articles about the move within the technology community to use more inclusive languages. While this is not new, it is receiving more attention in the past several months in light of the Black Lives Matter and other social justice movements. I am delighted to see the progress, and would like to advocate for all of us to pay attention to how we communicate with one another. 

What is an inclusive language? 

Inclusive language is the style of language that avoids expressions and terms that could be considered sexist, racist, exclusive, or biased against certain groups of people. You may be familiar with everyday words like "flight attendant" (as opposed to "hostess/stewardess"), or "work-days" (as opposed to "man-days"). 

When it comes to technical writing — and I am talking about our documentations, manuals, and designs — traditionally, we have used terms like "master/slave" to describe relationships between components. And, we’ve used "blacklist/whitelist" to describe items that are disallowed/allowed. These terms have been deprecated over the past several years in favor of more inclusive terms such as "primary/replica,” “primary/secondary" or "allowed/disallowed list." Not all of these changes are easy. A change initiated to remove “master/slave” terms in Python caused heated debate among the developers

We should also consider other aspects of diversity other than gender and race when you consider inclusivity, such as physical and mental disabilities. For example, instead of saying "the application uses an insane amount of memory and disk space", it is better to say "this application uses an extremely large amount of memory and disk space." 

I do not intend to provide an exhaustive list of exclusive terms and their alternatives here. There are many sources out there that provide good examples. I encourage you to check out Google's guideline for writing inclusive documentations.

Why is this important? 

For certain terms like master/slave, it is obvious that the reason is to avoid legitimizing and normalizing slavery. However, we sometimes encounter debates when it comes to other inclusive terms and the style of writing. Some would argue that the origin of the terms or words is not sexist/racist or not exclusive in nature. We should not focus on the root or the origin of the terms. Instead, we need to understand the impact of them. Blacklist and whitelist reinforce the association of "black" with bad (or banned, barred) and "white" with good. Using terms like "sanity check" or "crazy amount" paints a negative undertone to mental disability. These notions further drive conscious and unconscious biases among us. If we want to progress towards inclusivity and diversity in our workplace and our community, we have to push for the idea of everyone feeling they belong, feeling they are peers, knowing they are equal to others. 

What can you do? 

This is a delicate and complex topic, and we sometimes avoid talking about it. That needs to be changed. I must admit that, as a proud Inclusion & Diversity advocate myself, I had mostly paid attention to the obvious when I communicated in the past (for example, not using "master/slave.") I was glad when someone corrected me when I used the term blacklist on a conference call. Not understanding the reason behind it, I researched and studied more on the topic. I learned that it was just the tip of the iceberg.  I also realized that people do not have the same sensitivity level for tolerance. I have learned to argue, to persuade and to change minds. 

So, please learn. Listen. Be open-minded. Understand that there will be concepts that we, individually, don't fully comprehend or don't know today. We need to feel comfortable to be educated. Know that words matter, even in the space where we convey facts and truths like our technical documentations. If you are in a position to influence others, strive to foster an inclusive environment where everyone feels welcome and feels comfortable bringing themselves to work. 

Ned Visolyaputra

Senior Technology Architect

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog