From the DevMonitor: What Do Stack Overflow’s Survey Results Say To Dev Programs?

This post is from the WIP Factory Newsletter, which brings subscribers a monthly email of insight, analysis and news into the world of developer marketing and developer relations. To get more articles like this in your inbox every month, sign up for free now.

Stack Overflow’s massive popularity with developers puts it in a good position to assess developer trends and sentiments, so its annual developer survey results are worth a look. Its most recent results were released in March, and as usual, provide some interesting insights for developer program providers into how developers are working, and how their needs can best be met.

So, how many developers are there, anyway?

We’re frequently asked to quantify the number of developers in the world (often to facilitate an “Even if we only capture 1% of them…” thought), and it’s not an easy question to answer accurately. We have seen estimates from analyst firms as low as 18 million, up to a carefully calculated 43 million from a European software company.

Stack Overflow’s figures provide another take on the number, albeit indirectly. The site had 46 million visitors in January 2016, and it estimates 16 million of those were professional developers. WIP’s own research has found that half of developers say they visit Stack Overflow at least weekly; by extension we can estimate based on SO traffic there are 32 million+ developers. A rough estimate admittedly, but one that falls in line with the 30-40 million developers figure we feel comfortable with.

Who do you think you are?

Nearly 30 percent of respondents to the SO survey self-identified as “Full-Stack Web Developers,” compared to 12 percent who say they are backend only and 6 percent who say they’re frontend only. This gives a bit of insight into the bulk of the SO community – focused around web development – but also how technology is changing developer roles.

The survey results show that JavaScript is the most popular technology among respondents, even when separating out results for backend developers alone. When separate results for frameworks like Angular, Node.js, and React are added in, it is clear that JavaScript is hugely important both on the front and backend of modern web applications.

The results also note that just about 8% of developers consider themselves “mobile developers”, whether that’s mobile in general or specific to a single platform. Again, this is likely a result of changing technology and context, as mobile has become so pervasive among developers that it’s simply seen as part of modern development rather than a completely distinct domain in its own right. 

Breaking those mobile figures down, 3% of respondents said they were Android developers; 2.5 percent said they were iOS developers, while just 0.1% called themselves Windows Phone mobile developers (more on Windows Phone’s struggles below). 

We see this as well in our DevMonitor tool, where in terms of both Developer Interest on Stack Overflow and New Project Creation on GitHub, Windows Phone barely registers compared to Android and iOS.

Talking tech 

One of the more interesting areas of the survey covers the technologies developers are using, the tech they love, and the tech they hate. As mentioned earlier, JavaScript leads the way among the most popular technologies, followed by SQL/SQL server, Java, and C#. But keep in mind that “popular” here means most frequently used – there are separate figures for the most loved technologies, where a number of lesser-used tech lead the way: Rust, Swift, F#, Scala, and Go. There is also not much overlap among the technologies that are gaining in popularity on SO, led by React, Spark, Swift, Cassandra, and Raspberry Pi.

There are a few important takeaways here for developer programs:

 

  • Are you providing tools and resources that support the technologies and languages your developers are using? Keep in mind the SO survey is general and reaches across a large population of developers, and that your targeted groups may have some different needs and preferences.
  • Are you providing tools and resources in the technologies and languages that developers want to use? Both technology and developer preferences are constantly changing, and it’s important you understand how they are evolving in your own community, so you can provide the right sets of tools.

More bad news here for Windows Phone: it had the biggest drop among technologies represented on Stack Overflow, off 65% from last year. This echoes what we see in GitHub project starts from the DevMonitor, where the level of new Windows Phone projects has been steadily falling over the past year.

Developer priorities and challenges: How are you helping?

There are some really interesting data points from the questions the survey asked developers around their priorities and challenges, which some significant implications for developer programs. Answers to these questions cover issues developers face within their work environments, but also technical issues and developer motivations.

Just over 70% of developers said a priority was learning new technologies, with 64% saying building something new was important to them. We know developers like to kick the tires of new things and are constantly learning – does your program support this through its activities and resources?

In the same vein, the second most frequently cited challenge among respondents was poor documentation. This is something your program can directly influence through the quality and depth of the docs you provide! Having great documentation should be table stakes for any developer program, but sadly it’s not. Great docs are a very strong and effective means of differentiation for your program against its competitors.

Best Practices in Action: Twilio’s New Code Tutorials

This post is from the WIP Factory Newsletter, which brings subscribers a monthly email of insight, analysis and news into the world of developer marketing and developer relations. To get more articles like this in your inbox every month, sign up for free now.

In this section, we highlight the tools, events and other activities the WIP Factory team has come across that have really impressed us. These are best practices in action: the top developer marketing and relations activities from the community!

Twilio has long provided a good example for other API providers with its developer site and documentation. It recently released a new set of code examples/tutorials that continue that trend. Let’s take a look!

The tutorials cover a wide range of common applications of Twilio’s APIs and services, providing illustrative examples of how they can be used. One thing that immediately leaps out is the multiple language support for most of the tutorials, which gives developers the option to see code in a range of languages and for a number of different platforms.

When you click through to your language of choice, you’re presented with a view of code, and accompanying notes for each step. The relevant bit of code for the step is highlighted, and links to other relevant parts of the Twilio API docs are provided too.

Once a developer has clicked through the tutorial, they can also download all of the code for the tutorial from GitHub and explore it further. 

