31 Aug 2016

Including People

This post was also given as a conference talk at Ruby on Ales 2016 and Ruby Remote Conf 2016. If you prefer, you can watch the video or see the slides.

This is about including people in projects, teams, and communities, but it would be more accurate to say “not excluding people”. Tech is a highly exclusive field, and we need to stop driving people away before we can make them feel welcome and included.

To be clear: I’m not an expert at this, but I have (sometimes painfully) learned many ways to exclude people. I’ll tell you about them, and then suggest ways to avoid them! That’s not enough to guarantee inclusiveness, but it’s at least a start. That said, I can’t be sure my suggestions will work for everyone. Keep your eyes open, form hypotheses, experiment, and evaluate the results.

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 experience with the programming community has been largely positive. As a result, these suggestions are the result of research, reading, and listening to excluded people about their experiences.

But the main reason why I’m writing, as a white male, is that anyone else would suffer backlash for it. As reported in the Harvard Business Review, underrepresented people who bring up theses issues are penalized at work. When women and minorities try to surface these issues, they lose social status and prestige, and their coworkers and managers question their competence.

Now that you know why I’m the one bringing this up, let’s talk about it. 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 research. I’ve also written about how to be an ally, and about why diversity matters. First, I’ll briefly summarize 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.

There is a huge amount of repeated research showing these biases, because of gender, disabilities, sexual orientation or status, race, age, 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.

Even though this is a thoroughly researched phenomenon, 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”. Well, about that…

meritocracy is a lie told by rich white men

Successful people often assume they caused their success, and then wrongly conclude that anyone less successful somehow deserved to fail. This is not only the fundamental attribution error, but holding this idea actively causes discrimination! At companies that claim to be a meritocracy, performance evaluations and hiring decisions are even more biased.

Once that’s out of the way, everyone tells me that I should “obviously” focus on the pipeline problem. If new developers are diverse, then all of tech will become diverse eventually, right? Again: nope.

the pipeline leads straight to a sewage plant

Let’s start with the most obvious counterpoint: when the first electronic computers were built, all programmers were women. The title “Computer” referred to a woman who performed calculations. The job of “Programmer” was created by those women as they wrote programs to automate their computational work. Despite starting at 100% women, programmers today are less than 25% women. If the trend continues, within a few decades no women at all will be programmers.

Young women already like computers and are interested in working with them. There isn’t anything wrong with the pipeline, but tech is so hostile that it drives even interested women away. This is 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 heard the comeback “including everyone is a good idea, but it would lower the bar”.

the bar is already on the floor

First, the very phrase “lowering the bar” is full of racist assumptions. Second, research into bias during job applications shows that white men have a huge advantage while experience and competence are dismissed in women or people of color.

Despite the research showing otherwise, big tech companies claim they value everyone equally. Their dismal diversity reports are explained away as part of the pipeline problem (which, as we just covered, doesn’t exist!) On top of that, employees confirm these companies continue to treat white men as inherently better, no matter what they say.

Hiring Manager: “We <3 diversity, but can’t lower the bar for our devs”
Me: “No, I was suggesting raising it. But, for your hiring managers”
— @josh_cheek

In America in general and in tech specifically, the bar for white dudes is already unbelievably low. The reality is the exact opposite of the claim: inclusion requires raising the bar—up above incompetent white men. At that point, more jobs can go to underrepresented competent people.

At this point, arguments for exclusion pivot to one more extremely popular claim: companies would love to be inclusive, but they can’t because it would be costly and hurt profits.

the economic argument is diversionary bullshit

I’ve written about the economic argument for diversity before, but the short response is “no, wrong again”. Research shows that diverse teams produce better results in less time. Diversity is measurably beneficial whether it is different expertise or merely different backgrounds or perspectives. Companies choose to uphold the exclusive status quo even when it means harming themselves.

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

Since you’re still here, 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.

people are why you are here

Software is made by people for use by people. Keep that in mind while you work on it! Projects usually involve three groups of people: end-users, potential contributors, and the existing team. It’s easy to be inclusive towards one of those groups while still being hostile to other groups. In the Linux kernel, for example, end-users are welcomed and documentation is provided for them. Contributors, on the other hand, are semi-regularly told that they are brainless imbeciles (or even worse language). Not so good on the welcoming, there.

include your users

So, let’s start with end-users. How can you be welcoming and inclusive of the people who use the software you work on? There are a lot of ways. People who are interested in using your software will pay attention to the other people working on it. They will pay attention to the other people using it. They will pay attention to whether your docs only ever say “he”. They will notice if reporting an error gets the response “that’s stupid”. So here are some straightforward ways to make sure that people using the code you write feel included.

