It’s easy to become enveloped in “paradigm-shifting” technical dogma, to the point that API providers overlook personal qualities of the developers that consumer APIs and the end consumers affected by their implementations.

Thankfully, there is an “out”, so to speak, for this kind of behavior. Surveys, especially when conducted on a broad criteria of participants, are perhaps some of the strongest avenues for understanding modern developers, offering hidden insights that when contextualized can drive technical approaches for years to come.

This piece is going to do exactly that — provide some context to one of the largest, broadest survey of the web development industry, the Stack Overflow 2017 Developer Survey. While the complete results can be found here, we’ve mined some interesting data points below, and helped to translate what they actually mean for the API industry.

Contextualizing the Stack Overflow 2017 Developer Survey

Before we begin, the survey itself should be properly contextualized. This isn’t a simple, small, informal survey — the Stack Overflow 2017 Developer Survey was gigantic, garnering information from over 64,000 respondents around the globe.

The origination isn’t some small social media group, either — Stack Overflow represents one of the most comprehensive and responsive communities in the tech industry. By their own data, “every 8 seconds or so, a developer asks a question on Stack Overflow”. While these questions might garner only a handful of responses, these millions of questions per year have formed a long-lasting, highly dense and useful system of questions and answers all directly relevant to the industry in question.

Plainly said, this survey is hugely important — and the data should thus be considered just as important and storied.

Raw Pertinent Data

Let’s take a look at some basic data points that have informed this piece.

Popular Languages and Technologies

In regards to popular languages and technologies, the survey had some very interesting data points. Regardless of whether the respondent was a full-stack, front-end, or backend developer, there were some consistent responses — namely that JavaScript is generally speaking the most overwhelmingly popular technology (62.5%), with SQL a close second (51.2%). This makes sense of course, given that many application backends utilize this technology so fervently.

This year was also the first year in which developers were asked what database technology they utilize. The answers are interesting, if not somewhat expected. MySQL is a common technology (55.6%), with SQL Server (38.6%), SQLite (26.6%), and PostgreSQL (26.5%) leading from behind.

There are some generally stable trends as well. In 2013, JavaScript as a total technology preference was 56.6%. In 2014, this was 58.9%, in 2015 54.4%, and in 2016, 55.4%. In 2017, it accounted for 62.5% of respondents. While in theory this shows a generally strong and constant adoption, the numbers are somewhat misleading, as response has increased dramatically year over year, suggesting a stable trend that is still influenced somewhat by increasing backend developer response rate.

The Rise of Modern Solutions

Interestingly enough, PHP, though still quite strong, seems to be falling out of favor in light of more modern solutions. The survey specifically tackles this subject in the “Most Loved, Dreaded, and Wanted Languages” section of its results. The top five loved languages are Rust (73.1%), Smalltalk (67.0%), TypeScript (64.1%), Swift (63.9%), and Go (63.3%), among relatively new languages compared to the other solutions on offer – this data is even more stark when one considers the marked absence of many enterprise, proven solutions.

This trend towards modern approaches is likewise present in the most loved platforms, where users were asked what they’d like to work in but have yet to work in. Android tops the list, signaling a rise towards open source more so than closed ecosystems, but Node.js, AngularJS, Python, and JavaScript also top this list.

That being said, the traditional enterprise languages and approaches are just as omnipresent as ever. When the most popular languages by occupation were collated, JavaScript pulled out well ahead of the pack, boasting 81.7% of day to day use. SQL was close behind at 60.4%, C# at 38.1%, Java at 37.9%, and PHP at 33.8%. This signals that, regardless of the wanted languages or the love for modern applications, many enterprise solutions still require the older languages and approaches, thereby making them a mainstay – at least for the time being.

Remote and Classical Workers

Of note is the definite trend of non-office workers, specifically workers who do at least some part of their work remotely. According to the respondents, 11.1% of developers call themselves full-time remote workers, 17.7% consider themselves as part-time remote in some capacity, 35.1% state that they work remote “a few days a month,” and 31.8% state that they “never” work remotely.

While it seems the lion’s share of workers never or rarely work remotely, the data actually suggests that upwards of 70% work remotely at some point.

The Takeaways

Now that we have the raw data, what does any of this actually mean? While a lot of what can be inferred from this data is just that — inference — the data rather strongly correlates with the following conjectures.

Older vs. Newer Tech

While the data shows that older stable technologies like PHP and its myriad of frameworks, as well as web technologies like HTML, are going strong in their respective fields, modern technology is definitely rising in favor, and are absolutely poised to replace these aging systems.

Interestingly, these new technologies are more beloved than the traditional ones. The “beloved” section of the survey is topped by new languages like Rust and Swift, whereas older technologies and languages lag behind. This isn’t to say those languages aren’t useful — just that, despite their obvious utility, they don’t seem to invoke the actual same level of excitement as newer solutions.

