On October 24th, 2017 the ThoughtBot team renamed their popular Ruby testing library FactoryGirl to FactoryBot. They explained their reasoning:

Those who were bothered by the name shared a concern that female-gendered names (for software libraries and tools) in male-dominated spaces can be problematic. […] We concluded that, even though not everyone agreed, lack of concern from many shouldn’t prevent the name being changed. Being clever shouldn’t be favored at the expense of others feeling marginalized.

We’ll get back to that in a moment.

I had a little time after work the other day, so I followed their upgrade instructions for the Square Payroll code base. Our app’s front-end tests talk to the back-end Ruby test server so I had to convert those files too (just change *.rb to *.js and *.coffee in their grep/sed command). The entire process, from reading the instructions through submitting the pull request, took eight and a half minutes. Eighteen minutes and fourteen seconds later, our continuous integration system Kochiku marked it as green, and after a few minutes’ review, it was done.

I first encountered FactoryGirl when I started at Square in June. The name felt somewhat odd to me, odd enough that I looked up why the authors picked this name. I wasn’t alone in my quest: the project developers wrote this explanation in 2016 to clarify the name’s origins. I shrugged it off as being lost in translation and moved on. Then again, I’m a cis-het guy, and don’t really need to think much about these things.

It bothered other people. Github user *tastycode* submitted an issue asking about the name, saying they think about renaming it to simply ‘Factory’. After a brief back-and-forth, during which tastycode suggested the new name, the project leaders agreed that it should be changed, and a few months later ThoughtBot developer *Eraldius* renamed the library to FactoryBot.

User *maxkwallace* provided this anecdote to help people understand why the name was problematic:

I was going through some code with a female engineer, and noticing the name FactoryGirl led to an awkward exchange. […] Another guy in the vicinity made a joke about the [factory girl] “doing the work for you”. The woman I was working with didn’t explicitly say that she felt uncomfortable (people almost never do), but my subjective impression was that she felt uncomfortable. I also felt uncomfortable.

This episode speaks to the micro-aggression that women face all too often, sometimes daily: an insinuation that they are different, unusual, perhaps even unwelcome, and at the very least, guests in the man’s world of software engineering. Although individual instances may appear benign, they add up over a lifetime and, over time, marginalize women. This also happens with people of color, LGBTQ people, and, indeed, nearly any group that isn’t a “standard” straight, white male. Perhaps it even impacts these very same white males.

We’re all empowered to act as allies to confront and help address these micro-aggressions. When the stakes are low, correcting the behavior not only has a greater chance to promote growth, but also, chips away at the deeper roots that lead to bigger problems. The importance of stepping forward in support of positive change is made clear upon observing that an apparently minor change requiring less than ten minutes’ work became very controversial with many (mostly male) developers, as can be seen in the comments and emoji votes on tastycode’s issue.

That thread taught me several lessons when it comes to being a better ally for our marginalized friends:

1. Examine our resistance to change.

Most of us tend to resist change. If somebody is asking me to change, and I feel myself bristling at the perceived expense of it, I should examine what that change actually costs me, and the impact it has on the people requesting the change. If my upset is disproportional to the cost, chances are that my privilege is showing.

1. Resist apathy.

When a problem doesn’t affect us directly, we tend to pay less attention to it. When “we” are the local majority group, that means we pay less attention to minority groups’ issues, which only furthers marginalization. If I find myself thinking that an issue isn’t that important, but somebody is telling me that it is important to them, I should take the time to listen. I should encourage my peers to do the same.

1. Don’t take silence for consent.

When people feel comfortable, they are more likely to express their opinions. Conversely when people feel marginalized, they are less likely to speak up when an issue seems contentious. I should not assume that somebody’s silence means they have no thoughts on the matter, or agree that the question isn’t important. I should not let the loudest voices in the room drive the decision, and should solicit other views, either immediately or in a separate conversation.

1. Don’t confuse feelings from a place of privilege with “logic”.

When the world looks a certain way to us, it’s easy to assume that that’s because our world-view is in fact the logical, rational one. This is a form of intellectual arrogance that not only contributes to further marginalization, but also, closes us off from broadening our understanding of our fellow humans. If I don’t understand why an issue is important, I should not assume it’s because the other person is irrational or illogical; I should always be open to questioning my assumptions.

In this author’s humble opinion, the above are conducive to better human interactions in general.

"Being clever shouldn’t be favored at the expense of others feeling marginalized."

Building a diverse and inclusive environment is important: first, because there is intrinsic value in treating all humans equally, and second, because it fosters stronger, more sustainable businesses and communities. Please join me in working together toward this goal, and share your thoughts in the comments!