My 7 favourite tenets of a good Developer Experience

[peibolsang]

After 8+ years building tools for developers, I learned that a good Developer Experience (DX) can seriously become a product differentiator, as it usually leads to a good User Experience (UX). Yes, it's all about making developers more efficient, creative, and just plain happier, but it's also about making your software products just better.

I've picked up on some key things that really lift up the DX game. Today, I'm giving away my top 6 must-haves for an awesome Developer Experience in this post. These come straight from my own journey, chats with developers, and some good old community wisdom. So, whether you're deep in the code trenches, managing products, or just getting your tech feet wet, these tips could give you a perspective on the whole DX scene.

Values

1. Liability

Don't solve generic problems. Solve specific problems by curating technology opinions and configurations. Most of the time, you'll do it through code. Alternatively, you'll do it through documentation. You must choose what to build wisely because code is a liability, and every line of code has a maintenance cost. As a result, get ready to remove some of your developer tools over time. As things evolve and industrialize, you must find your core values and lean on third-party libraries and cloud services.

2. Simplicity

Don't try to build magical tools that turn complex problems into easy ones. That can't happen. Instead, it's better to provide tools to make it easier for developers to deal with the complexity without hiding the essential details of such complexity.

Principles

1. Low cognitive load

Developer tools should not get in the way of developers. Good tools let developers keep with their train of thought easily without distracting them. There are no mental gymnastics needed to solve a problem. None. Your tools must let developers maximize their moments of inspiration.

The mental model a good tool pushes to developers is lightweight. There is no magic, and developers must still feel in control. Recognizing that engineering cycles are scarce, you should create functionality that does one thing, and does it well, giving developers time and space to focus on fixing those complex problems.

2. Abstractions, not illusions

Reducing the developer's cognitive load does not involve taking as many things away as possible. You don’t want to turn your abstractions into compositions or orchestrations of multiple solutions because that leads to unexpected surprises. Developers must know and understand what they are doing; therefore, you shouldn't hide essential details of what you are abstracting away. Abstractions should adhere to the "principle of less surprise," so developers must know at every moment what is happening when they work with your abstractions.

3. Leaky abstractions

A corollary of the above principle is that you should do “just enough encapsulations.” Creating non-added value wrappers on top of standard libraries and functionalities is a smell. Make sure your developers build on standard technologies (libraries or cloud services) with the help of your tools instead of building on your tools.

This means that your tools should not save developers from knowing things. Build functionalities that minimize how much a new developer has to know to start shipping (with default configurations or conventions) but provide a pathway to go deeper over time. The underlying technology should be exposed as a peer dependency so users can become experts about it through your tooling over time.

4. Not too much inversion of control

Focus on building primitives for developers (building blocks and examples), and be wary of creating generic frameworks (overarching and locked-down tools). If you create a framework, ensure it addresses a particular problem. In the words of PHP creator Ramus Lerdorf: “Everyone needs a framework; what everyone doesn't need is a general purpose framework. Nobody has a general problem; everyone has a specific one they're trying to solve.”

5. No “one-size-fits-all” abstractions

Once you have decided to create an abstraction, it can't be all things to all people. It's okay for your developer tools to offer different functionalities in different levels of abstraction for the same persona (e.g., a frontend developer), depending on their needs. However, you should not create one level of abstraction to serve all needs for the same persona.