codes of conduct

The most straightforward way to include people who are interested in your project is to establish a code of conduct, and then enforce it. At this point, there are a lot of examples of projects that have a code of conduct. Bundler is one, the Rust programming language is one. Coraline Ada Ehmke has even created a template called the Contributor Covenant that any project can use.

A code of conduct makes it clear that the project intends to provide a safe space for users and contributors that is free from harassment. Without one, anyone who experiences harassment on the internet will be much less likely to become involved in your project. That would be a tragedy, because most people who aren’t white caucasian males on the internet experience at least some harassment.

write great documentation

Next up, documentation. It’s a thing. You probably don’t have as much as you think you should, and chances are high you’re embarrassed about it. That’s okay. I work on a lot of projects, and none of them have perfect documentation. The ground rules for helpful, inclusive documentation for end-users are pretty straightforward: use “she” or “they” instead of “he”, and write some documentation that is aimed at newcomers to the project. Just that, and nothing else, is enough to get you off to a good start.

You can do better than that, though! For a fantastic explanation of how to write documentation that is genuinely helpful to users, check out the talk Writing Great Documentation by Jacob Kaplan-Moss. He outlines four kinds of documentation that your project needs to be useful to all the people who will look for it.

The first type of documentation is tutorials. Tutorials should explain how to accomplish a specific task. It should be possible to follow them start to finish in 30 minutes or less, and they should link to other tutorials or topic guides whenever they are relevant. Next up, topic guides. Topic guides explain a single topic in detail, mentioning the options, details, and unexpected bits that are specific to that topic. Topic guides should refer to other tutorials and topic guides as they’re relevant. Then there’s reference documentation. This is the API docs for your project. They are the most likely to already exist, but they are also completely useless for someone who doesn’t already know what they’re looking for. This is the reason that Rails has both extensive API docs and a guides project full of topic guides.

Finally, troubleshooting documentation. There will be problems that come up again and again—if you can, fix them in your code. If you can’t, add them to the troubleshooting guide. Write down the steps that you suggest to people having problems, and explain exactly what information you will need to be able to help someone who has a problem that they can’t fix on their own. As you write it, keep in mind that the person reading it will be frustrated at minimum and raging at worst. Keep it straightforward, don’t condescend, and try to be helpful.

Speaking of troubleshooting, how your project handles issue reports is a huge indicator of how inclusive your project is. If you respond to a new issue with “that doesn’t make sense” or “why were trying to do that”, the hostility implicit in those statements will be heard loud and clear. Start with the idea that whatever the reporter is trying to makes sense to them. Then, try to figure out what context they have that you don’t (or that you have that they don’t) that can help solve the issue.

give better answers

The talk Giving Better Answers, given by Sam Marshall at Alterconf Chicago in 2015, has really great concrete examples of how to give answers that are helpful without being condescending or hostile. Finally, always thank users for taking the time to report the error to you (they didn’t have to!). Always let them know than even if their problem isn’t a bug, you’ll try to help them, or at least suggest somewhere else that they can go to get more help.

Closely related to issue reports: IRC channels, Slack rooms, emails, and Twitter. Don’t just follow the code of conduct in all of those places, make sure that the code of conduct is being followed by others. Anyone that you have allowed to officially represent your project, whether core team or just a contributor, needs to understand that harassment and condescension is not okay. Listen and speak respectfully. Follow the code of conduct yourself, and call out anyone who doesn’t.

Finally, and this is true for every project: you have to enforce the code of conduct with everyone, whether user, contributor, core member, or yourself. If you have a code of conduct but let people slide, your project will become known as not just hostile, but hypocritically hostile.

include your occasional contributors

Now let’s talk about how to welcome contributors to your project. Everything that I’ve said so far about welcoming users applies to welcoming contributors, too. A safe environment without harassment is a requirement. Documentation helps a lot. Just having those things, though, isn’t enough. There’s more you can do to encourage contributions to your project.

First, and I can’t say this enough times, the biggest thing you can do to encourage contributions to your project is to ask for help. (Let me take this moment to say that I run the Bundler project, and we would love to have your help!) Most people think that they need to be total experts on something before they can even begin to help.

