Comment: A great developer experience requires working with both simple and complex development tools, explains Jean Yang, CEO of Akita Software.
While we sometimes confuse easy or straightforward with great developer experience, sometimes what a developer wants is the ability to dive deep into the complexity, because that’s where they’ll get the information they need to really get the job done. ‘tackle a problem.
This is the argument of Jean Yang, founder and CEO of Akita Software, makes, and she’s right. While the industry continues to come up with new ways to simplify development through low-code or no-code tools, we also need to keep an eye out for things that give developers the complexity they need to do their jobs well. – an example is observability.
SEE: The best and worst programming languages to learn (TechRepublic Premium)
The value of having different categories of development tools
Rather than lumping the different strands of the Developer Experience (DX) into one big ball, Yang suggested splitting the Developer Experience into at least two different paths:
When we talk about “developer experience,” we really need to separate development tools into two categories: those that make things easier and those that help developers get involved in complexity. DX needs are different for simplification tools and complexity tools! In the “simplification” category of development 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-accessible as possible and protect the developer from most of the details.
This is where a lot of people stop when they think of the developer experience. Years ago, a colleague (Yehuda Katz) called it “developer ergonomics”, and the name stuck with me. As Ben Kinsey defined the ergonomics of developers, it is “the study of efficiency in his work environment”. So if tooling / docs / etc. make the developer’s life easier, it’s good ergonomics.
Or maybe. Chris Ferdinandi denounced the problem with this approach: “Just as tax cuts for companies often do not lead to new jobs, but rather lead to higher bonuses for managers or payments to shareholders, [better ergonomics to yield] more JS often makes it easier for developers to write, even Following JS, and the cycle continues. ”
And, of course, “easier” doesn’t necessarily mean a black box that abstracts or hides all complexity. In fact, sometimes what you want is the exact opposite, because Yang continued:
The most classic example of a development tool in the “embracing complexity” category is a debugger: it shows you your stack trace; it shows you a call graph. It gets you where you need to go by giving you the tools to explore a complex system. Observability tools belong to this category. When people think / research developer tools, they often have simplification tools in mind. But for some purposes what you actually need is a tool that encompasses the complexity. For example: surveillance can only take you to a certain point. At some point you need something to help you because of the root.
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 to developer tools that incorporate complexity, not just setup and forgetfulness tools. ”
Honeycomb CTO and Co-Founder Charity Majors emphasized the importance of tools integrating complexity in the field of observability. According to her, development focused on observability is about “actively instrumenting the code so that you can have a more constant ‘conversation’ with production systems. It’s about understanding how changes to code affect users in real time, driven by developers who own the results of the code they write, because no one else is better placed to troubleshoot problems in the world. this code. No one else knows that too.
In order for developers to do their job well, they need to have access to the intricacies of logs, traces, etc. It’s not about monitoring systems after development; it is about building a continuous vision of the development process through virtuous feedback loops.
In short, from Yang’s point of view, by all means, let’s make some aspects of the developer’s experience as simple as possible. For others, however, let’s keep it complex.
Disclosure: I work for AWS, but the opinions expressed here are my own.