Including People: Why It Matters

At Cloud City Development, we care a lot about people—treating them humanely, helping them accomplish their goals, and working together to make the field of tech and the world a better place.

“Diversity” has gotten a lot of press lately, both in tech in general and in the Ruby community in particular. It’s a really important topic we’ve been ignoring it for a long time. So, over the past few years, I’ve put a lot of time and energy into learning about the reasons that tech as a field is not diverse.

Wait, why is a white dude talking about inclusion?

Right off the bat, I’d like to point out that it’s kind of weird for me to be talking about anything related to diversity or inclusion—I’m cis, straight, white, and male. People assume that I know what I’m talking about (whether I do or not), and my personal experiences with the programming community have been largely positive. As a result, these two posts are the result of a lot of research and a lot of talking to excluded people about their experiences.

But the main reason why I’m writing, as a white male, is that I’m the only one who can without suffering backlash for it. As reported in the Harvard Business Review, marginalized or excluded people who bring up theses issues are penalized at work. Research showed that women and minorities lose social status and prestige, and even have their competence questioned, simply for working to address these very real problems.

Now that you know why me, let’s talk about this stuff. It’s really important, we’ve been ignoring it for a long time, and everyone needs to act thoughtfully and considerately for us to have any chance of improving things.

Let’s talk about “diversity.”

The topic of “diversity” has gotten a lot of press lately, both in tech in general and in the Ruby community in particular. The history of pervasive sexism and harassment in the Ruby community has even gone mainstream—it was the biggest fact about Ruby in a Bloomberg magazine article by Paul Ford called “What is Code?,” aimed at non-technical readers.

Over the last few years, I’ve put a lot of time and energy into learning about the reasons that tech as a field is not diverse. I’ve talked publicly about how to be an ally, and about why diversity matters. Let me start with a brief summary of the current situation.

How to start increasing inclusion in tech: s/diversity/inclusion/g — @rockbot

To start with, diversity is the wrong word to use while talking about these problems. The reason that underrepresented people are underrepresented is not because they don’t exist—graduating computer science majors include many women and many people of color, to name just two underrepresented groups.

“Diversity is being asked to sit at the table while inclusivity is being asked your opinion at the table you are sitting at.” — @taylor_atx

Even though these people absolutely exist, they are not included in tech. Their opinions are not listened to, their feedback is not acted on, and their technical skills are suspect based purely on their background.

The lack of diversity in tech is unsolvable as long as we remain exclusive. We need to become inclusive people, creating an inclusive community. In an inclusive community, there is no “diversity problem,” because everyone feels equally welcome.

I talk about this in conversations with a lot of people, and this is usually the point where someone tells me that they feel very welcome and included, so this can’t possibly be the reason for the lack of diversity in tech. That position is demonstrably wrong.

We have a bias & exclusion problem.

One underlying problem is people being denied education, jobs, and promotions solely because of bias. Coworkers, managers, executives, and VCs have all been shown to unreasonably overvalue work by young, white, straight men, while unreasonably undervaluing work by anyone else.

It might be because of gender, it might be sexual orientation, it might be disabilities, it might be age, or race, or weight, or any of a thousand other things. Just changing the name, gender, or race on a resume is enough to change a “good” resume to an “unacceptable” one.

There is a huge amount of repeated research showing these biases, especially against people with disabilities, LGBTQ people, and people of color. Even though there is a lot of repeatable research showing these biases, people disagree with me every time I talk about this. They say things like “but tech is a meritocracy and everyone is valued based on their contributions to the whole.” That is, unfortunately, not true at all. In fact, research shows that performance evaluations and hiring decisions are _even more_ biased when the company is supposedly a meritocracy.

Meritocracy is a lie told by rich white men.

People who are rewarded for their actions assume that their actions were deserving of that reward, and then conclude that anyone who didn’t get the same reward must have done lesser work. That is, unfortunately, not true at all. In fact, research even shows that performance evaluations and hiring decisions are more biased when the company is supposed to be a meritocracy.

With that out of the way, everyone tells me that (obviously) I should focus on the pipeline problem, getting more members of marginalized groups into tech. If new developers are diverse, then all of tech will become diverse eventually, right?

The pipeline leads straight to a sewage plant.

Nope. For example, when the first computers were built, all programmers were women. Today, programmers are less than 25% women. If the trend continues, no women will be programmers within a few decades. It’s not because we need more women in the field, it’s because the field is hostile to women and drives them away. That’s why we need inclusion—we had diversity already, but we fucked it up.

At this point, objectors usually pivot to another tactic. I can’t even count the number of times I’ve been told that including everyone is a good idea, but companies will only be willing to have diverse teams if it is financially beneficial. I’ve written about the economic argument for diversity before, but the short version is simple. Research shows that diverse teams produce better results in less time, but companies are so entrenched in their biases that they’re willing to ignore that so they can stay exclusive.

The economic argument is diversionary bullshit.

But the underlying problem is even worse: there is no excuse for treating a group of people as inferior, ever. Mercenary attempts to include underrepresented groups for the purpose of “improving productivity” are doomed to fail from the start. Companies motivated solely by profit will never be inclusive, because that requires valuing people as human beings rather than interchangeable cogs in a machine that creates value for investors.

Inclusion is an attitude, and a philosophy of interaction.

Because you’re still reading, I’m guessing that you’re interested in ways to be genuinely inclusive (especially in open source projects, with no profits to worry about). Being inclusive isn’t just a checklist of things for you to do: it’s an attitude to adopt in every social interaction. That attitude needs to not just be present, but supported and defended against the condescending, hostile attitudes that are all too common in software.

In the next post, I’ve tried to abstract my experiences into principles that can be applied to any project, team, or community, but I can’t be sure that they’ll work for everyone. Learn from my experience (and my mistakes), but don’t apply anything blindly. Keep your eyes open, form hypotheses, experiment, and evaluate the results. Figure out what your goals are, and keep experimenting and evaluating until you’re getting results.

This series of posts was originally given as a presentation at Ruby on Ales 2016, which can be watched on YouTube. Special thanks to @taylor_atx and @rockbot for permission to use their tweets, and @sailorhg for editing, vetting, and extensive feedback.

Andre, Cloud City Development Senior Developer, known for well-tested code that's maintainable over time, thinks every new feature is a chance to leave the codebase in better shape than it started. For over 12 years, he's built and run web applications and specializes in sharing knowledge via pairing. He's been the lead developer of Bundler, the Ruby dependency manager, for more than 5 years; co-authored the third edition of The Ruby Way, a book about how to use Ruby in an idiomatic way; and founded Ruby Together, the non-profit Ruby Trade association. No matter what software you need to build, chances are good that he'll be able to give you specific examples of the tradeoffs to keep in mind, and help your company choose the options that will make you the most successful.

Contact us for a complimentary 30 minute consultation.

get in touch