What Is DevX/DevEx? Developer Experience, Explained

Developers are judged mainly through one lens: their work output. This is understandable, as most tech companies are fast-paced, high-risk, and lucrative. While those factors can inspire productivity and help them build a healthy work ethic, it’s not enough to guarantee consistent, bug-free releases from your developers.

What helps more is the developer’s relationship with work tools, processes, and work environment, which developer experience is all about. Conversations around developer experience involve three key players:

• The developer doing the work.
• The organization the developers work for.
• The companies that build developer products. This includes makers of SDKs, libraries, and APIs and how seamless the working experience of these tools is for their target customers — the devs themselves. This is where DevEx becomes an offshoot of user experience.

Unfortunately, most discussions about DX focus solely on its UX side, while the “employee experience” aspect, equally important, is ignored. That won’t be the case in this article because I’m unraveling both sides of DevEx.

By the end of this piece, you should better understand developer experience, how it affects your entire organization, and practical techniques for making it work for your developers.

(Related reading: developer conferences to attend & DevOps certifications to earn.)

What does developer experience mean?

Also known as DevEx, DeVX, or DX, the term “developer experience” refers to the developer’s relationship with the tools, processes, and practices they use throughout the software development cycle (SDLC). Microsoft defines it like this:

“DevEx refers to how easy or difficult it is for a developer to perform essential tasks needed to implement a change.”

It dwells on how factors beyond the developer’s control impact the developer’s output. Perhaps a better way of thinking about DevEx is as a combination of employee experience and user experience (UX).  Hence, it’s a two-fold concept which treats the developer as both:

• A user of technological products and software that aids innovation and the creation of more software. This is known as the external developer experience.
• An employee who collaborates with other departments, keeps up with existing code and industry trends, and follows the organization’s established working style. This is known as internal developer experience.

In discussing developer experience, questions like the ones listed below come up:

• What tools contribute to a goal?
• What are the existing blockers at every part of the dev cycle?
• Are developer products functional, well-designed, and easy to navigate?

Why is developer experience important?

Developer experience is important because it presents a more holistic way of prioritizing developers' needs, contributions, and the factors affecting their organizational output. As Andrew Boyagi, Senior Technical Evangelist at Atlassian, puts it:

“Companies that focus on developer experience will outpace and outperform their competitors, who will still be trying to work out how to measure productivity.”

This importance comes in the following areas:

Improving productivity

Developer experience addresses issues affecting developer effectiveness, which are small inefficiencies. These include issues like:

• Tight deadlines
• Long feedback time from software tests
• The development environment
• Bureaucracy at work
• Old, bug-ridden code

All these issues cannot be solved by switching to the latest tool in the market and hoping that developers will create magic to improve software delivery. Instead, DX will bring about:

• Shorter feedback loops
• More manageable developer workloads
• The elimination of unnecessary work pressure that leads to burnout and poor software quality

Shortening time to market

By removing blockers in the software development cycle, deployment time is shortened, and releases can happen faster. That means two important things: product launches will go on as scheduled, and features will be updated regularly.

Creating job satisfaction

A positive DevEx creates a working environment where developers are motivated to do their work. It also allows them to find fulfillment in even the challenging parts of their role, which increases their job satisfaction. Plus, their quality output gives them the confidence to do more since they don’t have to struggle with buggy code that requires refactoring.

Reducing employee (developer) attrition

Developers are less likely to leave a company that creates an environment for them to thrive, which is precisely what developer experience is after. Hence, you should expect to see an increase in the tenure of devs in any organization that prioritizes developer experience. Put it opposite: developer attrition will decrease.

Boosting employee attraction

In the labor market, hiring companies can emphasize the positive DevEx that their development teams enjoy. This is a great way to attract the right talents and maintain a pool of qualified candidates who hope to join your company whenever it hires.

“Developers are choosing which companies they want to work for based on the tools they provide,” says John Selvadurai, VP of R&D at Iterate.ai. “Those expecting to hire top-shelf developer talent now list their advanced developer tools as selling points and tout their DX commitments in interviews.”

So, what exactly makes a good DevEx?

Defining a good developer experience

Different factors contribute to defining a good developer experience. In relation to the employee experience, good DevEx happens when the developer can spend more time in the flow state. A flow state occurs when a developer has focused working time — free from distractions like unnecessary or lengthy meetings.

On the product side, that is external DevEx, flow state refers to a frictionless developer journey when working with tools. In general, organizations with laudable developer experiences generally have the following characteristics...

Easy product onboarding and experience

The tools and technology that devs rely on should be easy to work with, especially for first-time users. For this to happen, your devs should have easy access to:

• Good and obvious product support
• Existing product communities that developers can go to for specific hands-on help