Let me make it extremely clear: I have never been an expert on any project that I have started to work on. I have also learned more by working on open source projects than any other way that I have learned anything about programming. When you ask for help, and when you write a document explaining how people can contribute, make it clear that they don’t need to be an expert to be able to help you. Schedule times to pair with contributors at any skill level, and then actually pair with them so they can get started.

Write development documentation. This is completely different from the documentation that targets end-users. It needs to explain how to set up the project locally for development and how to run the tests. It needs to explain who runs the project, what policies there are for contributions, and how to contact the other contributors on the project.

Don’t stop there, though. If there is anything you have to do repeatedly, like triaging issues, write a document that explains the steps. Write a list of every type of help you would like to receive. For Bundler, that includes fixing typos, writing docs, triaging tickets, refactoring code, fixing bugs, implementing features, and lots more. We have a dedicated document that not only lists each kind of help we would like to get, but links to guides for that specific type of help.

Treat pull requests the same way you treat issue reports: the person opening the pull request has context that means what they are doing makes sense to them. Even if there is no chance that you will ever accept the PR, thank them for making it (they didn’t have to contribute!). Explain your reasoning. Try to understand the underlying problem that drove them to send the PR, and see if there is a way you can help them even if you aren’t willing to accept the patch. Respect their intelligence and their time, and they’re likely to keep contributing.

include your team

It’s important to apply all of these principles to your entire team. Respond to code of conduct violations aimed at your team members. Make it clear that you have their back. Tell them that you appreciate their help. Apply the exact same principles that we just discussed for users and contributors: assume that what they are doing makes sense to them, and work to find the context that isn’t shared so that you can understand each other. Finally, give positive feedback and make requests. Collaborate with your team, discuss decisions, and listen to their input.

apologize. for real, though.

I screw up on a regular basis. Chances are also pretty good that you will screw this up at some point—we all make mistakes, and that’s okay! Being inclusive is an ongoing process, and part of that process is learning from mistakes. When you act in a way that excludes or alienates people, they might talk to you about it. Appreciate them for it! You’re being given a chance to learn and improve.

Most human beings respond with defensiveness when they hear they made a mistake. It’s really important to recognize that urge, acknowledge that it is normal, and completely suppress it. If you learn you screwed up, a defensive response is not okay, and not appropriate.

Keep in mind that the person you hurt is under no obligation to even inform you, let alone put up with a shitty response. Listen respectfully, then go process your feelings somewhere else. Apply ring theory, and keep your own problems aimed outward at people who are less impacted by the situation than you are.

Once you’ve managed to process your mistake, it’s time to apologize. Apologies absolutely cannot include conditionals like “if I offended you” or “those who might have been offended”. They cannot include any mention of intentions, like “we didn’t intend”. They cannot include any caveats, like “sorry, but”. Any apology with one of those elements is doubling down on your mistake and making the situation worse. Don’t do it.

Research from Ohio State University identified elements that make an apology most effective: Express your regret, identify the harms you caused, acknowledge your responsibility, apologize specifically for the harm you caused, ask if you can do anything to resolve the situation. If there is a thing you can do and you are able to, do that thing without arguing, bargaining, or complaining. For a more thorough explanation of this topic, go read On Making Mistakes by Julie Pagano for a detailed, step by step guide.

respect & empathy are all that matters

In the end, everything that I’ve suggested comes from the underlying principle of having respect and empathy for other people. Other people don’t have the context you do, and they don’t have the skills you do. Almost all of the time, they’re just trying to do their job. They can tell when you’re trying to help, and they’ll be very happy to receive that help. On the other hand, they can tell when you don’t like them and don’t care about them, and they will respond to that as well.

Treating others the way that you personally would like to be treated isn’t enough. Read about how to be a good ally. Listen to people in underrepresented groups. Pay attention to how tech as a field mistreats those underrepresented people, and actively work to fix it. Call out people violating codes of conduct. Let them know that what they’re doing isn’t okay. Tech as a field is biased and exclusive, and the only way it will get better is if all of us act together to change it.

improving inclusion

Let me finish by taking one of my own suggestions: I run a popular open source project, Bundler. We want to be more inclusive! The Bundler team has committed to offering pairing time to any developers who are willing to contribute.

I also want to improve this talk, and improve inclusion in tech. If you have ever thought about contributing to open source, but felt intimidated or excluded, please let me know about your experiences—I want to change things so that everyone will feel capable, welcome, and empowered to help make things better.

Special thanks to @juliepagano for On Making Mistakes and So You Want To Be An Ally, @taylor_atx and @rockbot for permission to use their tweets, and @sailorhg for editing, vetting, and extensive feedback.