A Take on Developer Experience
article last updated: October 13, 2023
🌱 - A collection of sprouting thoughts.
A lot of people bring up the importance of feedback loops in Developer Advocacy. A great example of this is The Developer Advocate's Guide to Addressing Product Friction by Kurt which I absolutely love!
I've been thinking a lot about Developer Experience. This is a pretty wide subject. I like to define it as a summation of a developer's experience on your platform or ecosystem. This can encompass different parts of the developer workflow like tooling, community, content, education, and support. All of which alone are vast niches to cover. Here are some evergreen resources describing in their own way how developer experience interfaces with all the aspects of a developer workflow that I mentioned above.
- The Seven Deadly Sins of Developer Onboarding
- Developer Experience Metrics; How to measure DX using UX metrics
- Developer Experience at Netlify
- Developer experience is the next major competitive front in enterprise tech
- Redefining Developer Experience: Why DX is the New DevRel
Improving developer experience means helping developers jump up a skill level, one step up on the difficulty scale. A jump they need to realize they need to make on their own. I find that this is where education plays a huge role. I like a quote from a pal about how GitHub tackled this (paraphrasing here) "GitHub at first was a tool not a lot of people know they needed, so a big challenge the team had was educating them and helping them understand the value of GitHub. A big part of that was getting them to a skill level where the value of the tool became more apparent."
Education! Very important!
Quick change of ideas!
The first interaction with a tool (or first few) really says a lot about how the rest of the users' experience will be. Helping users understand the value your tool brings is the first brush with education.
Take Strapi for example a great Headless CMS that takes a lot of effort out of building and getting authenticated and fully functional APIs up quickly. It can be very hard to understand the value of the tool if users aren't aware of the effort abstracted away. When you educate developers on the core issue a tool solves, they better appreciate the work that went into solving that problem.
How I think about it. There's more value added by making your number of addressable developers larger.
Education means bridging that skills gap. Objectively, a chef with a better idea of why a sharp knife matters in the kitchen has a better experience using one (and will always want to use one!)
Cutting the skill gap is a great way to invest in your community too! Think of it as paying it forward. We gave and now it's time a reap a little. What we take here however is only great if we use it, we need to invest in actionable feedback loops.
Skilled developers know what they want. They're educated and empowered. They start to notice things that as people building a tool, we don't. They can tell us things they need. Things that can help others jump to the next skill level and make your tool a little or a whole lot better as a whole or on the developer experience side.
Like I said this only works if you use it as intended.
Here's how it's a loop! Getting more users to make tools better at the end of the day gives us...
-
More ways to improve our product by helping hear from our top percentage of skilled users.
-
More ways to improve and empower our community by educating them on all the ways we're making leaps in developer experience.
A tad utopian but this direction is one I'd like to take. It feels like a great way to keep our community happy and build something they'll enjoy. Of course, all of this is a bit high level given all the nuance that exists in products and companies.
If you'd like to see how this plays through join us or follow me on the bird app.