Happy developers can cause happy customers

In my experience at twoday, happy developers lead to happy customers – and that great software starts with a great experience for the people building it. 

In this post, I’ll share my own experience with ensuring continuous quality deliveries – not through checklists, testing rituals, or daily standups, but by focusing on something more fundamental: Developer Experience (DX).

What is Developer Experience?

The Developer Experience, or DX for short, is the sum of all interactions a developer has with the dependencies of getting work done. Think of the process when you are assigned a new task. Is it easy for you to find the starting point for your changes? Can you trust that you are marking the correct components for a new release? Do you have the tools available to test your changes and ensure that they don’t introduce side-effects in other parts of the system? How much manual labor is involved for you to get your committed changes deployed to production? 

It is similar to User Experience, but for programming. It’s all about the ease and flow of the daily grind. 

Think of velocity, quality and the joy of every day-to-day development activity. 

If you are interested in a long read; Developer Experience Lab[1], a joint Microsoft and GitHub research initiative, has published a study named DevEx in Action: A study of Its Tangible Impacts[2], where the conclusion was that improving and measuring developer experience will lead to happier and more productive developers, stronger teams, and more successful organizations. 

Core values of great DX

Self-service tooling: each one can set up their own localhost environment using a CLI, the environment is powered by dashboards to show the current state. It should be easy to restart parts of the environment in reaction to development changes and reset the local environment when something goes off the rails. 

Use PRs for education, not nitpicking. A reviewer should ask themselves the following questions: Does this PR grasp the key concept of the parent issue? Do I have any input on existing parts of the system that are affected? Is there anything here I could learn for later use? 

Have reliable CI/CD pipelines and fast feedback loops with intuitive error messages when things go south. 

Have clear and searchable documentation with “getting started” guides. A README.md file in the repository root may point to the more advanced topics in other documentation systems. 

Use the documentation hierarchy to explain what you want to tell. Example, think of this structure of sub-pages; “Domain -> Technical -> Development” versus “How do I? -> Start the API project -> using a localhost database”. Which page is easier to find when you look at the document tree and need to find out how to boot a localhost database for your project? 

Celebrate DX wins. DX improvements are just as good internal demo material as new features. 

Why DX matters 

Software development works like a large freight train. It takes time to get the train up to marching speed. When you reach it, you should plan your voyage, curves and brake sections ahead of time to keep that momentum. Unforeseen events that make you pull the emergency brake will cause the train to take long time before it comes to a complete stop. When you are ready to travel again, expect the same amount of time to get up to your earlier marching speed. 

The same principle applies to our brain. Context switches are hard. Context switches take time, and you end up spending more time and energy to reach the same result. A good DX will give the developers fewer context switches, thus higher productivity. 

From a newcomer’s perspective, good DX with fewer hurdles materializes into faster onboarding and shorter time to the first commit. From the senior’s perspective, they spend less time training new hires and free up more time to work on the more advanced parts of your system. Letting people focus on what they are best at ends up with better code having fewer bugs and smoother releases.  

Think of DX as a system concern, equal to performance, reliability, and security. Let new talents become productive quicker, and let existing staff use the time to work with the things they love.  When developers thrive, teams stick together longer – which means deeper knowledge sharing, smoother collaboration, and better solutions.  

"I don't know" is a system failure, not a person failure.  

Uncertainty is an opportunity for innovation. 

Signs of poor DX. Check those that apply  

Outdated or scattered documentation. While some would argue that outdated documentation is better than having no documentation, it can also have negative effects. The usefulness stays as long as the documentation can be used as a starting point to explore deeper. There is, however, a non-zero chance that newcomers in a part of the system will be led down the wrong path.  

Manual, error-prone setup steps that may or may not be executed, depending on if someone burnt themselves hard enough the last time to remember it this time. 

Opaque build/deploy failures. Sometimes things fail, sometimes not. “I have seen that error before, but I have no idea what it means. Just run the pipeline again and I bet it will complete with success.” 

Daily bootstrap, too many siloed tools or custom scripts. “Remember to perform this step when you log on in the morning”. “You need to setup this executable using a script we got from Operations. I have no idea what it does, but B does not work without it” 

Long feedback loop. “We have not set that up locally. You must deploy the development environment and see how it looks.” 

Nitpicking PRs. Usually, a sign of tension between teams or individuals on a team. Reasons may be a lack of understanding of each other’s work or that each side has more than enough with their own struggles. Whatever the reason is, that problem is best solved anywhere else than in PR comments. 

Key DX metrics  

DX is not about intangible values and emergent visions. The core principles of DX can be measured as metrics.  

Time from project start to first successful build that enters production stage. 

Meantime to resolve (MTTR) for developer-facing issues. This is an important metric to be aware of. Remember, we have already been through context switching and the freight train further up this page? Each hour spent resolving issues in the development pipeline equals several hours of lost production. These hours quickly add up and affect your production costs and margins directly. 

Deployment frequency. Less hassle enables the team to deploy more often. Frequent deployments have fewer changes between each deployment. Fewer changes in each deployment means lower risk per deployment. 

Lead time for changes: how long does it take for an approved change request to be visible in production? 

Quick-win improvement tactics  

Have a “day-in-the-life-of” shadowing of new hires. 

Curate end-to-end workflows, golden paths, which enforce best practices by default. 

Automated, one-click environment provisioning with managed secrets and local telemetry. 

Documentation-first culture: documents-as-code and document reviews. 

Monthly retrospectives with blameless postmortems for any obstacles. 

Encourage experimental ideas / hackathons. 

The perfect project   

Improving Developer Experience does not always require huge overhauls. Some of the most effective changes I introduced in our projects were surprisingly simple, yet impactful.  

Don’t spend a month of lessened productivity implementing all these goals at once. Rather, find the pain points in your team and ask not just “How can we fix this?”, but “How can we make this process a more pleasant experience?” and work incrementally on resolving issues as they arise. 

There is a one-click start of the distributed applications and all dependencies. 

Every dependency that is not directly a part of the project can be run in a localhost environment as a clone of the cloud infrastructure. 

Have observability, using well-known industry standards like Open Telemetry, available locally. 

Use PRs as a learning process. 

Linting, security-scans, policy validation are all automated processes that belong in the CI pipeline. 

A commit will be expected to be released soon. Avoid long-lived feature branches where no feedback is gathered in the development process. 

Build an artifact once in the CD pipeline, promote it through stages (dev, staging, production). Allow for rapid rollback. 

Sharing DX Wins on LinkedIn    

It might not always feel natural to share behind-the-scenes improvements – especially the subtle ones. But when it comes to Developer Experience, those small wins are just as worth celebrating as new features or customer success stories. 

Don’t be shy about writing up internal improvements – sharing them helps others learn, reinforces good practices, and builds a culture of continuous improvement. 

 Here are 5 DX wins worth sharing: 

• How we saved X hours per developer per week 

• Cutting handoffs and speeding up delivery by doing Y 

• How Team X reduced time-to-market by 30% 

• Why culture and communication matter in our engineering team 

• X broke again yesterday – here’s how we made sure it won’t happen next time.
  
  

References

[1]: Quantifying the impact of developer experience 
[2]: DevEx in Action: A study of its tangible impacts 

About Oskar Emil Skeide    

Oskar is a .NET software developer with 18 years of experience and a strong interest in automation and DevOps. He joined the company that is now twoday Software Engineering in Ålesund, Norway, back in 2017. Most of his time is spent working on customer projects as a Lead Consultant. Currently, he’s stationed at the Norwegian Coastal Administration, where they develop distributed systems to help ensure safe and efficient traffic through fairways and ports along the Norwegian coastline.