We bought a fancy new can opener, the kind with the squishy handle. When I first held it in my hand, it felt immediately comfortable. The only problem was I couldn’t figure out how to open a can.
That initial use is an important milestone, whether the tool is a can opener or an API. In fact, Hello World has become so much a goal for developer experience that it has its own shorthand—TTHW (Time to Hello World) or TTFHW (Time to First Hello World). People like me have so emphasized these goals that there’s a danger that what comes next can get lost in the shuffle.
The goal of a can opener isn’t to open a single can. Similarly, most of developer experience happens after Hello World.
The Developer Journey to Success
My definition of developer experience is broad and is meant to go beyond any single moment in a developer journey:
Developer experience is every interaction a developer has with your company, service, and product.
It’s a paraphrased version of Don Norman’s take on user experience, with “developer” in the place of user.
Clearly “every interaction” goes beyond the first.
In fact, as you see on the simplified developer journey timeline, developer experience begins with a first impression. That could be finding a blog post, following a link, or hearing about your product from someone else.
Only after this first impression can a developer have that important first experience. Yes, you should aim to improve it, because without it developers might not continue on the timeline. And notably, the largest path on the timeline comes after the first experience.
Identify and Measure Success
To get developers from first experience to first success, you need to understand what it would mean for them. In can opener terms, think more about their other actions in the kitchen. Your product plays a role in a larger project or solution to a developer problem.
The best developer documentation includes common use cases. These can spark developer creativity, or even provide’ a blueprint for their prototype. You can create sample apps for each use case to decrease the time to first success-and increase the likelihood a developer will reach it.
In addition to identifying success from the developer perspective, you want to know how it looks in your product. What signs do you have that someone has moved from tire-kicking to actual usage? It might be repeated logins, volume of API calls, or the amount of data stored in their account. When you identify it, you can measure it.
Finally, you can use content and communication channels to help more developers reach success. Ultimately, this level of developer experience has more impact than Hello world—for developers and your business.
Remember Long Term DX
Once a developer has reached success, they’ll have less active involvement with your developer experience. Hello World is way back in the past. Yet, every interaction continues to provide an experience. Some are initiated by developers and others come from your own maintenance. Both can impact developer experience.
The most obvious example of post-integration developer experience is downtime—planned or otherwise. When a service is unavailable, at a minimum a developers’ workflow is impacted. In other cases, it might cause downtime of the developer’s app, too. That means your developer experience flows through to the whole company, and their customers.
Downtime isn’t the only cause of ongoing negative developer experience. Any time you make updates to your product, the mere change can cause issues for developers. Even well-meaning improvements can force developer’s to return to their code for a fix.
You might add data to your API or fix a bug. Depending how developers have integrated, that could actually break existing code.. of course, you want to make improvements, but a great developer experience includes a lot of communication with each change, including an opportunity to test for breaking changes.
Finally, there is maintenance entirely in the control of developers. over time, they may expand the integration to use even more of your product. That means they’ll return to your documentation and other resources anew. Instead of Hello world material, they’ll be looking for evergreen references or guides specific to a new feature. You should speak to this returning audience, too.
At a minimum, ensure your reference is accurate. In these return visits, the original integration will be a hazy memory. It might even be a different developer. Help them out with up-to-date functionality.
Another thing to look out for is consistency within your product. Use the same schemas for data and ensure small details like the way you refer to fields is the same. Even if different teams built two areas of the product, developers interpret it as a singular experience.
Everything that helps returning developers also improves the developer experience of those earlier in their journey. Even though the Hello world experience is often missing, it’s not the only problem to solve. Remember to consider the entire developer journey from first impression to the last interaction.