My take on Developer Experience

Developer Experience does not mean ‘does this look pretty’ nor ‘does this solve a problem’. It means ‘does this help you solve the problem’.

The latter two can sound exchangeable but they are different. There are many tools out there that can, technically, solve the problem. They have the features & capabilities to do it. But does it actually *help* you to solve the problem? I have had the pleasure of using many tools that *technically* could solve a problem, but I had to fight against the tool to make it work - they sure didn’t *help* me.

Developer Experience needs to focus solely on helping the developer achieve their goal.

Many tools just don’t care about experience, while others do care but get it wrong. I have seen a few different approaches, but in general I’ve noticed two styles: ‘feature based’ or ‘solution based’.

In my opinion, taking a feature-based approach to DevEx leads you to what I would describe as ‘pretty but shitty’. This approach agonizes over the experiences of each individual feature, ensuring that just using that one particular feature is beautiful. However, this approach tends to completely ignore that this feature is only one small part of how the developer is building a solution. It ignores the fact the developer needs to not only find the feature, but find it at the right time and in the right context to understand how/why/when to use it.

It ignores that building a solution is a journey; a story with a start, middle and end. Maybe even a Shyamalan twist or two somewhere.

The ‘solution based’ approach instead focuses on guiding the developer towards their desired outcome. It takes a step back from individual features and looks at the bigger picture. How do we take the developer from their starting point A to ending point C?

DevEx should be absolutely aligned with the original mission of your tool; What problem is your tool solving?

The best Developer Experiences leave your users believing that your tool is *the* natural solution to the problem, rather than just one possible way to solve it if you think about it a bit.

…perhaps this is one reason why so many get this kind of DevEx wrong; nailing the ‘why’ behind your tool is much harder than it sounds.

Vercel is one example of a company that absolutely nailed the Developer Experience for their product’s core goal: “Deploy frontend projects”. The cognitive load required to achieve that goal with Vercel is probably the lowest I have ever come across for any developer tool.

At no point in the journey do you ask ‘how do I solve this problem with Vercel?’ you simply know ‘Vercel solves this problem’. That is the goal of DevEx.