If you want a diverse community, you have to stand up for marginalized members

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.

Inclusion is a necessary part of good coding

Too often I see comments like “some people would rather focus on inclusion than write good code.” Not only is that a false dichotomy, but it completely misrepresents the relationship between the two. Inclusion doesn’t come at the cost of good code, it’s a necessary part of good code.

We don’t write code for the sake of writing code. We write code for people to use it in some way. This means that the code needs to work for the people. In order to do that, the people designing and implementing the technology need to consider different experiences. The best way to do that is to have people with different experiences be on the team. As my 7th grade algebra teacher was fond of reminding us: garbage in, garbage out.

But it’s not like the tech industry has a history of bad decision making. Or soap dispensers not working with dark-skinned people. Or identifying black people as gorillas. Or voice recognition not responding to female voices. What could go wrong with automatically labeling “suspicious” people?

I’ll grant that not all of these issues are with the code itself. In fact a lot of it isn’t the code, it’s the inputs given to the code. So when I talk about “good coding” here, I’m being very loose with the wording as a shorthand for the technology we produce in general. The point holds because the code doesn’t exist in a vacuum.

It’s not just about the outputs and real world effect of what we make. There’s also the matter of wanting to build the best team. Inclusion opens you up to a broader base of talent that might self-select out.

Being inclusive takes effort. It sometimes requires self-examination and facing unpleasant truths. But it makes you a better person and if you don’t care about that, it makes your technology better, too.