Dave points to Sarah’s post on Developer Experience (DX) at Netlify. Part of what Sarah did there is lay out what the role means. It’s a three-part thing:
- Integrations Engineering (e.g. features)
- Developer Experience Engineering (e.g. building integrations to ensure quality end-to-end for customers)
- Documentation (e.g. … uh, documentation)
I like it. You gotta define the thing to do the thing. Dave, though, writes about being a consumer of DX rather than a creator of DX. Another three-parter:
- Is it easy? Does this technology solve a problem I have better than I’m currently doing it.
- Can I get help? If I have a problem, can I talk to someone? Will I talk to someone helpful or someone shitty?
- Is the community healthy? If I do go all-in on this, is the community toxic or nice? If applicable, do good community extensions exist?
Another favorite of mine on this subject is Shawn Wang’s Developer Exception Engineering, which agrees with the basic premise of DX, but then digs a little deeper into the “uncomfortable” (yet honest and candid) aspects. Here’s one example:
Is your pricing predictable or do your users need a spreadsheet to figure out what you are going to charge them? If charges are unexpectedly high, can developers use your software to figure out why or do they have to beg for help? Are good defaults in place to get advance warning?
I like that good DX can be born out of clarity in the uncomfortable bits. Where are the rough edges? Tell me, and you earn my trust. Hide it, and you lose it.
About Author
