As a bonus to the column below this month, Rafat Sarosh recently posted a new interview with me about being a great engineering manager and lead as part of his marvelous Masters of Technology video series.
Microsoft has long been associated with popularizing the personal computer (the PC). However, people don’t talk about PCs much anymore. Now, it’s about phones, phablets, tablets, laptops, and desktops. People don’t talk about political correctness (the other PC) much anymore either. Now, it’s about inclusivity, unconscious bias, microaggressions, and cancel culture. Regardless of our desire to welcome everyone as they are and treat them with respect, we all have unconscious bias and sometimes make hurtful expressions regardless of our intent. I’m not PC, despite my best efforts over time.
Diversity and representation in the community and workplace helps. It improves awareness and can provide immediate feedback when you offend inadvertently. If people assume the best in each other and stick up for one another, they can learn how to make everyone feel welcome and appreciated. Unfortunately, some people refuse to assume the best in others. That’s wrong and hurts the entire group. Some people refuse to learn and change, even when others assume the best in them. That’s also wrong and harmful.
You can remove stubborn people from your group (see Good engineers and The toughest job—Poor performers). But what if the stubborn thing isn’t a person? What if your code, your tools, your APIs, or your documentation is offensive? What if your PC is not PC? Is it okay to have master and slave branches? Is it okay to have black and white lists? Some people might dismiss these things as just names. They could be called parent and child branches or prune and plum lists. Who cares? A name is just a name, and folks are too sensitive. Maybe, but we all have words that bother us. How do we determine which words are worth the effort to change and what words are good replacements? Let’s have a respectful discussion.
What did I say?
If you’ve always used industry-standard terminology to refer to master branches and blacklists, you may reasonably wonder why anyone might be offended. After all, you didn’t come up with the terminology. You’re just using accepted and documented names. If you’re a software engineer, you’ve learned those terms and know what they mean. There’s no reason to be offended, right?
My parents are Jewish. I’ve heard “Jew” used as a verb by people who grew up in communities where that’s an accepted use of the word “Jew.” I find that usage offensive. However, the communities that use “Jew” as a verb don’t typically include Jews as equal members.
The software community didn’t include Black engineers, women, and other underrepresented people as equal members for decades, as has been well documented lately. Several common software terms are offensive to those underrepresented people but became standardized before the offended individuals were welcomed into the software community. However, those people can’t feel welcome when they are constantly being offended, any more than I could stand working somewhere that I’m constantly Jewing.
For more on diversity and inclusion, read Growth mindset and diversity.
What should I call you?
Which words are worth changing, and what words should replace them? If a community owns the definition of a word, and desirable members or friends of that community are offended by it, then the community should change the word.
For example, say your five-person team owns a search API, and the suggested name for the filtering interface is “Laser.” If one of your team members lost sight in her left eye due to a laser, you might want to pick a different word. Likewise, if you want to hire Black engineers and have Black customers use your services, you might want to pick a different word than blacklist to refer to undesirable entries.
If you aren’t going to use “Laser” or “blacklist,” what words should replace them? You want replacement words that accomplish the following three goals: clearly describe the purpose, lack a negative connotation, and avoid overloading.
Let’s review some common examples.
- Blacklist and whitelist. You could use “prune list” and “plum list,” but that could be confusing. You could use “bad list” and “good list,” but the items on the bad list might not really be bad, just blocked. You could use “block list” and “accept list,” but “block” has many meanings in software, so again there’s confusion. I’d recommend “deny list” and “allow list.”
- Master and slave branches. Here there already exists a common and clear term for a master branch that has no negative connotation or overloading: “main branch,” which is the term GitHub is standardizing. As for “slave branch,” it makes sense to choose a term that refers to the branch’s purpose, such as “release branch,” “feature branch,” or “topic branch.” In general, they are “child” branches using the common, clear, and unoffensive graph term.
- Black hat and white hat. The cybersecurity community sure loves its hats, and it has traditionally used colors to portray the actions of bad and good actors. While many claim the hats align with old westerns, black being evil is still black being evil. Besides, it’s not about community members who accept the words—it’s about desirable members or friends of the community who are offended by the words. I’d recommend “bad actors” and “good actors,” since the connotations are intentional when it comes to cybersecurity.
I considered including “users” as an offensive term, but not too many people find it offensive. I just love the quote from one of my heroes, Edward Tufte:
Only drug dealers and software companies call their customers ‘users.’
We should say “customers” or “end customers” instead of “users.”
The communication process has broken down
For whatever reason, operating system processes are a hotbed of questionable terms. Processes don’t end; they die. You don’t stop them; you kill them. If they’re unresponsive, they’re hung. If they remain around after stopping, they’re called zombies. (Actually, that’s pretty funny.) If the parent process that spawned a child process dies, the child process is an orphan. Can’t we talk about operating system processes without bringing up hanging or orphans?
Action movies are fun, but my everyday life needn’t be filled with violence. Processes should be stopped when necessary. If they’re unresponsive, they are stuck. If they remain around after stopping, they are pending cleanup. If they lack parents, they are parentless. I don’t feel as strongly about violent terms as I do racist and misogynistic terms (like “grandfathered” or “man-months”), but next time your team is picking terms for its products, tools, components, or services, please select precise words that describe purpose and leave out the unnecessary connotations and overloading.
Many misogynistic terms can be replaced easily with gender-neutral equivalents, like grandparented and person-months. However, clearer terms for these two examples would be “exempted” and “x people for y months.”
Heeded my words not
Words have power. They bring up memories and feelings, good and bad. They have meaning and emotion beyond their dictionary definitions. If you’re going to use words, mean what you say and say what you mean.
We want desirable members and friends to feel welcome in our communities. Since the whole world uses software, we want all people and organizations to feel welcome to work on and use our products, tools, components, and services safely as intended without offense. (Undesirable hackers, profiteers, and bullies can take all the offense they like.)
If desirable people are offended by old, accepted terms, we should change those terms. Choose replacements that clearly define purpose, lack negative connotations, and avoid overloading. The desirable friends and members of our community should be made to feel welcome and included, just as you hopefully once were. It’s the right thing to do.