Many tech providers, including Splunk, have resources like Docs (technical documentation) and online Community groups for users.

Example of a Community portal, this one for users of Splunk products.

Cross-functional collaboration

Developers don’t work in silos. They rely on others like the quality assurance (QA) team and product managers at different stages of the development cycle. However, this is hardly ever a seamless collaboration, as a GitHub survey shows that 27% of respondents claim waiting for build tests and code review takes up most of their time daily.

So, there must be processes that make communication amongst these teams seamless and fewer blockers that slow down release processes.

Positive rating on DORA metrics

DORA metrics — a DevOps concept — are also used to evaluate the strength of an organization’s DX. These metrics indicate aspects of developer productivity like speed and stability, which are products of a good developer experience.

For example, an elite deployment frequency rate signals that a team collaborates, implements CI/CD, and has an active production environment.

Streamlined processes

Good DevEx is a reality in organizations with fewer repetitive activities and an agile setup. Tim Cochran's description of how a developer’s day that is optimized for effectiveness provides some inspiration on this, as some of the standout points include:

• Short standups
• Fast feedback
• Developer portal
• Up-to-date libraries and any resources that help the developer maintain a flow state and maximize their daily impact

(Related reading: agile transformation.)

Ways to improve DevEx

So, let’s get to the practice side: you want to improve your developer experience — but where do you start? Here are some great areas for jumping-off.

Run a DevEx audit

A developer experience audit involves reviewing the developer's journey with a product. Similar to how the UX design process starts with extensive user research through different methods, a DevEx audit should involve a developer survey to get feedback on your developers' needs, which may differ from what experts claim will work for every developer.

Many companies make the mistake of optimizing their DevEx according to how FAANG or Fortune 500 companies operate. Apart from the apparent budget difference that will make implementation near impossible, the customers, vision, and infrastructure/legacy code differ.

Our point? Work according to your organization's and your developers' needs, and avoid following trendy techniques that will not yield the right results.

At this stage, you should be able to accomplish the following:

• Uncover issues with your product’s usability.
• Figure out the fastest areas of impact in an organization.
• Highlight recurring issues that cause developers to file support tickets when using your tool.
• Point out blockers to your developer flow state, such as context switching, long feedback loops, faulty software, and poor communication with other teams.
• Identify points of friction in the developer’s journey, which will improve product adoption.

For all these, you may need to employ the service of a developer advocate consultant or even a developer audit service company.

(Related reading: UX metrics to know & the double diamond design process.)

Provide product documentation

Product documentation is the first point of contact for new product users, but its goal is defeated when it is unclear and filled with unnecessary jargon. Avoid this! Instead, you can offer different types of documentation to your users based on what they need and make them simple to understand, easy to navigate, and specific enough for an audience or purpose.

This document should always be up-to-date as new features are added to keep users engaged.

A pro tip for creating concise user documentation is to automate many tasks in the software so the documentation is less of a chore to dig into — meaning users can be onboarded in less time.

Set up a DevEx team

Since DevEx is not a once-and-done thing, you may need a dedicated team to make it happen, which is where a DevEx team comes in. Such teams can consist of:

• Developer advocates
• A developer experience engineer
• Other developer relations roles dedicated to prioritizing the needs of your developers

Together, they’ll be responsible for creating a developer portal, ensuring the adoption of DevEx tools, and resolving developer issues.

Implement DPE: developer productivity engineering

StackOverflow’s survey of thousands of developers confirms that Developer Productivity Engineering (DPE) principles contributed to the overall DevEx in the past year.

Some critical components of DPE are:

• Automated testing
• Regular evaluation and improvement
• Continuous integration and continuous delivery

Create an ideal development environment

Investing in the individual experiences of your developers by creating an optimal environment for coding and collaborating matters. So, consider:

• Reducing workload for your developers as much as possible.
• Having fewer meetings and shorter review times to prevent frequent context switching that interrupts the flow state.

Adopting developer-centric tools and frameworks. An example is Ruby on Rails, which, as this Reddit user describes, “offers tools that will improve the experience of writing software compared to a bare PHP app.” Some companies go as far as creating their own DX platforms, as Atlassian did with Compass.

The SPACE framework also offers a more wholesome approach to developer productivity, which will boost developer experience.

Developer experience is critical to quality software delivery

Think of developer experience as the cockpit of your plane, with your developers as the pilots driving your organization forward through software development. Just as a pilot must navigate through the dashboard with different elements that must be responsive, intuitive, and reliable, the developer faces the same predicament — this time through the tools, documentation, and workflows they deal with at work.

The right environment provides multifold benefits, chief amongst which is quality software delivery, which advances organizational goals, reputation, and the entire ecosystem.