What is Developer Experience? a roundup of links and goodness

I recently contributed to a series of fireside chats hosted by LaunchDarkly. One of the themes that we discussed was Developer Experience, and how to improve it. I was asked by one of the attendees at the EMEA event (video here, interview by Cody De Arkland) about further reading on the subject and offered to put together a post about it. So here we go.

I will start with some of our own writing.

Developer Experience is about creating an environment in which a developer can do their best work. DX is the context in which developer productivity can be unleashed, in which individual needs can be successfully balanced with those of the engineering team. DX is about developer feelings – it is a sociotechnical system which should consider every touchpoint a developer interacts with to plan and produce software, from learning a platform to the very first line of code all the way through its promotion into production. From documentation to SDKs to version control to monitoring and observability, everything a developer touches will have an impact on their productivity. Culture too, helps to define a good DX of the lack of it.

A great developer experience gets out of the way, leaving the developer in a flow state. DX allows developers to be more effective, by making the good thing the easy thing – in areas such as testing, security and observability this is increasingly important. Good DX allows for shift left (see Rachel Stephen’s post below for more on this).

The DX is about more than function; it’s not just about the quality of the tool. The more features that are added to a given tool or platform, the more challenging it becomes to deliver a high quality experience. That’s why opinionated platforms can offer a better developer experience. Offering more and more primitives can make the DX worse – bringing overheads in their wake. Stephen O’Grady discusses this in detail here, with a nod to the strategies and cultures of AWS and Heroku.

DX is less about laundry lists of features, and more about how those features are thoughtfully balanced with a bias towards usage. DX removes points of friction in setting up environments. DX is coding without yak-shaving. Good DX is an iPhone moment.

Thanks to open source and its democratisation of access to software, the tech industry has experienced a Cambrian explosion of technology options, services and approaches. In theory, this is great for software developers. We have at our disposal an enormous bounty, a cornucopia of software delights. Judging by the dramatic reductions in mean time to ship code we have driven over the past decade, this sea of software options has been an enormous win for individuals and the industry as a whole. This win has not come without a cost.

As the sheer number of products and services needed to build and ship code has grown, so too has the burden on the software developer and engineering organisation. Much of the responsibility for selecting, assembling, operating and maintaining application development toolchains has been left to the engineer. At RedMonk we call this problem the Developer Experience Gap.

Most toolchains, from where the first lines of code are written through test, build, integration and deployment all the way out to production, are made up of a patchwork quilt of products and services from different suppliers.

What the market is telling developers and their employers alike, effectively, is that the market can provide a system that will shepherd code from its earliest juvenile days in version control through to its adult stage in production. It is telling them that the system can be robust, automated and increasingly intelligent. And it is also telling them that they have to build and maintain it themselves.

In 2022 it’s obvious that this approach cannot stand. FAANG and startup companies are increasingly building DX teams to work with platform teams to improve overall organisational productivity and development velocity. Spotify’s Backstage, the open source platform for building developer platforms is gaining traction because organisations want developers to spend more time coding and less time thinking about and working on infrastructure. Enterprises too are acknowledging the need to improve toolchains and developer productivity – which explains VMware’s decision to build a front end for it’s Tanzu Application Platform based on Backstage. Golden paths and guardrails are the new watchwords.

Meanwhile in web development opinionated platforms are exciting developers that want productivity with modern workflows built in. Netlify looked at patterns based on bringing interactivity to static site development and gave it a name, and a design sensibility: the JAMstack. It also helped mainstream the pattern that whenever a new deployment is created, it automatically generates a unique URL – a simple, brilliant innovation, also utilised to great effect by Vercel. Heroku had innovated with Review Apps.

From developer first to DX first platforms, the IT industry is people endlessly remaking remakes of Heroku.

DX is becoming increasingly critical for companies of all shapes and sizes because developers are the most important constituency in building digital products and services. Competition for talent is fierce, and developers are more demanding than ever. Why would a developer put up with a poor developer experience when they can likely find a job that better aligns with their needs and preferences? Even distributed work is intertwined with DX now.

That’s enough from me for now. Here are those links I promised.

Firstly, I love this 2013 dissertation by Fabian Fagerholm and
Jürgen Münch because it is so holistic and comprehensive in thinking about what DX is, and can be. It takes an academic multi-disciplinary approach and is all the better for it.

New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers’ feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance.

So back to the present, and a more practical application of DX. Sarah Drasner is a powerhouse on DX. You should follow her on Twitter for all the wisdom. See for example this thread

When we think about Developer Experience, we have to think beyond a single product.

In a Developer’s journey, we begin to prioritize the features that are touch points along the larger system.

What I often find is there are gaps between these products where we have to do intentional work to make things feel seamless.