What this fundamentally means is that the new solutions are more attractive to developers because of what they offer. Traditional solutions are great, and as powerful as they are, they will still be significant in presence.

These new solutions, however, offer very complex solutions to what will inevitably be very complex problems. What might take a lot of hackery to do in standard languages and approaches can be simply done with purpose-built languages and their applications, which will ensure these languages keep climbing both in devotion and use.

Library Support

In terms of what this means for providers, the data suggests a definite trend away from the unified traditional approach of the big languages and into a greater array of choices. Some of these choices are compatible, and others are not, but generally speaking each language occupies a specific industry, a specific use case, and a specific purpose.

Accordingly, we can garner a lot of insight as to practices and library support by looking at the surging popularity and usage of new languages. You should continue to expect older solutions and languages, but as time passes, these will be less prevalent, and will lose market share year-over-year.

Accordingly, library support should have a greater, broader base of support. For example, API providers should consider providing not only their traditional documentation, but additional documentation in a myriad of forms, as well as interactive tutorials, on languages like Go. Having code tutorials in these additional languages is a very simple thing to include, but provides a wider support base for current and potential users.

To be clear, supporting these traditional, older solutions is very important — that being said, supporting modern languages and solutions is just as important, and can have some serious implications as to your uptake, retention, and market share. Any provider worth their salt needs to support a wide range of solutions — not doing so, and only supporting the classic libraries, is very much a death knell; if not immediately, then in the long run.

The Developer Profile is Different

Perhaps the most interesting set of data points here for API marketing concern the developer profiles. The developer is very, very different from years past. The primary point of interest here in the nature of remote work.

According to the aforementioned data, the lion’s share of developers work remote at some point, which is a far cry from the office cubicle worker of yesteryear. This has serious implications in terms of the resources these workers demand. Providers can no longer rely on the nature of the enterprise solution to handle workers.

In previous years, enterprises solved many issues. Documentation was generally handled as part of the business transaction of implementing a solution, and what wasn’t documented was provided as a contract service to an enterprise at a given price.

This isn’t really the way things work now, though — with so many remote workers, the “enterprise solves everything” approach is no longer applicable. You need effective, complete, useful documentation, otherwise you’re going to have remote developers give up on your solution because there’s nothing they can use.

Demographically, it should also be noted that there’s a pretty stable split geographically and numerically speaking between European, North American, and other developers — it seems that the distribution is rather even across geographic and cultural boundaries. Accordingly, your solution needs to have intrinsic support for the legal implications of applications across all spaces. Stable encryption support, a methodology for custody tracking, etc. is super important, especially if your solution supports data destruction, transfer of data, or any sort of data collection, as there’s a lot of legal issues inherent in these processes.

This also has implications for marketing. Not everyone is an enterprise — in fact, the data suggests that the most lovable technologies, such as Go and Android, are those with strong open-source communities. In fact, those loved languages have in some cases drastically displaced more traditional enterprise solutions.

Simply put, the enterprise is not as large in terms of market share and influence as it once was — but the majority of marketing is diverted to that space because of the high economic payoff. As that space diminishes as non-enterprise developers and startups become a larger portion of developers, you need to make sure you’re providing not only large, complex solutions for an enterprise, but also scalable, low cost solutions for smaller use cases.

Conclusion

It’s been said, but it bears reiteration — metrics and data are incredibly important. Being able to understand and classify your developer consumer will help in making your service more appealing.

Being able to identify new usage, adoption, and retention trends based on these kinds of surveys helps to inform both the health of the industry in general and the health of leading solutions. The takeaways here are numerous:

• Language support: Providers should support international standards and technologies, as the data suggests even representation across cultural and geographic areas;
• Be forward-thinking: Modern languages are slowly supplanting traditional and enterprise solutions — having even basic support for these newer elements would leverage this movement for API success;
• Open up: The movement towards open-source is not slowing down, and if anything is growing by leaps and bounds — supporting this as an early adopter may be vital for business.
• Scalability: As the distributed workforce grows, business must offer low-cost, scalable solutions for small dev teams alongside their enterprise solutions.

While none of these data points are groundbreaking shockers — for instance, in 2018 SQL will likely place within five percentage points of this year’s datasets, which is hardly an abandonment — the trends validate some of what we’ve been discussing on the blog, and what industry experts have forecasted.

It is important to remember, however, that these trends are not set in stone, and chasing the language of the week can be just as dangerous as ignoring it outright. This data should inform industry approaches, not define them, and accordingly, it is just as important to have stable support for storied, traditional solutions, as it is to support new ones.