The guiding principle of a great DX
There is no question among developer relations people that a great developer experience (DX) is the key to a successful developer program.
The trouble is that different people define DX differently. Sometimes there are different views, even within the same organisation. For example, both Salesforce and Salesforce-owned Heroku have dedicated DX pages on their developer portals. But evidently, the two teams from the same company have quite different ideas about what DX is.
Besides, any experienced developer relations person will tell you that information on both the Salesforce and Heroku DX pages have little to do with what DX is actually about.
DX is not about technology. It’s about how developers feel about technology. This is a very important subjective dimension of DX that is often overlooked.
DX is a complex subject at the cross section of technology, marketing, and behavioral economics. It has many moving pieces that all need to fit together to deliver the desired outcome. API syntax, documentation, video tutorials, toolchain, support, onboarding, testing and monitoring tools, scalability, performance, and case studies are all important.
It all can become overwhelming very quickly, especially when multiple teams are responsible for different parts of the developer product. Where do you start, and how do you decide what is important in order to deliver a great DX?
The guiding principle
We have seen dozens of interactions of developers with API, SDK, portals, documentation, and tools when doing DX audits for our clients. (DX Labs does developer experience audits for companies that have developer programs.)
A clear pattern emerges from all these interactions. A great DX always does an excellent job of saving developers’ time and conserving their mental energy. This I believe should the the guiding principle of designing a great DX.
It’s wishful thinking to believe that developers enjoy using your API. No, most of them don’t. Developers enjoy building their own stuff and solving their unique problems. This is where they get that dopamine rush, which makes software development such fun. (Anyone who has written non-trivial software understands what I’m talking about.)
It just so happens that in the process of getting things done, developers may need to use your API, SDK, portal, tools, and documentation. A great DX will help them to get things done as quickly and effortlessly as possible saving their time and mental energy.
Easier said than done
We often see that DX blunders are really innocent mistakes caused by deep familiarity with your own API, documentation, toolchain, and portal. The more familiar you are with your product, the more difficult it is to see where others stumble. It’s so easy to assume that a confused developer is just an exception. That becomes even a bigger problem when API, SDK, tools, documentation, and portals are delivered by different teams.
This is the reason why getting feedback from developers is so important. Surveys of developers who already use your product can help a great deal, but they are not the panacea for finding all the DX ills. First, developer only answer questions that you knew to ask. Second, much like your own team, developers who are already familiar with your product will often miss where new developers got stuck and won’t see the opportunities to improve your developer funnel.
To get a true sense of how developers feel about your product you need to go beyond online surveys. Developer experience audits and checkups are a great way to learn in great details how real developers experience you product and where biggest opportunities for improvement are.
DX Labs is here to help with structured feedback and actionable recommendations from real developers on how to improve the DX of your product.