When making those investments, the most common paths can be defaults, while anything the user needs that’s more unique can become configurable options.

Drasner is now Director of Engineering, Web @ Google, but while at Netlify running their DX Engineering group wrote this great post. You have to be holistic about it, bridging engineering, documentation, third party integrations, developer advocacy and so on.

Developer Experience Engineering is a hybrid role that is an intersection between more traditional advocacy of engaging in communities, writing posts, and doing open source work with engineering work.

Jean Yang, CEO and founder of Akita Software, just wrote a frankly fantastic piece, essential reading about DX and the need to develop platforms for the 99%. She argues that companies like Facebook, Apple, Amazon, Netflix and Google are built different. The needs of most development shops really don’t map to them, and in order to aim for mass productivity we should be thinking about the needs of the 99%. “Trickle down tooling” (love that analogy!) is no more realistic than trickle down economics.

It matters to talk about the 99% Developers because these are the developers building the software that powers our lives — insurance, health care, retail, and banking, just to name a few. It’s not only small companies that can’t easily adopt the processes of modern, tech-first companies; it’s most companies that were not built around technology and that have decades of legacy software practices firmly in place.”

Day 2 DX doesn’t get enough attention and it should:

It should not be a surprise that with most tools worth their price tags, most of what a developer experiences — and experiences pain around — occurs outside of the first minute of use. First, integrations with developers’ day-to-day-workflows (for instance, existing code review, CI/CD workflows, and modes of collaboration) is a better indicator of whether a product will be sticky than are initial delighters. It’s well-known among developer tools creators, for example, that integrating with GitHub and GitLab will help make your tool much more useful and appealing.

One company aiming at this kind of automated tooling space is Harness. This post, How To Prioritize The Developer Experience And Improve Output is useful.

With the consumerization of enterprise IT, the expectation for users of enterprise systems continues to rise, because of their experiences outside of the enterprise. Seen as highly technical when compared to an average business system user, the developer experience can sometimes take a back seat because of a stigma that “developers can just figure it out” and should be able to string together disparate open source projects even though it’s not their expertise. Even providing an API or interfaces for developers to use without explanation and education can hamper DX. Having poor DX is a detriment to overall engineering efficiency, and the ability to innovate and iterate, while not adding to technical debt.

We also really like this post from Albert Cavalcante – What is DX?

Developer Experience is the equivalent of User Experience when the primary user of the product is a developer. DX cares about the developer experience of using a product, its libs, SDKs, documentation, frameworks, open-source solutions, general tools, APIs, etc.

DX and UX share some principles, but with differences in good practice, this is because developers have different needs in their daily context compared to an average user.
In short, DX is important for the same reasons that UX is important.

Developers who find good DX are happier, promote more, and use their product longer.

This tweet from Nick DeJesus is a gem. He’s well worth a follow.

Developer experience is so much more than using the product itself.

Debugging is part of dev exp.

Documentation is part of dev exp.

Your error messages SHOULD NOT be coming back looking like cryptic metaphors.

I should be able to find what I need in your docs in minutes.

Gitpod has a great podcast about DX, if you’re into audio content.

One recent guest, Kurt Kemple from Forthright, argues that Developer Experience is the new Developer Relations. It’s a really good read.

Developer experience is an event or occurrence within an ecosystem that leaves an impression on a developer.

More RedMonk goodness. My colleague Rachel Stephens just wrote a properly excellent post about DevX helping developers to build more secure applications. Well worth a read, this is definitely an under-considered issue.

If we are asking developers to be increasingly responsible for building secure apps, we have to make it as frictionless as possible for them to do so. We need platforms and software with baked in security defaults. We need to embed principles of least privilege. We need guardrails not gates. We need a focus on usability and speed. We need reduced configuration areas exposed to developers. We need automation. We need developer experience.

One incredibly important aspect of user experience–and one that Kate Holterhoff discusses in relation to velocity here–is accessibility, designing for a wider range of people. Too often DX ignores accessibility. This post from Suz Hinton, cybersecurity developer tools at @stripe – A guide to coding accessible developer tools – is canon.

Just like there is no perfect average end user, there is no perfect average programmer. Every one of us is different when it comes to our abilities, experiences, and lives. But we tend to have the same goals—such as leveraging others’ code when we can, so as not to reinvent the wheel. Every developer wants to write the best tool they can for their peers. They want to make their tools easy to use, help save others’ time, and preserve their cognitive load. They often want those tools to reach as many other developers as possible—and accessibility is an important and integral part of that strategy.

Disclosure: AWS, GitHub, GitLab, Google Cloud, Harness, LaunchDarkly, Salesforce (Heroku), and VMware are RedMonk clients.