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.
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.
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.
Alex can help with this.
Alex can be integrated with several JS-based programs. There are integrations for Atom, Sublime and VSCode, but also for Slack and Ember.
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.
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
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.
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
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
A node docker image is booted, and
installed and run against the
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.
Inclusivity and the use of language
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
your continuous integration pipeline can
prevent deployment of documents or posts
containing inconsiderate writing.