The Importance of a Great Developer Experience
In February 2012 I began working for a new company. On my first day, I deployed to production. I was lost for words. It felt like magic. Every day was the same: pick the highest priority item, implement it, and then deploy to production immediately. After 6 months, I was still pinching myself.
The experience for me as a developer, the Developer Experience (DX), was energising and motivating. Instead of fighting against processes to get my job done and get my code into production, I felt like the red carpet was being rolled out for me.
As a result of the great developer experience me and my colleagues enjoyed, the benefits to the business were tremendous. The speed at which new features got implemented, and importantly delivered to production for customers to benefit from, was as fast as humanly possible. And instead of waiting weeks for the next release, bugs in production got fixed in a couple of hours.
Not only does a great DX enable people to become productive quicker and build better products, a great DX is an excellent retention strategy. People will want to stay at your company for longer if they aren’t burnt out fighting against the process just to do their job.
The Elements of a Great Developer Experience
A good DX frames developers as customers and considers the journeys they go through as they build products for the company. Every step in a developer’s journey is an opportunity to improve their experience and improve the performance of the organization.
Pleasant Onboarding
Joining a new company is a time of optimism and positivity. For many developers, the positivity drops away instantly and they start to question their decision to join the company as they begin the onboarding process.
Getting access to the relevant tools then getting all the necessary permissions is usually frustrating and full of delays; chasing up people who grant access to projects in Jira and Confluence and then pestering them because they haven’t given you the correct access. Then there is the struggle of getting your development machine set up so you can actually be productive and write code. In some companies this takes weeks.
Back in 2012, my CTO was passionate about “every developer pushing [meaningful] code to production on their first day”. This implied doing it from their own machine and having access to all of the tools required to do so. This should be every CTO’s goal.
Zero to Production in 1 Day
If there is one aspect of DX that is more painful than onboarding then surely it’s getting a new service/application into production. The number of grey hairs on my head increases just thinking about the struggles I’ve faced trying to get code into production environments.
The contrast between a good DX and poor DX for getting new services into production is astronomical. In companies with a strong focus on developer experience, it is possible for developers to create a brand new application have it deployed all the way to production in 1 day. In companies with a poor DX, it’s weeks or months of agony.
When I say all the way to production in 1 day, I mean using a robust and secure deployment pipeline that bakes in quality and compliance requirements, to the same standards as any other application running in production. Developers have a slick paved road which provides almost everything they need out of the box.
Getting to production in 1 day is not always possible. You might want to have a pen test or peer-to-peer check of any new service before it goes live, and that can delay things. But technically, that should change very little. Everything should be automated and ready to deploy to production at the click of a button once approval is granted.
Recommended Reading: From zero to production in sixty minutes: Building a cloud platform for product development.
Self-service Over Blocking Dependencies
Life can be frustrating as a developer when you are constantly blocked, awaiting people outside the team to provide you with a service such as spinning up infrastructure, providing access to some tool, or installing software.
A good DX removes the frustration of being blocked, and prevents friction between teams, by providing developers with a self service experience. Self-service can be implemented in many ways, using tool’s like Backstage or by taking a GitOps-based approach.
Self-service can also be implemented by giving teams, or senior people within a team, the ability to perform tasks themselves like admin permissions in Jira and Confluence.
Red Carpet for Continuous Delivery
If you want to build a high-performing engineering organization, make it as easy as possible for developers to continuously deliver value for customers. Roll the red carpet out and give developers all of the tools they need to develop, deploy, and support applications in production.
HMRC, of all places, had an excellent DX for continuously delivering applications all the way back in 2015. As a development team building on HMRC’s MDTP (development platform), you get a wealth of libraries, tooling, and operational support like metrics, monitoring, and logging all out of the box, enabling you to focus on delivering your team’s core value proposition.
Platform Engineers at HMRC would analyse continuous delivery metrics across all teams and share the practices from the highest performing teams and provide dedicated support to helping teams with lower deployment trends.
As a developer, this is exactly what I want. I want the organization to give me all of the tools, support, and encouragement I need to deliver value for customers as quickly, frequently, and safely as possible.
Delightful Local Development Environment
Naturally, developers spend a large amount of their time using their computer to build software systems. When the DX is great, a developer can focus on solving business problems and seamlessly perform the relevant tasks. When the DX is poor, a developer hates opening their laptop and spends all day fighting with it and wanting to throw it through the window.
A developer should be able to install the tools they need to do their job. They should have powerful machines and peripherals that provide an optimised, comfortable experience. They should have access to all of the necessary resources for building applications and gaining the knowledge they need (e.g. Stack Overflow).
Penny pinching on developer equipment is far too common and makes no economical sense. And it sends totally the wrong message. Providing developers with the equipment that makes them productive and removing every impediment that inhibits them form doing their job sends a very clear message: we trust you, we value you, we want you to enjoy working here and solving problems for our customers.
Learning & Sharing Community
Being a software developer is a very privileged career. It’s a highly creative job; using the latest tools and technologies to solve new and novel problems. Discussing tools, technologies, and problem solving approaches is exciting to developers. It’s why we love our jobs.
A good DX makes learning and sharing a part of a developer’s daily life. There are communities inside the company, there are discussion forums for discussing the latest tech news, and there are regular events and internal conferences to discuss and share ideas.
Some organizations have an extremely poor learning and sharing DX. Developers work in silos. There is no encouragement to learn and share. There are no digital channels or in-person meetings for people to communicate. Good developers do not want to work in this kind of environment.
How to Create a Great Developer Experience
It’s easy to talk about a good DX but I do recognise that is hard to achieve, especially in some types of organization. However, there are fundamentals that all companies can put in place to begin the journey to a better DX.
Measure Developer Experience
One of the key steps to improving DX can be to measure it. Some things are easier to measure like deployment frequency, time-to-production for a new service, and the number of tickets developers create for non-self service tasks. Other aspects are harder like local development environment satisfaction. In those situations, use surveys and speak to developers.
Invest in Developer Experience
Developer experience is unlikely to improve just by a CTO announcing at a meeting that everybody needs to work together to improve the DX. The company needs to invest: invest in platform teams to build self-service infrastructure and tooling. Those teams should be as customer-obsessed as any other team in the company, and developers are their customers.
Set out a Vision
When DX is poor, it’s hard for people to feel that things are ever going to change. DX can be seen as yet more buzzwords and empty talk.
I find that setting out a vision can help. The vision needs to be precise enough that it feels real, and is not just fuzzy aspirations. For example, explain in the vision that the goal is to have new services all the way to production in 1 day, and provide examples of how it could work.
The most important thing is to keep making progress towards the vision. Think big, start small, and keep improving.
