Commentary: A great developer experience requires working with both simplification and complexity-embracing development tools, says Akita Software CEO Jean Yang.
Though we sometimes conflate easy or simple with a great developer experience, sometimes what a developer wants is the ability to dive deep into complexity, because that's where she'll gain the insights needed to truly tackle a problem.
This is the argument Jean Yang, founder and CEO of Akita Software, makes, and she's right. Even as the industry keeps coming up with new ways to simplify development through low-code or no-code tools, we also need to keep an eye on things that give developers the complexity they need to do their jobs well--one example is observability.
SEE: The best programming languages to learn--and the worst (TechRepublic Premium)
The value of having different categories of developer tools
Rather than munging the different strands of developer experience (DX) into one big ball, Yang suggested we separate developer experience into at least two different paths:
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! 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.
This is where many people stop when thinking about developer experience. Years ago a colleague (Yehuda Katz) called this "developer ergonomics," and the name has stuck with me. As Ben Kinsey defined developer ergonomics, it is "the study of efficiency in one's working environment." So if tooling/docs/etc. make life easier on the developer, those are good ergonomics.
Or can be. Chris Ferdinandi has called out the problem with this approach: "Just as tax cuts for businesses often don't lead to new jobs, but instead lead to bigger bonuses for executives or shareholder payouts, [better ergonomics to yield] more JS often leads to developers having an easier time writing even more JS, and the cycle continues."
And, of course, "easier" doesn't necessarily mean a black box that abstracts or hides away all complexity. In fact, sometimes what you want is the exact opposite, as Yang continued:
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. 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.
As such, she wrote, we need "More UX [user experience] conversations about how to help developers embrace complexity" as well as "More love and attention for complexity-embracing dev tools, not just the set-it-and-forget-it tools."
Honeycomb CTO and cofounder Charity Majors has stressed the importance of complexity-embracing tools in the area of observability. Observability-driven development, in her telling, is "actively instrumenting code in order to be able to have more of a constant 'conversation' with production systems." It's understanding how changes to code affect users in real-time, driven by developers owning the outcomes of the code they write, because no one else is better positioned to fix problems in that code. No one else knows it as well.
For developers to do their jobs well, they must have access to the complexities of logs, traces, etc. It's not a matter of monitoring systems after the development fact; it's building ongoing insight into the process of development through virtuous feedback loops.
In short, to Yang's point, by all means, let's make some aspects of the developer experience as simple as possible. For others, however, let's keep things complex.
Disclosure: I work for AWS, but the views expressed herein are mine.
- Yay or nay: What do you really think about low-code and no-code platforms? (TechRepublic)
- Low-code and no-code won't kill developer jobs, here's why (TechRepublic)
- Listen to TechRepublic's Dynamic Developer podcast (TechRepublic)
A guide to The Open Source Index and GitHub projects checklist (TechRepublic Premium)
Programming languages and developer career resources (TechRepublic on Flipboard)