Programming language bias

There are many characteristics you can use to define groups of developers, but the purpose of this post is to look at the biases we bring when defining developers by their chosen programming language.

My developer relations career has centered around APIs which has afforded me the opportunity to sling a bit of Java, PHP, Python, Ruby, .NET, NodeJS and Objective-C code. This isn’t a flex, I share this detail as I’ve lost the need to self identify as a “fill in the blank” developer. This wasn’t always true.

My journey as a programmer began with Allaire ColdFusion, the first database driven web content server. CFML (ColdFusion Markup Language) a tag based syntax that was approachable for those familiar with HTML and unlocked the ability to create dynamic web applications for many developers. I identified as a ColdFusion programmer for years and built friendships with others in the community. As other languages grew popular for web development, I observed divisions forming between developers based on the language they used. Conversations  between these developer groups at times lacked civility.

As I reflected on my personal journey, I wondered why do we attach our identity to programming languages? How does this influence our treatment of other developers? What  hidden biases impact developer relations work? These are the questions I want to explore.

Tribalism

As developers, we seek out others who share a passion for a shared technology.  We might connect in person or online wishing to learn from those with more experience.  Along the way we build connections that lead to identifying as a member of a developer community. We may attend conferences, join Slack groups.  As we grow, we find ways to help others new to our community. The developer community becomes our tribe.

The desire to find your tribe isn’t new. Thousands of years ago humans banded together with family members for companionship and survival. In modern society, we have the opportunity to choose who we spend time with and may belong to one or more tribes.

If our lives don’t depend on tribes, why do they still form? In the 1950s a psychologist coined the term homophily, which means “love of the same”. Humans are attracted to those who share similar opinions, beliefs and lifestyles. It is this “love of the same” that binds a group together. Developer communities have a shared interest in a technology and work together to push it forward. A key aspect of tribalism is loyalty. Once committed, we don’t easily abandon our tribe, which made a lot of sense in the past. You see this loyalty for technology expressed  on social media and other forums.

There is a lot of upside from the tribes we form. Think about the large scale open source projects developers use on a daily basis. These projects deliver amazing technology. Developers educate and support each other in communities. On an individual level we find friendship and connection with others.

Us versus Them

Communities develop ways to tell the world who they are and what they stand for. You see this in established developer communities who create statements of purpose. According to their website, “the Linux Foundation is dedicated to building sustainable ecosystems around open source projects to accelerate technology development and industry adoption”.

Along the way, developer communities may tell the world who they are NOT when defining themselves. A much smaller Apple expertly used this technique to differentiate their product from Microsoft in their I’m a Mac ad campaign.

The campaign was effective for selling Macs, but I disagree with pitting groups of developers against each other in an effort to win “hearts and minds”. It’s not a zero sum game and there is room for all types of developers. In the end, does the tool help you get the job done?  One example that stuck with me from over a decade ago was a series of videos parodying Apple’s popular “I’m a Mac” ad campaign. Ruby was the “the Mac” while other programming languages were Windows. Here is one that targets Java. Watching this video you might get a chuckle, but I share it as an anti-pattern we should not emulate.

Why does this tactic work? Our brains are wired to look for patterns. Subconsciously, we scan for signs that someone is with us or a stranger and a potential threat. Again, useful during hunter gatherer times, but has bad side effects in modern society. Adopting an “us versus them” stance may start with debating the merits of technology but can quickly devolve into ridiculing entire developer communities. It’s not fair to dismiss the work of thousands of passionate developers because they aren’t part of your tribe.

Age bias

Over time, biases may develop against different programming languages. Groups reinforce stereotypes by poking fun at X developers. I admit that I’ve gone for the cheap laugh in a meeting at the expense of an “uncool” technology. This behavior signals to others which developers we value and those to dismiss. This is the opposite of empathy which is fundamental to good developer relations.

As programming languages age, so does the associated developer community. Older programming languages may struggle to attract junior developers and over time will skew older as experienced developers continue to hone their skills. Python may be the only language on the left side of the chart that is attracting young developers in significant numbers today. I would attribute that to the rise of machine learning and python being the preferred language. Ignoring older programming languages may unintentionally result in  ageism towards a group of developers. A bias against developers using newer programming languages can also exist. Companies may categorize these new languages as too experimental or not mature enough.

Geographic bias

It occurred to me that geography might also play a role in which programming languages are valued by companies. I live near San Francisco and have watched the rise of many new technologies. The programming language(s) deemed worthy  by Bay Area companies may not reflect what developers in other countries are using daily.

I joined Xero a New Zealand based company and was informed that Microsoft and .NET are very popular in New Zealand and Australia. I was a bit surprised, but as I’ve helped hundreds of developers from that part of the world, there turned out to be quite a few .NET developers. To validate my experience with some data, I fired up Google trends to see the interest in C# across the globe. There was New Zealand at number 5.

Why does this matter? Where your company and engineering teams are based may bring a bias towards how you support developers.

Why should I care?

Thank you for sticking with me as I examine the human need to form tribes, the benefits of our affinity groups, the perils of adopting an “us vs them” world view and the ways bias can creep into how we view programming languages.

I believe we can work to be more inclusive. Especially, if you work in developer relations where empathy and advocacy are so important. We can improve ourselves, our companies and communities. Start with yourself by posing the question. Have ever belittle, ridiculed or dismissed a developer based on their programming language? When you hear Python, PHP, Clojure, Java, .NET, do you picture who those developers are and make any assumptions?

As developer advocates, we are in the room when decisions are made. How can you influence those around you? If you see support questions going unanswered based on the programming language, what can you do to help them get equal treatment. You might need to model the behavior initially so others learn from your example.

Most importantly, when you speak to a group of developers be open and inclusive. Try to vary the languages you use when showing code examples during talks. Avoid the temptation to get a cheap laugh at the expense of other developer communities. I know we can all do better.  At the end of the day, we all share a common desire to connect, grow and solve challenging problems through code.