Code Review with an Eye for Equity

Coding is like any other science – we improve on what came before, and we stand on the shoulders of giants who have paved the way. 

And coding is like life: things get stale and old if you don’t keep learning, keep moving, keep improving. If framed in a certain context, though, can code be harmful? 

A little over two years ago we initiated a project that aimed to address that central question. We sought to update the use of terminology in our coding infrastructure, to see if we could shift our language to one that relies less on outdated, offensive terms, and more on inclusive, up-to-date language. This took the form of replacing several commonly used terms in our architecture, including master; slave and whitelist; blacklist. 

Why am I writing about this now, though, if the initiative has been underway for two years?  

Organizational acceptance of an effort of this magnitude is easy to approve… in principle. We live in a divided world. Taking steps to ensure that the terminology we’re using doesn’t isolate or harm its readers can only better support diverse teams, build more inclusive workspaces, and encourage a more innovative environment to code in. 

A project of this scope, touching every aspect of our work, takes time. While this initiative isn’t as newsy as it once was, the work to make these changes happen can stretch far into the future, and even longer to render it an ingrained part of a company’s culture. And change that facilitates inclusion has a deeper – if not quite as newsworthy – impact when it happens out of the spotlight, when it’s up to the passion and persistence of a workplace community to drive the change. 

The initial push for this change resulted in hundreds of reports like the one above for project owners to implement. Anyone working in tech understands that adding changes to a project’s backlog is part of the project’s future. We’ve made a lot of changes, but there are lots more to be made, and lots more to be identified in the future. 

Addressing this desire to the tech industry’s use of language doesn’t have an easy answer and requires ongoing commitment to change, as any culture shift does. We’re far from the first organization – and hopefully far from the last – to engage in this kind of introspective and inclusive code conversion. Gitlab, which houses the vast majority of our code base, announced in 2020 that by default top-level branches would be renamed from ‘master’ to ‘main.’ And programmers with traditionally marginalized backgrounds celebrate, as in this 2020 article from Wired, steps toward workspaces designed with their inclusion in mind. 

The tech industry’s work at large is ongoing. One year ago, Intel and a number of other large tech firms announced their participation in the Alliance for Global Inclusion, an effort to drive commitment to shared diversity and inclusion metrics. In January of this year, Google released new guidelines for the inclusive use of language in software and software documentation, and in February, Microsoft provided resources to drive bias-free communication. 

From a practical commitment perspective, we’re currently operating thousands of projects across our enterprise, and an approach that proactively alters language can be both presumptuous (in cases where terms are used legitimately) and detrimental (in cases where terminology change could break code). 

An example of our in-house Inclusive Naming Report, complete with flagged instances of the target terminology and instructions for what to do next. 

Several dedicated folks within our Engineering teams developed an in-house tool to flag the terms listed below that we identified as potentially harmful – whitelist, blacklist, master, and slave – and encourage the Gitlab project owner to add these terminology changes to the project backlog, to address when the time was right. 

At the end of the day, this language change process is tricky. It runs the risk of being seen as performative – even Gitlab faced pushback for its 2020 changes. As individual champions of change within Climate, and as an organization focused on an inclusive culture, we need to ask ourselves what this sort of effort represents for us.  

Tech and agriculture are about the constant aspiration to do better for yourself, build better for your community, and improve the world bit by bit. Ultimately, the investment is worth it. We’ll keep doing the most we can to create an inclusive space for tech workers and for agriculture, and keep on yielding change by working through our backlog.