Read on Twitter
When we talk about "developer experience," we really need to separate dev tools into two categories: ones that simplify things away and ones that help developers engage with complexity. DX needs are different for simplification tools vs complexity-embracing tools!
Thread.
Thread.
In the "simplification" category of dev tools are all kinds of automation tools: APIs like Stripe and Twilio; SaaS products like Netlify; domain-specific languages like GraphQL.
You want these tools to be as one-click as possible and shield the developer from most details.
You want these tools to be as one-click as possible and shield the developer from most details.
The most classic example of a dev tool in the "complexity-embracing" category is a debugger: it shows you your stack trace; it shows you a call graph. It lets you get where you need to go by giving you tools to explore a complex system.
Observability tools are in this category.
Observability tools are in this category.
When people think about/look for dev tools, they often have simplification tools in mind. But for some purposes, what you need is actually a complexity-embracing tool.
For example: monitoring can only take you so far. At some point, you need something to help you root cause.
For example: monitoring can only take you so far. At some point, you need something to help you root cause.
What I'd love to see:
More understanding that not all dev tools can simplify your problems away!
More UX conversations about how to help developers embrace complexity.
More love and attention for complexity-embracing dev tools, not just the set-it-and-forget-it tools.
More understanding that not all dev tools can simplify your problems away! More UX conversations about how to help developers embrace complexity. More love and attention for complexity-embracing dev tools, not just the set-it-and-forget-it tools.
Do we need another low-code tool, or do we just need more developer-friendly tools for working with SaaS APIs? 
