![\"\"](\"https:\/\/www.backblaze.com\/blog\/wp-content\/uploads\/2020\/11\/bb-bh-Code-and-Culture-What-Happens-When-Tthey-Clash.jpg\")
<\/p>\n<\/p>\n
Every industry uses its own terminology. Originally, most jargon emerges out of the culture the industry was founded in, but then evolves over time as culture and technology change and grow. This is certainly true in the software industry. From its inception, tech has adopted terms\u2014like hash, cloud, bug, ether, etc.\u2014regardless of their original meanings and used them to describe processes, hardware issues, and even relationships between data architectures. Oftentimes, the cultural associations these terms carry with them are quickly forgotten, but sometimes they remain problematically attached.<\/p>\n
In the software industry, the terms \u201cmaster\u201d and \u201cslave\u201d have been commonly used as a pair to identify a primary database (the \u201cmaster\u201d) where changes are written, and a replica (the \u201cslave\u201d) that serves as a duplicate to which the changes are propagated. The industry also commonly uses other terms, such as \u201cblacklist\u201d and whitelist,\u201d whose definitions reflect or at least suggest identity-based categorizations, like the social concept of race.<\/p>\n
Recently, the Backblaze Engineering team discussed some examples of language in the Backblaze code that carried negative cultural biases that the team, and the broader company, definitely didn\u2019t endorse. Their conversation centered around the idea of changing the terms used to describe branches in our repositories, and we thought it would be interesting for the developers in our audience to hear about that discussion, and the work that came out of it.<\/p>\n
The Backblaze Engineering team strives to cultivate a collaborative environment, an effort which is reflected in the structure of their weekly team meetings. After announcements, any member of the team is welcome to bring up any topics they want to discuss. As a result, these meetings work as a kind of forum where team members encourage each other to share their thoughts, especially about anything they might want to change related to internal processes or more generally about current events that may be affecting their thinking about their work.<\/p>\n
Earlier this year, the team discussed the events that lead to protests in many U.S. cities as well as to new prominence for the Black Lives Matter movement. The conversation brought up a topic that had been discussed briefly before these events, but now had renewed relevance: mindfulness around terms used as a software industry standard that could reflect biases against certain people’s identities.<\/p>\n
These conversations among the team did not start with the intention to create specific procedures, but focused on emphasizing awareness of words used within the greater software industry and what they might mean to different members of the community. Eventually, however, the team\u2019s thinking progressed to include different words and concepts the Backblaze Engineering team resolved to adopt moving forward.<\/p>\n
![\"working](\"https:\/\/www.backblaze.com\/blog\/wp-content\/uploads\/2020\/04\/bb-bh-How-BB-Does-Software-Eng-Interviews-1024x583.jpg\")
<\/p>\n
The words \u201cmaster\u201d and \u201cslave\u201d have long held harmful connotations, and have been used to distance people from each other and to exclude groups of people from access to different areas of society and community. Their accepted use today as synonyms for database dependencies could be seen as an example of systemic racism: racist concepts, words, or practices embedded as \u201cnormal\u201d uses within a society or an organization.<\/p>\n
The engineers discussed whether the use of \u201cmaster\u201d and \u201cslave\u201d terminologies reflected an unconscious practice on the team\u2019s part that could be seen as supporting systemic racism. Although the term, “slave,” hasn’t been used in the repositories, in this case, the use of “master” prompted the question that forced them to acknowledge that their usage of one of the terms could be perceived as an endorsement of the pairing’s historic meanings. Whether intentionally or not, this is something the engineers did not want to do.<\/p>\n
The team decided that, beyond being the right thing to do, revising the use of the term, “master,” would allow them to reinforce Backblaze\u2019s reputation as an inclusive place to work. Just as they didn\u2019t want to reiterate any historically harmful ideas, they also didn\u2019t want to keep using terms that someone on the team might feel uncomfortable using, or accidentally make potential new hires feel unwelcome on the team. Everything seemed to point them back to a core part of Backblaze\u2019s values: the idea that we \u201crefuse to take history or habit to mean something is \u2018right.\u2019\u201d Oftentimes this means challenging stale approaches to engineering issues, but here it meant accepting terminology that is potentially harmful just because it\u2019s \u201cwhat everyone does.\u201d<\/p>\n
Overall, it was one of those choices that made more sense the longer they looked at it. Not only was the use of \u201cmaster\u201d problematic, it were also harder and less logical to use. The very effort to replace the word revealed that the dependency it described in the context of data architectures could be more accurately characterized using more neutral terms and shorter<\/em> terms.<\/p>\n The Engineering team discussed a proposal to update the terms at a team meeting. In unanimous agreement, the term \u201cmain\u201d was selected to replace \u201cmaster\u201d because it is a more descriptive title, it requires fewer keystrokes to type, and since it starts with the same letter as \u201cmaster,\u201d it would be easier to remember after the change. The terms \u201cwhitelist\u201d and \u201cblacklist\u201d are also commonly used terms in tech, but the team decided to opt for \u201callowlist\u201d and \u201cdenylist\u201d because they\u2019re more accurate and don\u2019t associate color with value.<\/p>\n The practical procedure of changing the names of branches was fairly straightforward: Engineers wrote scripts that automated the process of replacing the terms. The main challenge that the Engineering team experienced was in coordinating the work alongside team members\u2019 other responsibilities. Short of stopping all other projects to focus on renaming the branches, the engineers had to look for a way to work within the constraints of Gitea, the constraints of the technical process of renaming, and also avoid causing any interruptions or inconveniences for the developers.<\/p>\n First, the engineers prepared each repository for renaming by verifying that each one didn\u2019t contain any files that referenced \u201cmaster\u201d or by updating files that referenced the \u201cmaster\u201d branch. For example, one script was going to be used for a repository that would update multiple branches at the same time. These changes were merged to a special branch called \u201cmaster-to-main\u201d instead of the \u201cmaster\u201d branch itself. That way, when that repository\u2019s \u201cmaster\u201d branch was renamed, the \u201cmaster-to-main\u201d branch was merged into \u201cmain\u201d as a final step. Since Backblaze has a lot of repositories, and some take longer than others to complete the change, people divided the jobs to help spread out the work.<\/p>\n While the actual procedure did not come with many challenges, writing the scripts required thoughtfulness about each database. For example, in the process of merging changes to the updated \u201cmain\u201d branch in Git, it was important to be sure that any open pull requests, where the engineers review and approve changes to the code, were saved. Otherwise, developers would have to recreate them, and could lose history of their work, changes, and other important comments from projects unrelated to the renaming effort. While writing the script to automate the name change, engineers were careful to preserve any existing or new pull requests that might have been created at the same time.<\/p>\n Once they finished prepping the repositories, the team agreed on a period of downtime\u2014evenings after work\u2014to go through each repository and rename its \u201cmaster\u201d branch using the script they had previously written. Afterwards, each person had to run another short script to pick up the change and remove dangling references to the \u201cmaster\u201d branch.<\/p>\n Managers also encouraged members of the Engineering team to set aside some time throughout the week to prep the repositories and finish the naming changes. Team members also divided and shared the work, and helped each other by pointing out any areas of additional consideration.<\/p>\n In September, the Engineering team completed renaming the source control branch from \u201cmaster\u201d to \u201cmain.\u201d It was truly a team effort that required unanimous support and time outside of regular work responsibilities to complete the change. Members of the Engineering team reflected that the project highlighted the value of having a diverse team where each person brings a different perspective to solving problems and new ideas.<\/p>\n Earlier this year, some of the people on the Engineering team also became members of the employee-led Diversity, Equity, and Inclusion Committee. Along with Engineering, other teams are having open discussions about diversity and how to keep cultivating inclusionary practices throughout the organization. The full team at Backblaze understands that these changes might be small in the grand scheme of things, but we\u2019re hopeful our intentional approach to those issues we can<\/em> address will encourage other business and individuals to look into what\u2019s possible for them.<\/p>\n","protected":false},"excerpt":{"rendered":" In this post, we\u2019re sharing about the Backblaze Engineering team’s conversation regarding the idea of changing the terms used to describe branches in our repositories, and the effort that resulted from that discussion.<\/p>\n","protected":false},"author":150,"featured_media":96887,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[7],"tags":[468],"class_list":["post-96873","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud-storage","tag-b2cloud","entry"],"acf":[],"yoast_head":"\nRolling Out the Changes and Challenges in the Process<\/h2>\n
![\"\"](\"https:\/\/www.backblaze.com\/blog\/wp-content\/uploads\/2020\/11\/Code-and-Culture-banner.jpg\")
<\/p>\nMoving Forward: Open Communication and Collaboration<\/h2>\n