Words Matter
“Words used carelessly, as if they did not matter in any serious way, often allowed otherwise well-guarded truths to seep through.”
― Douglas Adams
“But if thought corrupts language, language can also corrupt thought.”
― George Orwell
Bonus points for knowing the books these quotes come from.
I’ve been in the software industry for a long time. As those that work here know, and those that use software can see, it changes quickly. I feel like I’m releasing a new feature or fix every other day. It’s actually one of the amazing things about the software industry, and something that I genuinely love. But as fast as the industry moves there is one area that seems to be out of step with the world – the words and phrases we continue to use when developing and in documentation.
Some words of course don’t matter, but then there are the words that can evoke a gut wrenching feeling every time they are read or heard. Words like “master”, “slave”, “blacklist”, “dummy”, etc., may mean nothing to you beyond what they are used for in your industry, but to others they could be triggering thoughts and emotions that you might only sympathetically understand. While it’s easy to dismiss these words as “no big deal” because “the usage has no connection to the emotional triggers,” does that really matter? Isn’t it just better to err on the side of avoiding the possibility of triggering further negativity?
The idea of being mindful of the language we use when coding and communicating isn’t a new one. Companies like Apple, GitHub, The Linux Foundation, MasterCard, Salesforce, Air Canada and others have been leading the charge for quite some time now. The Drupal project was well ahead of the curve, replacing master/slave many, many years ago with primary/replica. GitHub has gone from master/slave to primary/secondary and from blacklist/whitelist to allow list/exclude list. Apple has included inclusive language guidelines within their style guides. There are many examples out there, but in a broad sense the idea and implementation has been slow in picking up speed. The company I work at has people from many different backgrounds, which is one of the things I love about it. At our small, growing company we have employees living in no fewer than three different countries and spread all across the U.S. Diversity has always been one of the incredible driving forces of innovation. I couldn’t be more happy to modify the words I use in my communications and documentation if it will pull us all closer together and encourage other underrepresented groups to join the industry.
Change is Good
“I have noticed even people who claim everything is predestined, and that we can do nothing to change it, look before they cross the road.”
― Stephen Hawking
As it’s often said, change can be difficult, but this is one of those instances where it’s not only easy but free, or very inexpensive, and where the benefits can be huge for minimal effort. Let’s start using alternative words in the place of those words we think may make others uncomfortable. Begin by using them in new code and documents and then update legacy words when and if it’s possible. Before you know it we’ll eliminate one more barrier for someone that wants to join the fun.
Here is a list of potentially sensitive words and possible alternatives:
| Sensitive Word | Possible Alternatives |
| Blacklist, Whitelist | Deny list, Allow list |
| Blackhat, Whitehat | Unethical, Ethical |
| Blackbox, Whitebox | Closed box, Open box |
| Whitespace | Empty space |
| Dummy | Fake |
| Man-month, Man-hour, Man-year | Person-month, hour, year |
| Master, Slave | Primary, Secondary |
| Sanity check | Test check |
| Grandfather | Legacy |
How Can BluBracket Help?
BluBracket covers a number of security concerns but we also identify sensitive words within repositories. Many of the words above are already built into the product, and for those that are not we have a custom regular expression feature that allows you to add your own. The BluBracket CLI tool can identify certain sensitive words in code before developers ever commit them. The tool also gives developers the ability to scan commits for tokens, keys, IDs, PII and even custom regular expressions pre-commit. The really great part is that the Community Edition and the CLI tool are 100% free. Go here to try it out. Once you’ve tried it out, we would love to hear your feedback on how we could make it even better – support@blubracket.com.
