What is Developer Experience?

Table of Contents

Whether you’re at a company in the midst of a digital transformation, or a scaling startup, you know that the engineering department is core to business success. In order to retain amazing talent and boost productivity, the most modern companies in the world are focusing on the software developer experience (DX).

In this article, we’ll explain all you need to know about establishing a good developer experience to get ahead of the competition.

Developer experience defines how easy it is for a developer to implement a task whether it’s a change in the system or building something new end-to-end. Optimizing workflow, processes, and developers’ working environment, among other things, can lead to a more meaningful and enjoyable developer experience and more productive devs.

Good Dev Experience = Dev Happiness = Higher Productivity

The SPACE framework, the result of a joint Microsoft and Github research effort, uses five dimensions to examine the many social and technical aspects that shape the developer experience. These five dimensions are:

Satisfaction and well-being: Refers to the state of mind and physical well-being of software developers.
Performance: Describes the outcome of a system or process.
Activity: The quantity of work done, measured in terms of its outputs or actions.
Communication and collaboration: Describes the collaborative process and mutual support that characterizes software development teams.
Efficiency and flow: Evaluates the degree to which programmers can make headway in their projects.

Taking into account these five dimensions within an organization allows for a clearer picture of the areas where the developer experience is lacking. But it is only a framework and not a concrete way to measure DX. More on DX metrics below!

Why Developer Experience Matters

Developers are essential to the success of every company that creates or sells software. True, your clients and customers are crucial. But at the end of the day, your internal customers (in this case, your developers) need to be well taken care of for your firm to succeed. You should prioritize a great DX for two main reasons:

Higher productivity and faster delivery: It’s not uncommon for one development team to juggle a wide variety of systems, dependencies, repositories, platforms, and tools at once. When you have a well-thought-out developer experience, you remove the roadblocks that prevent developers from completing tasks efficiently.
Better business alignment: Once your development team is freed from the burden of cleaning up a sloppy technological environment, they can better focus on improving your company’s key business features, which is where your brand’s ingenuity and productivity really shine.
Employee retention: If the recent Turnover Tsunami taught us anything, it’s that companies that don’t genuinely care for their employees don’t inspire loyalty or better performance. With the cost of hiring and onboarding a new hire plus the loss of institutional knowledge, it just makes more business sense to invest in your current employees.

The Role of Developer Experience Teams

It’s becoming more common for engineering orgs struggling to reach peak performance to invest in a committed developer experience team. DX teams may go by various names, such as dev productivity or platform engineering.

A DX team performs a variety of tasks, including:

Technical documentation: This involves documenting the workflows and processes used by the development team. This would facilitate the standardization of processes and be useful when bringing on new developers.
Choosing tools and programming language: A developer experience team’s job is to supply the development team with everything they require to accomplish their work effectively. They need to ensure the team uses a uniform set of developer tools and programming language that prioritize efficiency and developer productivity.
Improving processes: Good DX seeks to alleviate developers’ burdens by identifying areas where time can be saved, eliminating sources of friction, and streamlining existing processes.

Developer Experience Metrics

As the saying goes: “If you can’t measure it, you can’t manage it.” While measuring developer happiness might give you varying results, there are many quantitative indicators that will help you understand if your developers are overworked or generally frustrated.

Let’s look at 4 key DX metrics that provide insight into the satisfaction of your software engineers.

Work In Progress

Work in Progress (WIP) measures all the branches that are currently being worked on (e.g. in state ‘active’).

Too many tasks open simultaneously can indicate a dev is stretched too thin or struggling to balance multiple priorities. A high number of open tasks forces an individual to context-switch frequently to accomplish their assigned tasks, which leads to cognitive overload and burnout.

Teams should strive to keep individual WIPs under six and average pull requests per team member to no more than two.

Weekend Activity

You can track weekend activity with a metric like active days. Active days measures the number of days during a sprint that a team member has shown activity. This can be commits, comments, or reviews. If your dev is working 6 or 7 days a week, this is an indication of potential fatigue, and that dev might be due for a change of pace.

Pull Request (PR) Size

Pull request size is a metric calculating the average code changes (in lines of code) of a pull request.

The size of a pull request is an indication of its complexity. By chunking your work into smaller sizes, teams are able to reduce the number of bugs in production, while also increasing important delivery metrics like cycle time, deployment frequency, and merge frequency.

The ideal pull request size is fewer than 200 lines of code.

Merge Frequency

Merge frequency is defined as the total number of pull requests or merge requests merged by a team over a period of time.

A higher merge frequency is an indication of a healthy software delivery pipeline and an absence of PR review process bottlenecks that frustrate developers. Optimizing for merge frequency is one of the most important pieces when it comes to creating an amazing developer experience.

Improve Developer Experience

You can’t afford to risk your business outcomes by letting the happiness of your development team suffer. When a developer feels satisfied with their experience, this directly impacts the quality of their digital product. Here are some ways to establish a great developer experience:

Workflow Automation

Repetitive, low-value work can be draining. That’s why you need to replace manual processes with automation whenever possible. By streamlining their processes, developers can focus more time and energy on what they love doing most: coding. At LinearB, we consider this to be the foundation for better engineering. We’ve developed two tools to assist with this.

First, don’t treat all PRs the same. Developers wait on average 4 days for a pull request review, and small PRs that wait for days to be reviewed result in a “Looks good to me” type comment 80% of the time.

gitStream auto-routes PRs based on their characteristics by creating custom review automations for your repo’s .cm file. Some PR’s are just image or docs changes that could be merged automatically; while others are modifications to key parts of the codebase that need review from a subject matter expert or more than one reviewer.

Second, for PRs you don’t want to automate fully, streamline your code review process. Our developer bot WorkerB can help devs save time and reduce context switching by:

Providing context to help devs navigate a growing PR queue and make better decisions
Reviewing and approving PRs with less than 5 lines of code changes directly from Slack or MS Teams

Manage Burnout

As mentioned above, too much WIP and weekend activity is a warning sign. Our Teams dashboard helps you see WIP and active days for your team members. And our burnout indicator will notify you when a team member has worked 90% of the days in a current sprint (starting at day 6).

A key component of developer experience is creating a culture where managers are encouraging their devs to rest and take time away from their work. This reduces the risk of getting bogged down or overwhelmed by a project and allows for some perspective and distance before diving back into a sprint.

The Bottom Line

When it comes to the success of your organization, engineering leaders need to focus on developer experience as a means to retain talent and sustain high productivity levels. In the long term, happy developers deliver better code. That’s why you need to provide a positive developer experience in your organization by considering their perspective and searching for ways to make their lives easier.

Teams who are ready to start focusing on their developer experience today can begin by optimizing for continuous merge: the practice of improving code merge frequency and quality. At the end of the day, developers just want to code and see their work put into the hands of your customers. Using workflow automation tools like WorkerB and gitStream will improve your merge frequency and of course, your overall developer experience.