How to build an awesome Developer Experience (DX)
Master your developer experience like "Jiro Ono"
I’ve always wondered what makes a developer experience exceptional.
I’ve finally found my answer by grasping the significance of ‘quality‘ in Japanese culture.
Zeno Rocha describes two kinds of quality :
atarimae hinshitsu (当たり前品質)
miryokuteki hinshitsu (魅力的品質)
Atarimae hinshitsu is the idea that things should work the way that they are supposed to.
Miryokuteki hinshitsu, on the other hand, is the idea that things should have an aesthetic quality. It's basically the kind of quality that fascinates you!
Whether you’ve had the privilege of dining at Jiro Ono’s restaurant or have immersed yourself in the ‘Jiro Dreams of Sushi‘ show, you’ll find this fascination and captivating quality.
Roget Ebert captures this essence by concluding:
While watching it, I found myself drawn into the mystery of this man. Are there any unrealized wishes in his life? Secret diversions? Regrets? If you find an occupation you love and spend your entire life working at it, is that enough? Standing behind his counter, Jiro notices things. Some customers are left-handed, some right-handed. That helps determine where they are seated at his counter. As he serves a perfect piece of sushi, he observes it being eaten. He knows the history of that piece of seafood. He knows his staff has recently started massaging an octopus for 45 minutes and not half an hour, for example. Does he search a customer's eyes for a signal that this change has been an improvement? Half an hour of massage was good enough to win three Michelin stars.
To build this fascinating quality, Jiro Ono was extremely focused on his customer’s perceptions.
Similarly building an awesome developer experience means you go beyond the functional part and focus on your developer’s perceptions that trigger their positive emotions (fascination, happiness …)
Understand your developer’s emotions
I believe that understanding the developer’s emotions and triggers is a great approach to enhancing DX. Abrahamsson, Graziotin, and Wang also confirm this belief as they demonstrated an empirical correlation between the Affective States of Software Developers and their self-assessed Productivity.
For more than thirty years, it has been claimed that software developers are essential when considering how to improve the productivity of development process and the quality of delivered products. However, little research has been done on how human aspects of developers have an impact on software development activities. We echo a call on employing psychometrics in Software Engineering research by studying how the affective states of software developers - emotions, moods, and feelings - have an impact on their programming tasks.
Re-design your Developer Journey
As developers interact with your products and immerse themselves in your environment, they traverse a virtual path that leads them from point A to point B (desired outcome).
We can recognize two sides within the developer journey path:
How your developers engage with your environment (e.g. developer community, team, organization, devRel program…)
How your developers interact with your systems to accomplish their tasks (code base, documentation, landing page, tutorials…)
Your developer intends to reach the destination faster and enjoy the journey by interacting with your environment and systems.
Every interaction serves as a step toward shaping the perceptions of your developers.
To optimize your DX, you need to focus on re-designing these steps:
Flag each step with a color:
Red: Friction felt by developers and prevents them from achieving the desired outcome. (e.g. critical recurrent bugs)
Amber: Friction that slows down your developers from achieving the desired outcome. (e.g. developers can find some manual workarounds)
Green: Zero friction
Minimize the number of steps
Fix the Red and amber steps
Divide and conquer your Developer Journey
Getting your developer journey right is a challenging task, It entails different stages. The nature and number of stages might be different and tightly coupled with what kind of developers you are targeting, for instance, internal developers will experience different stages than external developers.
Suppose you're managing an Open Source API or library. Employing a divide-and-conquer strategy involves outlining the essential stages that shape your developers' journey. Typically, three stages will be necessary:
Onboarding
Objective: Reduce the time it takes for developers to get value from your product.
Steps
Getting started guides / quick start guides
Hands-on tutorials
Use-cases
Guided tours and checklists
…
Metrics
Time To First “Hello world“
Completion rates for setup / interactive tutorial
Number of downloads/installations
Positive feedback on the onboarding experience (NPS)
Adoption
Objective: Reduce friction and build trust with your developers
Steps
Documentation
Sandbox / Playground
Debug / Error management
Changelog
Support
Webinars / Events
…
Metrics
Active product usage
Number of created assets (e.g APIs created)
The time it takes a user to fix an error
Positive feedback on the onboarding experience (NPS)
Contribution
Objective: Increase the number of active contributors and maintainers
Steps
Documentation
Contributors and maintainers mentorship program
Ambassador program
Webinars / Events
…
Metrics
Time to first PR review
Number of active contributors/maintainers
Wrap up
By embracing the principles of quality, understanding the developer’s emotional aspects, and strategically redesigning the developer journey, you can create an exceptional developer experience that fosters fascination, happiness, and productivity.
In the following video, Jiro and his son share the secrets of applying these principles to make the best sushi in the world.
👉 If this post prompts you to reach for your chopsticks, feel free to share it! Or click the ❤️ button on this post so more people can discover it on Substack 🙏
Nice perspective, Samir, and useful guidance on evaluating the developer journey.
I think it also helps to define a Vision statement for your DX, i.e. I have adopted "Make our APIs a joy to work with", which I think falls nicely into Miryokuteki hinshitsu