Improving Developer Experience: What You Need to Know

Catarina Gamboa•February 17, 2023

Behind every great software there is a team of developers invested in creating the best experience possible for the users. But what about the experience of the developers behind the curtain? This is where Developer Experience (DX) comes in, to provide developers with the best environment, tools, and processes so they can excel in developing software.

Learn what developer experience is and how it can improve your teams, thus your software, and your business.

What is Developer Experience? #

Developer Experience is related to User Experience (UX) where the end users are the developers.

In a broad sense developer experience englobes everything related to the experience of developers. This experience encapsules every stage of the development lifecycle, from writing code, to testing, maintaining and deploying it, but also can include the collaborations between team members, the way they feel about the job and the product, and the overall ecosystem. With such a broad definition, different views have naturally emerged from different people, as Chris Coyier’s blog post identifies. Some people see DX as the features included in a technology, the APIs they provide, the hooks they have, their integrations with other systems like editors (IDEs) or interfaces (CLI), etc. Others look at the systems surrounding the technology, using documentation, demos, videos to get to understand new systems. And there are also those who  look at a higher level of how to improve developer productivity and reduce the time wasted in meaningless but necessary activities.

All of these aspects have gained interest in the last few years and companies have started to address them. Even so, new positions have come to light as Developer Experience Engineer (DXE), and all Developer Experience Teams, dedicated to the experience of programmers whether they work within the organization or are consumers of company products.

Why is Developer Experience Important? #

Developers are the backbone of software companies, and nowadays we are surrounded by software. From the moment we wake up to the moment we fall asleep, software is everywhere and if we want to have good quality software we need developers at their best. To software companies this is even more important since their whole business relies on developers’ work. As mentioned by Abi Noda in DevXPod, a podcast related to developer experience, developer productivity can be seen as an output of developer experience - “If I were drawing a flow chart, Developer productivity would be the output, so I would draw a line pointing from developer experience to developer productivity”. Moreover, good DX also increases developer retention, since developers feel they are successful in their roles in the company, and by improving developer productivity, the company’s efficiency will also increase. This result was also attested by a recent study from University of Victoria that found that “developer experience drives productivity, engagement and job satisfaction”.

DX has been gaining traction both in academia and industry, with the first side aiming to understand the principles behind DX and the latter showing how they have been using it in practice. New conferences, podcasts, and blog posts on the subject are being posted frequently, and a developer community has been forming. All of this shows that although DX might be a new topic to many people, it is very relevant, and it is beneficial to be aware of it and invest time to understand it.

Dive into DX #

It is essential to first understand the different connotations of developer experience before improving it inside your teams.

As a conceptual framework, Fabian Fagerholm and Jürgen Münch (2012), denoted three main dimensions of developer experience: cognitive, affective and conative. The cognitive dimension relates to how developers perceive their development infrastructure on an intellectual level, what tools they use, what are the frameworks and the workflow that should be followed. The affective dimension relates to the way developers feel about their work, which includes social aspects like respect, relations within the team and their superiors, work environment, sense of belonging and attachment to the company and the products. The last dimension, conative, relates to the developer’s purpose, the value they see in their contribution, their alignment with the activities and their motivation and commitment. These three dimensions aim to synthesize the angles to which we can look at developer experience.

Similarly, there is an advisement for a 360-degree perspective on developer experience that “includes culture, community and processes that make the engineering team work together effectively”.

On the side of development infrastructure there are many decisions to be taken into account throughout the software engineering process to make it as easy and smooth as possible.

For example, before defining all the tools that the team will work with it can be helpful to look into Software Development Kits (SDKs) that integrate these tools for the different stages of software development. Finding continuous integration and continuous delivery (CI/CD) techniques that automate and fit into the development process is also extremely important. Overall, there are countless SaaS that can be used, so it is important to choose a SaaS that integrates better with the overall development process and that improves Developer Experience. Similarly,  DevOps, which integrates software development with IT operations, can also be improved with automation and the right choices of tools/processes. Within this long development pipeline, it is also important to check the bottlenecks that hinder productivity and negatively impact the project and the company.