The Twilio team explains some of their motivations and goals behind the new tutorials in a blog post. Its portal already had a good set of Quickstarts, which the team says it had good feedback about, but created the tutorials to go a step further and give developers a quick and easy way to get code into production apps and services.

These tutorials are great, and provide a good model for other API providers to follow, for a number of reasons, but two stand out:

  • They’re based on developer feedback and needs – they are written in the languages and for the platforms Twilio developers use most. The Twilio team knows its community, and acts on that knowledge.
  • They fill a gap that is often left between getting started materials and raw documentation. As the team noted in its post, it gets good feedback from its Quickstarts, but what does the developer do next? Whether by providing tutorials like these, or regular blog posts and demo projects to show how to build the API into an application, there’s a need for deeper, quality examples that are more “alive” than just the technical documentation.

 

From the DevMonitor: What can we learn from the shutdown of Parse?

This post is from the WIP Factory Newsletter, which brings subscribers a monthly email of insight, analysis and news into the world of developer marketing and developer relations. To get more articles like this in your inbox every month, sign up for free now.

Parse caused some waves in the developer world recently when it announced it will shut down in January 2017. The Facebook-owned mobile backend-as-a-service (mBaas) platform was well known and generally well regarded by developers, so the news came as quite a surprise. Why would such a seemingly popular service shut down? Furthermore, what lessons does it hold for other BaaS and developer tool providers?

Why is Parse shutting down?

The official word from Parse’s announcement is that it’s closing because “we need to focus our resources elsewhere.” A Facebook spokesman said, “Moving forward we want to dedicate more resources to high-impact products and services in areas like analytics, monetization, discovery, and authentication.” Pretty typical corporate-speak stuff, really.

On the face of it, the acquisition of Parse by Facebook turning into an acqu-hire isn’t that surprising. After all, Parse’s developer offering doesn’t totally fit with Facebook’s main business, and it’s unlikely that it would grow enough to make a significant impact on the parent company’s revenues or profits – which would require a contribution of hundreds of millions of dollars.

But Parse was certainly popular. Data from our DevMonitor tool shows that over the last year, an average of 450-650 new projects were started on GitHub with the keyword “Parse”, and the number was trending up. While that is impressive, it may just not be enough on the backdrop of the scale of Facebook’s larger business. This isn’t unprecedented, either, as it harkens back to the decision by PayPal to shutdown Stackmob, the BaaS service it acquired, in 2014.

Also, it’s worth considering the question of the success of these and other services at turning their users of free tiers of service into paying customers at sufficient scale. There is anecdotal evidence of many developers launching prototypes, MVPs or other first-effort projects using free resources, particularly for backends, then building their own infrastructure as their project grows.

Shutdowns like those from Parse, StackMob and others color developers’ perception of all similar providers. Why build on a platform that could disappear at any point, and potentially with short notice (such as the recent developments at Venmo and Kimono Labs)? Even if the services are backed by a big company, there is little guarantee of security – and a big credibility hurdle for service providers to overcome.

What can developer tool providers learn from Parse?

It’s essentially impossible for developer tool providers to overcome this credibility hurdle with developers, but it certainly can be mitigated effectively, and the Parse shutdown offers several tips on how to do so.

1. Know your developers, especially the free riders

Offering a free version of a service is, for the most part, table stakes these days for developer tool providers. Developers learn by doing, and in order to accurately assess a tool, they need to be able to use it. That said, providers need to be careful where they draw the line between their free and paid tiers of service.

Often, this is dependent on the provider’s business goals. Is user growth the primary objective, financial implications be damned? Or is it building a sustainable business with paying customers? The VC-driven nature of this space often emphasizes the former, but this in itself can work against the tool providers. Developers’ skepticism of free services, and their long-term stability, exists, and news like the shutdown of Parse only makes it grow.

Understanding who is using your service – and how – is crucial in order to tier and price your products correctly meet your business goals. Giving away services to try and get hockey-stick user growth isn’t always the right answer.

2. Use open source, open protocols and open tech to your advantage

Building user lock-in around proprietary technology is a long-standing tactic. But it’s something developers are increasingly on the lookout for – and again, the demise of Parse and other providers will only boost this further.

The higher the degree of lock-in, the higher the hurdle to attract developers will be. But this can be mitigated by building around open technologies and allowing developers to fully export their data, so that if they wish to move off of your platform, it’s easier for them to do so and reduces the reworking they will have to do. In turn, this makes developers more comfortable choosing to adopt a service to begin with.

This may seem counterintuitive to some – making it easy for customers to leave your service – but when lock-in turns developers off of your service in the first place, it’s a necessary step to take.

3. Eat your own dog food – and shout about it

One of the best ways to build developer confidence in your tools is to use them yourself. For example, Amazon Web Services avoids being painted with the same brush as some other cloud service providers in terms of long-term stability, because developers understand that the same services are used to power Amazon’s own business. AWS’ future is more assured than some other providers because Amazon needs it to survive, and shutting AWS down would have serious internal repercussions for the company.

For many tool providers – particularly when after they are acquired by bigger companies – this sort of dog-fooding either doesn’t exist or isn’t at all clear. By utilizing your own products and services and deeply integrating them into your own business, and by making developers aware of it, you build credibility as well as confidence that the service will exist over the long-term.