API: All People are Important

For non-technical folks, API jargon can seem like another language. But for some API developers and consumers, that’s literally the case. English has, as it has in so many areas, become the de facto language of choice for programming and API development. That could pose real problems for non-native speaking developers, as could being the only female or minority member of a software development team.

In this post, we’ll be looking at some of the ways in which non-native speakers can tackle language barriers, as well as how the space as a whole is changing to foster the inclusion of women and minorities, and how this could reshape the API development space in years to come. As we’ll see below, negative culturally ingrained ideas can be dangerous when it comes to building a long-lasting product.

The Dominance of English in API Development

A 2016 infographic from Hubspot suggests that a random selection of 100 developers would break down in the following way:

• 25 in North America
• 30 in Europe
• 34 in Asia
• 5 in South America
• 4 in Africa
• 2 in Australia and Oceania

The first thing to note here is the majority of North Americans and those in Europe are brought up around English, even if they don’t speak it fluently. It’s also worth highlighting that many developers in Asia work on projects and products outsourced by Western companies, so they will typically have strong English language skills.

Roll all of those numbers together and we can see that as high as 89% (maybe even 91% if we add in Australian developers) of developers might be used to communicating in English, even though Asia makes up the single biggest share of developers.

In other words, it’s not all that surprising that English continues to be the dominant language in software development as a whole. So, when considering localizing efforts for API documentation, is catering developer portals to the regional tongue really all that necessary? Let’s dive into a case study to find out.

API Development For Non-Natives

In composing their API documentation, Yakov Karda of Chatra found it difficult to support English alongside their native tongue, yet the team has strived to make the developer portal relatable:

“Our docs are written and maintained directly by engineers. Since they felt a little unsure of their grasp of English, they mined pop culture for contextual examples that they knew were correct and would be understood by native [and non-native] speakers alike.”

Russian API designers at Chatra decided not to localize docs

Why not just write documentation in their native Russian?

“We actually started with full documentation in English and Russian, but got rid of the latter when we realized how difficult it is to make updates and maintain versions across two languages. Besides, as we have noticed, it’s just not necessary: most people who can use APIs (i.e. engineers) are proficient enough in English to get by without translation.”

Yakov also provides a specific example of how, sometimes, product localization can make things worse rather than better:

“The Russian version of Photoshop is totally incomprehensible because you can’t differentiate between cut, crop etc. in the Russian language, so users have no idea what a feature does when its name is localized.”

There’s no doubt that the demand for wider language accessibility is out there in the API space. At the end of 2011, the Google Translate API was shuttered due to what Google referred to as “extensive abuse,” but Microsoft Translator and IBM Watson’s Language Translator remain. As well as translating inputted text and detecting languages, they can do all sorts of cool stuff like detecting and translating text in uploaded images.

We also found it interesting that Language Translator has API functions baked right into its demo:

We already know that great APIs are all about playing together nicely with each other, and it’s tantalizing to think about plugging a translation API into a non-English API and converting the whole thing in real time. Consider, for example, how this could allow a non-English speaker to see all of the functions they need in their own language, build the app of their dreams using an API and then convert the whole thing back into English.

The Women In Tech Problem

The 2016 Hubspot data found that just 6% of developers surveyed identified as female. With more and more initiatives aimed at inclusion for women (Nordic APIs included!), you’d expect that number to have increased by now.

Although a The Next Web survey with a fairly small sample size found that the number of women in development has increased to more than 14%, a Stack Overflow survey of 100,000 developers suggested that it was still hovering around 6.9%.

Whether due to algorithms, in the case of Google Translate’s sexism or clumsy coding that paints women as “other” to the male default, it’s safe to assume most of these cases would have been addressed with more female developers in the mix.

Turkish is a gender neutral language. There is no “he” or “she” – everything is just “o”. But look what happens when Google translates to English. Thread: pic.twitter.com/mIWjP4E6xw

— Alex Shams (@seyyedreza) November 27, 2017

We’re thrilled to see that representation on conference panels continues to be a hot topic in the tech space. For example, the recent API City conference “emphasized women in tech; nearly every segment featured a female in at least one track, and the conference even had a luncheon for women and non-gender binaries as well as allies.”

When Diversity Makes A Difference

There’s no shortage of troubling cases regarding people of color (or the shortage thereof) in the tech world, and this can have serious implications in how software is produced. A Gizmodo article states that “researchers found that when various face recognition algorithms were tasked with identifying gender, they miscategorized dark-skinned women as men up to a 34.7 percent of the time. The maximum error rate for light-skinned males, on the other hand, was less than 1 percent.”

Brian Brackeen, “who jokingly identifies as ‘probably the only’ black CEO of a face recognition company”, highlights in the article how serious some of these problems can be. “If you have to log into your [bank] account twice because you’re African American, that’s unfair,” he says. “But, you’re not gonna get shot.”

Brackeen has penned an editorial for TechCrunch calling for face recognition companies to stop selling their tech to law enforcement agencies until the disparity between errors identifying black and white faces has been addressed, and it’s easy to see here how something a white CEO might regard as a bug or an inconvenience has another level of significance for black men.

One has to think that any solution he develops will be nuanced and thoroughly tested, rather than a quick and shoddy workaround…such as, say, Google blocking its image recognition algorithms from identifying gorillas because it kept mistaking black people for them.

Final Thoughts

Folks like Masayuki Igawa and István Zoltán Szabó have written at length about coding and creating content/documentation, but these pieces tend to focus on how non-native English speakers can improve their skills rather than ways in which an Anglocentric development space might better accommodate non-native speakers.

Unfortunately, it seems some API designers underestimate the surrounding context of language, gender, or race when building APIs (and coding generally). However, we’re glad to see that various efforts are being made to include women and minorities – non-native English speakers is a tricky one, since they don’t necessarily have a common language, though there have been conference talks on the subject – and we’re excited to say that these efforts continue to gather steam.

For example, IBM is developing tools aimed at identifying and eliminating bias and it’s becoming increasingly common for tech events to make inclusivity a priority. The recent API Strategy and Practice conference featured everything from a quiet room and communication stickers to designated non-binary restrooms and on-site childcare.

Many of us may not ever need or be able to take advantage of these measures, but that doesn’t mean that we should forget that there are people out there who do. Most of the problems we’ve outlined in this post don’t have any easy answers, but we continue to address diversity and inclusion in the space a priority as best as we can.