It is no secret the software industry has issues regarding diversity and inclusivity. The use of language can play a role in creating an atmosphere that is welcoming to everyone – or, at the very least, not uninviting.

This is why some, like André Staltz (creator of Cycle.js) and David Heinemeier Hansson (founder of Ruby on Rails) propose to change some of the words, used in our industry:

Software development still has a lot of terminology with a racist or patriarchal background. Let’s change that.

• Blacklist ➡ Denylist
• Whitelist ➡ Allowlist
• Killer app ➡ Beloved app
• Master/slave ➡ primary/replica

This is not a new phenomenon. In 2014, the Drupal team decided to change the use of master/slave terminology to primary/replica. The Django team opted to do the same: first to leader/follower and later to primary/replica. And so did CouchDB. More recently, Python and Redis also got rid of their master/slave vocabulary – albeit not without struggle.

Likewise, every now and again, the term “craftsman” or “craftsmanship” is debated. Sarah Mei (founder of Rails Bridge and architect at Salesforce) is often involved: not necessarily discussing the merits of the “software craftsmanship” movement, but because the term craftsman could be seen as unwelcoming (or, as some put it, oppressive) to those who do not identify as male.

Although I have voiced my concerns on Twitter regarding general embargoes earlier this year, I think it is beneficial for cultures to review the language used every day.

For the purpose of shaping a welcoming community through language and not alienating anyone, it is necessary to be mindful and reminded of sensitivities – especially of those not felt by the author or voiced by the people in the author’s bubble.

The “right” choice of words?

That being said, I think we should be wary of a chilling effect of sorts by automatically attacking, dismissing or silencing those who utter words or phrases that rattle us without considering context or intent. By definition, the connotation of a word differs per culture, society or social group and is subject to change over time. That is why declaring certain words as taboo, offensive or harmful and calling it a day is ill-advised and unrealistic — especially with regards to intercultural and international settings.

Speak up when you think someone is expressing themselves in a poor or potential harmful manner, but do so in a way that is not harmful itself. Be aware of the fact that a public accusation has consequences: Twitter crusades, angry mobs, witch hunts and character assassinations. Even if the accusation was later proven to be unfounded, it could disproportionately damage someone’s career forever. That is why it is advisable to presume innocence, keep an open mind, maintain a constructive dialogue and dilligently apply the principle of least harm. Reach out in private before escalating the matter in a public forum and try to provide evidence and examples for improvement.

The “right” choice of words, the boundaries between euphemism and dysphemism, approbative and pejorative, should not be determined by blanket statements but be evaluated on a case-by-case basis. They should evolve through dialogue and mutual respect. In my opinion, warnings for inconsiderate writing should therefore not unquestionably lead to self-censorship but be regarded as a starting point for understanding, empathy and conversation. I believe Alex can help with this.

The tool

For obvious reasons, I think the best thing about this tool is its name: alex. 😉 Joking aside, alex is a tool made by Titus Worm designed to check your writing for possible insensitivities.

Alex utilizes unified, retext and remark for processing text and markdown. The dictionaries at retext-equality and retext-profanities are used as a corpus of harmful language. If you think another word should be included, you could create a pull request in either of those repositories. If you are ever in need of another text-processing tool in JavaScript – for instance for determining the readability of an article, detecting the sentiment of a text or checking for repeated words, passive voice or redundant acronyms – you may want to check out the other retext libraries.

Alex can be integrated with several JS-based programs. There are integrations for Atom, Sublime and VSCode, but also for Slack and Ember.

Exceptions

Sometimes, a word is not used inconsiderately or inappropriately. One could, for instance, refer to the word as-is, quote someone who used this word precisely or use a word in a non-harmful context. Likewise, one could respectfully disagree with the tool’s assessment.

Even though alex is configured to recognize whether a word is referred to in a literal sense or not, a .alexrc file can be added, an alex field can be added in package.json or (partial) exception clauses can be inserted into the source document.

If I wanted to silence the word “execution” in the entire document, this can be done by prepending the following comment to your text, markdown or otherwise:

<!-- alex disable execution -->

You could decide to re-enable the check later in the file. Alternatively, you can disable the check for a specific subsequent block of text, such as a paragraph, quote or list:

<!-- alex ignore execution pop -->

As you can see, you can control multiple messages in a single statement.

Continuous integration

The blog you are reading right now is built using a static site generator called Hugo. I have configured GitLab CI to let Hugo generate HTML upon each change on master. The results are then hosted via GitLab pages.

As with (other) programming projects, we can configure GitLab CI to verify whether our added content integrates with our existing codebase before deploying it. Tests verify intended behaviour, linters unify code style and static analysis tools monitor code quality. We can setup alex to check our writing as well:

stages:
  - check
  - deploy

check:
  stage: check
  image: node:8
  script:
    - npm install -g alex
    - alex content

pages:
  # ...

Both the task as the stage are called check. For clarity, we would want to change this if we add another check. This task is configured to run on every branch and, if applicable, before the deploy stage. A node docker image is booted, and alex is installed and run against the content directory.

If there is questionable language in my writing, alex shows the warnings in the build log and throws a non-zero exit code. This stops the build and halts deployment.

In conclusion

Inclusivity and the use of language is continuously a hot topic in society in general and software development in particular. Regardless of whether you think certain phrases are harmful or not, a tool like alex helps you identify potential issues with your writing you may have overlooked and invites you to think about their impact. You can then decide to change your wording or to actively ignore the warning.

Detect issues in your code editor, in Slack or before publishing articles. Adding alex to your continuous integration pipeline can prevent deployment of documents or posts containing inconsiderate writing.