What Makes a Great Developer Experience?

Let’s say you have a team that owns a library that is used by ten other teams. The library team has their own goals, their own deadlines, and their own priorities. They are focused on what they have to do to accomplish those. If they are allowed to ship breaking changes to their customers every day and they experience no consequences themselves for doing so, then they will ship breaking changes every day, because that’s the most efficient and effective way to accomplish their goals.

This is an interesting idea. It feels obvious, but I’ve never considered this.

I use so much software where I feel like the developers must never use the software at all, as workflows that would be obvious to any user are buggy or convoluted.

If you are a library team and you want to make a breaking change, you have to refactor the codebases of all your customers in order to adopt the new, breaking change. If you are a cybersecurity team and you want a new control to be implemented on all the codebases at the company, you have to install it yourself in all those codebases and make sure it works.

I think this is an interesting idea, but I’m skeptical that it’s the full solution.

It seems hard to put in practice outside of very tiny and very huge orgs.

The author led the Code Health team at Google when I was there, so I saw this working because Google invested huge amount into tooling to make this work. But Google still had a lot of problems with misaligned incentives between libraries and clients, and there was still a lot of pain around breaking changes.

In contrast, I worked at Microsoft for 3 years, and never really worried about my dependencies breaking me, but there I also had to deal with way more legacy code and fear of changing anything because there were no tools for large-scale changes and the automated testing at the time was very coarse-grained.