Mr Walé’s Inclusion Fusion Vernacular Spectacular!
or Decoupling from (Bad) Shibboleths in the Developer Community
Link to Slides
A problem with developers is that we often say and do things that are esoteric and treat them as criteria for being a “developer.” This conflicts with the fact that a developer can come any background.
Today I’m going to talk about shibboleths. What’s a shibboleth? A shibboleth is a proverbial line in the sand that determines who belongs and who is an outsider. Many are in programming. Text editors, paradigms, languages, type systems, are all topics of… um…, “vigorous conversation.”
If you want to think about it in terms of middle school Venn Diagrams, the developer community does not do enough to encourage seeing different developer groups as unions instead of as intersections. This can have a lot of different manifestations. Say you're working on a project in Java and are coding at a makerspace. You tell someone else about your project, and they grit their teeth and say, "Could you try doing it in Ruby?" and grimace as if you had just spit in their face or something.
And even when people start to see the developer community as a union, there are still faux-pas that people make. To a newcomer, these situations set up too much of a danger of alienation, especially in terms of vernacular. If someone uses some tech terms that you don’t know, you can feel out of your depths. However, where words can be alienating, they can be helpful and illuminating as well.
Also, this is a field where someone can constantly learning how to do their job in new ways (and therefore where they are constantly a beginner at something or other). Yes, developing requires a certain set of skills, but not everyone arrives at learning them in the same way. As developers, we have an opportunity (and perhaps even a responsibility) to deemphasize aspects of code culture that help to maintain its status as an intimidating monoculture. And, guess what? In the long run, doing that makes us do our jobs better!
I’m African-American and West African. Let’s talk a bit about West African cultures and “joking relationships” and then bring it back to how programmer culture bears some resemblance.
In West African culture, people from different families or tribal groups sometimes have a common ancestry and have “joking relationships” between each other. These joking relationships mean that, when a person from one group encounters someone from another group, they exchange light verbal taunts with each other as a means of establishing a jocular familiarity. A good parallel to draw is the relationship that someone in the US Air Force has with someone in the US Navy. An airman may joke that they're "smarter" than a sailor while a sailor will joke that they're "tougher" than an airman.
In African-American culture, “joking relationships” find a corresponding custom in the form of “the Dozens,” also known as “snaps.” These are ribs made between friends for comic purposes. "Yo daddy so tall that he look like he's walkin' on stilts!"
Sometimes, exchanges about programming languages, syntax, paradigms, tooling, etc. can be like this. In this case, the code community looks like a set of unions with bold dotted lines. You like to code in Python and you’ve just met someone who likes to code in Javascript. You make jokes about callbacks while he makes jokes about how Javascript is everywhere so (Borg voice) resistance is futile. However, even with warm ribbing, there is a danger of alienation, especially to the uninitiated newcomer. If I’m new to coding and somebody makes fun of the programming language that I’m using, then I don’t feel as good about the language that I’m learning or about learning programming in general.
Also, joking is only fun for all parties involved if there is an inherent symmetry to the joking. Even if I’m an experienced coder, I’m likely to feel at best annoyed or at worst alienated if people are consistently making fun of the programming language that I use and I don’t have much of a retort. Remember that programming languages, paradigms, utilities, etc. are all tools that people deem best for achieving a task.
ALTERNATIVES/BEST PRACTICES
So, what can we do to move forward?
Ask yourself: Is this a proverbial hill on which I want to die? Usually it's not.
Ask yourself: With my argument in this conversation, am I treating things as more important than people? If yes, it's very likely that this is not an argument worth defending or the conversation is not one worth having.
Have a Code of Conduct. Even for a weekly meetup. Really. It doesn't have to be the Magna Carta or the Constitution, but have one. Of course, not all codes of conduct are good ones. A conference recently leaned on its code of conduct to rationalize why it is allowing a known racist to speak at it. Needless to say that that conference has lost the support of people of color and their allies.
A good code of conduct is clear, welcoming, and has internal buy-in.
-It clearly lays out what is allowed and what is prohibited
-It makes sure that people from underrepresented groups know that 1) the event will be welcoming to them because it is a safe space 2) in a proper manner, the event organizers will deal with any deviations from the event being a safe space
-Everyone organizing the group or event sees utility in the code of conduct and is ready to proceed according to its stipulations.
Gather in semicircles literally and figuratively I went to an event recently where many of the attendees were employees of a specific company. I was not an employee of that company. However, one of them was awesome enough to make sure that I felt included by making a space in the group for me to come in. He then called me over and introduced me to everyone else in the group. See, semicircles are great because they communicate that people from outside the current group can join. As members of the greater developer community, we need to communicate that people from all backgrounds and experience levels are welcome to join.
In that vein, give newcomers tools to adapt. At the end of this talk, I'm going to give you a link to an open source glossary of technical terms to which you can add via pull requests. The goal is to give newcomers early exposure to these terms so that the terms do not intimidate so easily. Link
Avoid joking relationship behaviors Especially when you first meet someone, you don't know their experiences and preferences about programming languages and tooling. Instead of assuming a false familiarity when you find out their preferences and proceeding to joke about said preferences, be ready to listen. Be ready to learn something from someone with a different perspective.
For that matter, even knowing someone for a significant amount of time does not give you license to make jokes about their technical background or preferences. There are better ways to relate to people with whom you work and/or socialize. Aim to compliment the good things that people do instead of deriding things that are a matter of taste. Being considerate, positive, and helpful are all more beneficial than being "funny."
Be helpful instead of indicating helpfulness Answer questions when you're fully engaged instead of flitting into other people's conversations with your answers. Make sure that people are actually asking you for questions. Floating from conversation to conversation like a butterfly with pedantic "well-actually" phrases does little to teach people. It does little but indicate that you like to prove how much you know.
Answer questions without condescension Don't act surprised when somebody doesn't know something and asks a question about it. Such a response can humiliate the person asking the question and is a disincentive to intellectual curiosity, which helps to drive success in programming, a field where, ideally, people are constantly learning.
Sources:
Sanankuya (Joking Relationship)
Contempt Culture
Negativity in Talks
Deconstructing "K&RC Is Dead"
Hacker News response to "K&RC Is Dead"
Things I Wish Someone Had Told Me When I Was Learning How to Code
The Recurse Center User's Manual - Environment
"Just"
Hi, this sounds like a great talk! The part about recommending different programming languages resonates with me. I've had times where I mention which language we are using for a project, and without asking what reasons we had for choosing that language, they just say, "Oh you should actually use X." They don't know any of the context, but they immediately assume they know what's best.
Sorry, rant over.