Why care about the developer experience?
I’ve moved! Check out this article on my new site here.
Imagine you’re a developer working at Opentech Corp tasked with adding payment support to your company’s product. You start by doing research on payment processing solutions in order to make a recommendation. You first try out payment processing company XYZ Processing because you’ve seen them around for a long time and you know it’s used by other companies.
After banging your head against the wall for 2 hours to get a simple test payment working, you give up and try out company ABC Processing.
With ABC Processing you’re taken through a smooth registration flow, download an SDK for the language of your choice, and you are accepting payments within a sandbox environment within minutes. Furthermore, you want to know whether ABC Processing supports subscriptions and transactional payments, not only do they have an in-depth guide that walks you through how to set it up, but there’s also a video tutorial that takes you through everything step by step.
Because of the how easy ABC Processing’s integration is, you’re done ahead of schedule and look like a genius to your manager. You recommend ABC Processing and your company moves ahead with it.
As great as Opentech Corp has been, six months later you get an amazing offer to join Startup Inc. 2300 that you can’t pass up. Your first responsibility is to add payment support to their stealth mode world changing blockchain-based gig economy at home coffee roasting service launching next month.
Which payment processing company do you think you’d go with?
This fictitious story is not that unrealistic for how many developers found and fell in love with Stripe. By focusing on creating a great developer experience, Stripe created viral growth for a product that does not feel inherently viral, a payment processing system. They did this by recognizing the importance of the developer experience, executing on it, and by marketing to developers.
Given that Stripe is now valued at $36 billion, perhaps this is something worth prioritizing?
Let’s take a look at what is developer experience, why it matters, and how to do it well.
What is developer experience (DX)?
With the explosive growth of software, User Experience (UX) has become as core to creating a great product as the actual engineering that goes into creating the software. There are countless guides, best practices, and articles showing the impact that great UX can have on everything from product sign ups, payment flows, to utilization of features, and user retention. UX goes well beyond the pixels on the page, but into understanding the feeling users have when using your product.
Developer experience or simply DX is equivalent to UX when the main user of the product is a developer. DX encompasses the experience that developers have using a product’s client libraries, documentation, frameworks, APIs, tools, technology, or service.
The responsibilities of DX functions span API design, quality assurance, developer tooling, and developer relations. To do all this well, you must constantly ask yourself, what do users of your API feel and how can you make them feel better?
With this baseline understanding of DX, let’s take a look at why it’s important to focus on creating a great developer experience?
Why focus on creating a great developer experience?
With the massive explosion in products that target developers as their audience (see API growth chart below), it’s more critical than ever that companies prioritize DX.
Just as core product developers are no longer responsible for a product’s UI, the core developers should not necessarily be responsible for the API developer experience. You need a dedicated team of DX experts as well as a company culture that understands and cares about the developer mindset.
A great developer experience provides a fast track to Hello World (see Everyday Developer) and according to Ian Jennings, founder of Haxor, most companies think their time to Hello World is about 15 minutes, but in reality, when tested, 50% of developers never even make it that far.
When it comes to developers choosing a platform to solve a particular issue, and ultimately the companies they work for, it’s generally much easier to abandon an API during onboarding as soon as you hit a roadblock and switch to the next option than it is to take the time to figure out and solve the problem. Platform decisions that may lead to large longterm licenses are often determined in days, hours, or even minutes.
McKinsey & Company reported that companies at the top of Developer Velocity outperform other companies in terms of business value by 4 to 5X. Furthermore, in the 2019 State of API report, when API consumers were asked to vote on the most important characteristic of an API, more than 60% indicated “ease-of-use” as their primary desire when integrating.
SendGrid saw massive business value within the first 18 months of establishing their DX team. During this period they reduced the time from developer registration to sending their first email to 3 minutes, their new API documentation reduced support tickets by 315%, and they increased email traffic flow through their client libraries by 239%.
As mentioned previously, Stripe’s focus on the developer experience helped them grow through word of mouth and network effects; “[t]heir audience, developers who are crammed for time, demand excellence, and scrutinize products not on their marketing but on their merits, don’t respond to splashy campaigns–they respond to things that make their lives better and their jobs more efficient and quantitatively better.”
Twilio transformed an industry by focusing on developers as their go-to-market strategy, “an end customer that turned out to be more valuable than people initially thought”. And after AccuWeather’s developer portal launch, where developers could build applications using the company’s weather data, they grew their community to 24,000 developers in the first 10 months, generating hundreds of sales.
By focusing on developer velocity and ease of use, developers are free to concentrate on solving new and interesting problems core to their business goals rather than eating up time battling API integrations. This makes developers happy and a happy developer will likely recommend your product to other developers and take your product with them as they switch companies throughout their career.
The keys to a great developer experience?
There’s a lot that goes into creating a great developer experience. To really do this right, DX needs to be part of your company’s culture and you need a company lead to serve as the champion for this culture and vision. Otherwise, there will always be a tendency to prioritize and resource the development of new features that appear to have a clearer line of sight to be revenue generating while accepting that the existing developer experience is good enough.
Along with having the right culture and a champion at a leadership level, the following are the key principles I believe companies need to focus on to start their DX journey to awesomeness.
Communication
Communication with the developers using your product is extremely important. You need consistent communication in order to build awareness about changes to the API, new versions, new features, and best practices. In my own career, I’ve been burned by this multiple times where I did not effectively communicate a change that led to confusion by the community and a loss of trust.
At a baseline level, you can use change logs, release notes, and email lists to keep your most engaged developers up to date. If you have an active community, you can use tools like Slack to provide updates and help build up your community. With the products I work on, we host regular office hours to share updates and I have bookable time on my calendar if someone wants to have a 1:1 conversation.
Beyond having channels available for communication, the style in which you communicate is also important. It needs to be authentic, resonate with the developers that use your product, and be on brand for your company, just as a marketing message might be.
Documentation
Often the first experience a developer has with a product is the developer documentation. In the DX and developer relations communities, we often measure the time from registration to our version of Hello World, but developer engagement starts well before registration.
Developers read through the documentation to get a sense for what the product and API does. Do they understand the functionality? Does it look well organized and comprehensive? If not, they may move onto the next available solution before even attempting to use your product.
Years ago in graduate school, I picked a web framework primarily due to how great the developer documentation looked and how active the community was. I figured if I couldn’t figure something out, the docs likely had the answer. I later founded a company and used this framework to power my company’s product.
Documentation needs to be comprehensive, but also well organized. The documentation needs regular audits to make sure it’s up to date and easy to follow. We run bug bashes on our docs as well as write friction logs to continually improve the developer experience.
Client libraries
Client libraries or SDKs are a way to provide easy consumption of an API. Rather than the developers having to write code to POST JSON to a REST endpoint, they can call a function provided by your client library that encompasses the object they need to pass to the API and idiomatic of the language.
However, building a great client library is a lot of work and it’s really difficult to support every possible language, so you have to choose a subset, which ends up creating a bias for how you want developers to work with your product.
For example, if you only support a Java client library, then inherently, Java developers are going to be more successful and other developers that favor other languages may assume your product only works in Java or that’s the best tool to use. The decisions you make in terms of language support will have an impact on the workflow of the developers that choose to use your product.
But you have to choose your battles, it’s better to have fewer client libraries that are really well designed, maintained, and documented than a large number of libraries that are impossible to understand and use.
Code samples
Code samples serve as demonstrations of your technology and client libraries. They should be an integrated part of your documentation and also serve as demonstrations of what your platform is capable of. This helps developers understand the potential of the product and provides a starting point to accomplishing a similar experience.
Do not assume expertise
When you’re close to a product and work on it day in and day out, it’s easy to forget how much intrinsic knowledge you have. This can lead to assuming a certain level of knowledge when it comes to using your product or when you use certain product-specific terms without defining them.
Another issue is that it’s possible that the developer trying to use your product has very limited experience in the programming language they are using or is still very junior. Guides, README files, tutorials, and the like need to be comprehensive to cover all skill levels.
Paying attention to support tickets related to terminology confusion can help highlight these problems. We run bi-quarterly user satisfaction surveys to track how our community is evaluating our documentation and try to identify information gaps. We also meet regularly with the support team to monitor consistent issues that can be addressed at scale by improved documentation or other resources.
Easy to debug
This seems obvious, but it’s easy to overlook or not prioritize.
It doesn’t matter how great your documentation or product is, people will run into issues where they need to figure out what’s going on. Ideally, your platform has built-in support for tooling like debug consoles, an API dashboard, or tools to help recreate specific production environments like an emulator.
On one product I worked on that was in the secure messaging space, the protocol was extremely secure, to the point where it made it very challenging to understand why it wasn’t working when it wasn’t working. It was a complete black box. We ended up having to build in various debugging tools and options into the API to make it easier for developers to uncover issues and solve them without hands-on support.
Also, depending on the nature of your product, a sandbox environment for testing ahead of launch is critical. No company wants to launch an experience with real users prior to internal testing.
Final thoughts
While UX is now a well established critical component to delivering high quality products, DX is still relatively new and sometimes overlooked.
Companies often fail to prioritize the developer experience because they are too familiar with their own product or they are not actively seeking feedback and assume people will get it. To do DX well, you need empathy, and a dedicated team of professionals focused on improving key DX metrics.
With so many APIs available, you are constantly competing with other products for the attention of developers. You may only have minutes or even seconds to convince someone to dig deeper into your solution.
According to the Ori Pekelman’s 3:30:3 rule as applied to APIs, a developer needs to be able to understand what your API does in 3 seconds, once you have their attention, they need to be able to identify how to call the API within 30 seconds, and finally, be up and running within 3 minutes.
That’s a high bar, but one you need to aim for if you want to compete with the best in class developer experiences in the world.
