Is your code creating a hostile work environment?

/

You run a serious, grown-up business, with an HR department and everything. If you find out that one of your employees is making rude, off-color comments in meetings, you're going to deal with that immediately. It's unacceptable behavior, it's not okay for that person to make your other employees uncomfortable in their place of work. It's your job to make sure they feel comfortable and safe enough to do their work1.

Likewise if that employee is making sexist remarks, or using racial slurs, or wearing t-shirts with sexually explicit images, or actively threatening co-workers with violence, or a whole host of other inappropriate behaviors. If you became aware of that, you'd do something about it. If you had a new hire starting this week, and one of their first encounters with their new coworkers was any of the above, you'd be mortified.

Now imagine that same employee opened up their code editor on the first day, started digging in looking for the cause of a bug, and during the course of reading the code they encountered all of the above.

Toby, the HR director from The Office, looking sad.

If you're a veteran programmer reading this, you might already be nodding your head. If you're not, let me explain.

How can code be offensive?

The main culprit is usually code comments. Comments allow programmers to annotate computer code with human-readable text. It might be a plain-language explanation of an algorithm, notes on how the code works, notes on other things that didn't work, possibly even diagrams.

But comments are also a place where programmers can express frustration, possibly in very colorful and inappropriate language. That frustration might even be directed at coworkers, and might include threats of violence (probably meant in jest). Or they can leave Easter eggs for other programmers to find, including jokes, stories, or pop culture references. Which, depending on the programmer, may not always be appropriate for all audiences.

Another area where programmers might get inappropriately creative is in variable naming. Aside from a few rules, most programming languages allow a lot of leeway in variable names, and the computer doesn't get offended if the coder uses a swear word as the placeholder for a database query result. File names in a project might also get this treatment. Really, any place where the name of something only matters to humans and not the machine, there's room for abuse.

Does this really happen?

Yep. It happens embarrassingly often in software development. (Be warned, some of those links are to Reddit discussions; exercise appropriate caution when reading them.) Sometimes it's the result of immaturity or a "tech bro" office culture. It may not even be a local problem - maybe you've acquired another company's code base, along with both its technical and cultural issues. Or it may be totally unintentional - developers might not realize that the language and terminology they're using is potentially offensive. Or it can be the result of language differences2.

Whatever the reason, your current team (and any new hires you hope to make) will be living in that code environment. If it's hostile, it might lead to good talent leaving. It might bleed into your non-code work environment. It might even lead to legal issues.

How do we prevent this?

If your code is purely internal, simply making sure you have a company policy about language use in source code may be enough - most programmers will avoid offensive language in source code if they know it's not acceptable. If your code is open source, and outside contributions are allowed, then a code of conduct is also a good place to specify that inappropriate and hostile language in source code is unacceptable. This is doubly important in open source, because anyone can see what is being written - the source code is now a very public representation of the company3.

I'm not a programmer, how do I determine whether this is happening?

Explain your concerns to your existing development team and ask them whether they see these sorts of problems (offensive/racists/sexist language, threats, or other inappropriate content) in the code. If it's code they work with regularly, it's likely they'll be able to tell you right away whether you have a problem.

If there are parts of the code that your team isn't familiar with (e.g., inherited or acquired codebases, legacy systems), an outside audit can surface these sorts of issues. Outside perspectives can also be useful for bolstering arguments with management4 about whether resources should be spent addressing a problem like this.

Conclusion

If you're a programmer, make sure your code and code comments are welcoming to your colleagues. If you're a manager of programmers, make sure that you've established expectations of reasonable and appropriate conduct in the code your programmers are writing. And if you're in upper management or HR, make sure that your company's software source code isn't a legal or talent retention liability.

  1. Or you just care about not being sued. That's better than nothing, I guess.↩

  2. I had a colleague once whose first language was Portuguese, and would sometimes mistype "tests" in code as the Portuguese word. It's only a one letter difference and an innocent mistake, but some folks might be offended.↩

  3. Some programmers seem to forget that front-end web code (the HTML and JavaScript used to make web pages interactive) can also be seen by anyone who selects "View Source" on the page. I've seen more than a few JavaScript comments that would warrant a visit to HR.↩

  4. Or your programming staff, if they seem to think this sort of thing is okay and doesn't need to be addressed.↩