All developers know that a poorly working development environment can hinder productivity, even to the point where it gets hard to get anything done at all. And although this is well known, it does not seem to be a topic for many teams. Usually because that’s just the way it is. Or when issues are recognized the teams are too swamped with building features and fixing stuff.
What is Developer Experience?
The stability of a dev environment is just one element of a broader topic that affects developers in their work. All things that determine how hard it is to do a software development job are part of the Developer Experience (also called DevEx or DX): processes, tools and other software in the ecosystem.
This effectiveness also directly influences developer happiness and vice versa. Working on software where every step of the process is painful will not yield happy devs and definitely not increase productivity, which in term drains more energy and takes away focus. Modern software development is already quite complicated, and a bad DX only increases the cognitive load making you less effective.
But DX is not only important in your own team, it is also important if you build software for other developers by building API’s, packages, templates or whatever artifact that other developers consume.
The quality of your documentation and examples, how easy to use your API’s are, the way you communicate, how quickly you respond to questions and requests all influence the DX of others.
Examining your current DX
To start exploring the state of your current DX you can look at common tasks that developers perform in order to build and maintain the software. For example, can you identify friction in:
- checking out and building solutions
- debugging
- running solutions locally
- adding or changing code
- running tests
- running (CI/CD) pipelines
- deploying new versions
- building a greenfield service or solution
Let’s say you are working on a web application. A bug is assigned to you, and you need to investigate and fix it. Many factors will have an impact on your developer experience. Can you easily determine the version of the application in production where the error occurred, and can you check it out quickly? Is it easy to spin up the application and debug it? Are there unit or integration tests that cover the area where the issue might occur, what is the quality of the tests? Is the machine that you work on fast enough? And if you finally find and fix the issue, how hard is it to create a pull request, get it reviewed and shipped to production?
Friction in one or more of these steps will quickly add up and ruin your developer experience.
We can get used to a suboptimal developer experience if we work a certain way for a long time, so a great moment to check the state of your current DX is when a new team member is onboarding. How quickly are they up and running, do they need a lot a help to get started, is the documentation adequate (if there’s any at all), how quickly can they ship their first code to production, etc.
It’s essential to get input from the entire team, as DX can be subjective, especially when teams consist of developers with varying levels of experience: a more senior member of the team will need less guardrails than a junior.
Improving the DX
Where do we begin when we want to improve DX?
First and foremost: communication and collaboration are key. Talk to the other devs in your team but also to teams you interact with. Discussing problems and irritations but also things that do work. like better tools and workflows, are great ways learn and uncover areas to improve. This improvement should be continuously and can be part of the regular agile feedback cycle.
In general, we should look out for any unnecessary administration and manual tasks. Automate tasks that are time consuming and / or frequent.
We can identity a few areas to look into when improving the DX. Note that this list is by no means exhaustive.
Tools
The developers in the team should have good equipment. Software development is a resource intensive task and slow machines directly impact productivity and frustration levels. Waiting for a debug session to start will break flow.
Machines should be kept up-to-date, not only for security reasons but also to keep differences between team members’ environments manageable.
Keeping differences manageable is also important when it comes to tools and IDE’s. By having a standard IDE and toolset it’s easier to optimize configuration and to solve problems. It’s ok if team members have their own taste in IDE or tools but this should not hinder others.
Feedback loop
A fast feedback loop in all parts of the development (or DevOps) cycle helps the team to iterate and learn faster. Live / hot reload allows developers to make changes while running or debugging and optimized builds reduce wait time between changes.
Fast automated tests can check for issues at various points in the development process, during coding but also during CI/CD. This gives confidence in making changes rapidly in a safe way.
A transparent, predictive and simple CI/CD process assists in getting changes to production safely, fast, often and consistently. This is aided with a branching strategy that is as simple as possible but does support your requirements. For example: if you don’t need to support multiple versions at the same time you might reconsider using Gitflow and look at something simpler, such as Github flow or Trunk Based Development.
In every environment (development, staging, production) you want to have good and easy to access observability and monitoring. E.g., when working with microservices you’ll want distributed tracing throughout your entire system. Without proper tooling developers will have no idea what happens in production which leads to missing vital information in the feedback loop.
Quality of code
Code quality is maybe of one the biggest contributors to a good or bad developer experience. Poorly written or unmaintained code tends to attract more bad code, the software version of the Broken windows theory. When the stakes are high because the application is important or even mission critical, developers even get scared to improve or change things, afraid that the house of cards might come crashing down. So only the necessary features are added (hacked in) and old, possibly unused code, is left untouched: Fear Driven Development. Fixing this is a long and tedious process, which requires many small steps, tests, lot’s of refactoring and even more patience.
The best is to prevent this from happening in the first place. That requires strong technical leadership, a well defined application architecture, enough and good unit and integration tests, good code standards, sticking to standards, consistency in and between projects, a good strategy for updating dependencies and frameworks and many more software development best practices.
Communication
A huge part of software development is communication. It’s both foundational as well as the glue that holds every other aspect together. Teams that communicate well generally perform better and have more trust in each other.
Sharing information and discussing problems should be a regular routine to make rapid changes possible. Scrum and agile teams usually have a daily stand-up meeting where they discuss progress and impediments, but it’s not intended for in-depth technical topics. This can be resolved by planning a short daily optional meeting just for the developers where there’s room for sharing ideas, problem solving and decision making. By having an opportunity to do this on a daily basis topics can be handled whilst they’re still ‘fresh’.
Another essential (but unpopular) tool is having a developer wiki. The wiki compliments readme’s (in code repos) by documenting common team practises, onboarding information, the teams way of working, overarching concerns, code standards, architectural overviews, processes, etc. A big challenge here is to maintain the wiki and keep it updated. This requires a lot of discipline and effort, but it is arguably almost as valuable as your code itself.
Culture
Culture is a broad topic, but it definitely impacts developer experience. As you might have noticed, DX and practices to improve it are closely related to modern development and DevOps culture. A developer experience tends to improve in a culture where learning and growth are central. In such a culture mistakes can be openly discussed without blame. A great example of this is the blameless postmortem in which the focus is on uncovering the root cause of problems without finger pointing. Punishing individuals or teams for mistakes erodes trust and will cause people to hide issues in fear of consequences.
To conclude
A good DX is not easy to achieve but it’s fundamental for a highly effective team. It reduces friction, frustration and cognitive load which leads to higher productivity and happier devs. It starts with being aware of what impact DX has, good communication and taking small steps in the right direction.