Moreover, it is crucial to understand your developers’ journeys with a given technology from the moment they discover it to the moment they are able to scale it to fit their purposes, as shown in the book Developer Relations. For each technology or tool selected it is necessary to detect if they are appropriate for a given functionality but also it is also crucial to consider their usability and aim for a smooth and optimal developer journey.

On the affective and conative sides, there is a need for a more of a human approach. As reported by Nick Mills from CircleCI there are many opportunities to improve developer experience. For one, it is important to understand what are the productivity killers that inhibit the developers’ flow. For instance, they might have many distractions with constant email and slack notifications or maybe there are too many meetings throughout the day that take time away from high focus exercises. Additionally, it is important to consider what are the most interesting problems to solve, since they are the ones that motivate developers, so less interesting tasks, like updating plugins or fixing versions, can be automated. Giving meaning to the work is also crucial and can be achieved by getting programmers closer to the end customers to show them the value they provide and the difference they are making in someone's life.  Bring the buying decisions and the leadership closer to the engineering team to make engineers feel valued and heard.

Improve DX in your Team #

A company that is concerned about developer experience values their collaborators. Roles focused on DX are great ways to ensure that this topic is not forgotten. However, any team can improve by taking the time to think about DX, question the current processes and ponder on the possible ways to improve their workflow.

The process of developer experience should be both proactive and reactive. Proactive to try to anticipate the needs of the team, the best tools, and processes to use. Reactive to understand what is impeding the processes and figure out how to solve the issues that arise along the way.

Researchers have proposed An Actionable Framework for Understanding and Improving Developer Experience based on an Ask-Plan-Act process. Starting with asking which are the needs for improvement by gathering developers feedback, then planning the improvements that need to happen on different levels (individual, team and organizational), and finally acting in continuous small improvements.

Therefore, at the start of a project or a process with a larger project, consider asking yourself:

• What are the right tools? - sub questions include which programming language fits the problem the best, which frameworks interact best with the remaining system, which developer tools should be included, are there any apps that improve the workflow. Instead of using your preferred tools, think about which ones would benefit the project and the team.
• Which style of collaboration should the team follow? - maybe the first instinct is to follow the same style as used before but different projects might have different requirements and those can even evolve with time, so understanding the project helps choosing the best way to interact within the team.
• How will the team communicate? - Find the best way to reduce distractions while also bringing attention to pressing issues.

After making the initial decisions about the tools, processes and environment, the team will start working on the given project. However, you should keep an open mind to change processes and incorporate new tools and technologies as well as new procedures in the course of the project.

Hence, during the development process it is important to iteratively:

• Understand what can be improved;
• Implement the improvements;
• Check if the implementation improved the initial issue.

To understand what can be improved, feedback from developers is very imperative. Besides this feedback, other techniques, as suggested by Cirpo, include monitoring topics on main engineering channels from communication tools (e.g., slack), present surveys to developers, gather data from github at an organizational level and monitor software life cycle.

Probably not all the reported issues can be tackled at once, so after deciding which ones should be worked on early, it is necessary to devote time to fixing these issues. This part might be easier when a DX team is in place, otherwise developers might switch their focus to these issues instead of focusing on their actual tasks.

After improving the issues, it is necessary to measure if the changes were meaningful and use the feedback from developers to see if the process led to a positive developer experience. However, the observability of these improvements can be a challenge. One possibility is to use the available data and inspect if the new implementations have the expected improvements, and use this feedback loop into the next iteration until reaching great DX. To measure the overall development experience, it is also possible to use evaluating metrics like DORA or SPACE, or try to apply metrics for user experience, as proposed by Albert Cavalcante.

Conclusion #

Developer Experience enables developers to reach their full potential and feel good at their jobs. We should aim at creating the best environment possible, a development team that feels accomplished while also helping in the developer’s journey to become their best selves.