Three DX lessons I learnt in 2024

1. Dev Ex is a people problem

Not only a technical problem. I started this year gung-ho ready to solve technical challenges. But the solutions I rolled out stemmed from a naive thought.

If I experienced these DX issues, then other devs would also have these issues. And if I solve these issues, then other devs would use the solution to solve their issues.

This thought turned out to be false.

I would create something new and exciting, that I was sure would solve the problem. Only to have no adopters. Or a change was made with immediate pushback and conflicting opinions.

Looking back, all of the above points are expected. The mental load on a dev team is huge. They're busy pushing features, tracking metrics, fixing bugs, reviewing code, and more. Any change that could disrupt their status quo will be painful. Even if we think the change is a good thing.

2. Measuring DX is hard

It's not impossible, there are companies like GetDX or Jellyfish built around DX metrics. But it's challenging to get a clear answer to this question:

Will we make the lives of our devs simpler with this particular DX change?

Maybe because the question is vague, it lends itself to being difficult to measure. But when we think of good DX, we think of these four points (source: Designing DX by Chris Coyier)

1. You’re able to do the thing you want to do, and it’s clear if you can’t.

2. It’s obvious and easy how to do the thing you want to do.

3. Doing that thing is fast and satisfying.

4. If anything goes wrong it’s clear, actionable, and help is available.

Classic DX productivity metrics from SPACE and DORA frameworks don't answer the above question. Metrics like PRs merged, code changed, CI run time, tickets completed, bugs introduced vs fixed, and more, are lagging metrics.

Don't get me wrong, these are important metrics to track. But we need to also track sentiment from developers.

This is where GetDX has introduced the Developer experience index (DXI):

With this metric, we could correlate DX changes to time loss which equals cash money.

3. DX should be treated like a product

We've talked about people and metrics. And you're probably thinking, this is product talk! And you're right!

The biggest lesson I learnt this year is that DX should be treated as a product.

As a product, we need to conduct user interviews, set up proper support channels, measure the right things, and continually market.

This lesson may not be news to you. Especially if you have a large DX team at a large company. But I feel that DX at a company gets started because a single dev was fed up with a particular problem. So they rolled out a solution to fix it. Eventually, a team forms around this process. And it's this fledgling DX team that needs product thinking the most.

This podcast on CTO buy-in, measuring sentiment, and customer focus by Engineering Enablement has really influenced my thinking around treating DX as product:

It's been a fun year of learning about DX. Thanks for joining me on this DX journey so far!

ICYMI

I released a video on how to use Dev Containers to prototype with zero* dependencies.

*Except docker