Introduction

As developers, we spend a lot of time creating user experiences (UX) that provide value to our customers. Ideally, these experiences are so good that people want to keep using them. Like customers, developers also appreciate when the products they work with are reliable and easy to use. Think about it - in an age of APIs, developer tools, and developer platforms - you want to make it easy for developers to find the right path to success. Put another way, developer experience (DX) can impact customer experience. DX provides an early opportunity to those building development products to set the developers (and their customers) up for success. After all, developers are users too and are significant drivers of business value.

Like consumer products, we want developer experience to be good enough that developers keep using our tools, building on our services, and relying on us to help power their stack. This experience has to be positive. When we think about UX, it's often in the context of completing a user task (e.g., sign-in, add-to-cart, search). With DX, it's a little different. When developers are presented with multiple similar development tools, they will likely evaluate them based on various parameters. It's about the usability of APIs, documentation quality, estimated development speed, production readiness of the platform, their understanding of the architecture, maturity of the ecosystem, and the ease of debugging when things go wrong.

During my time at Google, we've had to think about the design of DX for our Developer Tools, APIs, and services. I've been closest to this through our work on the Web and Chrome. This has taught me that through DX, we need to think about not only how developer products will enable solving problems for customers, but also how they'll help developers solve their development problems. After all, developers are users too and are significant drivers of business value.

DX is a really fascinating field that is still evolving. Similar to UX, there often isn't a one-size-fits-all set of ideas that will apply to every situation. That said, in this book, we hope to share a few ideas on how to think about DX, its relationship to UX, and other related aspects such as developer productivity. We hope you find it useful!

Definition

Let’s begin with a definition.

Developer Experience (DX) is all about how easily and effectively developers can get things done. It is the experience developers have when using tools and services to analyze, build, test, integrate, deploy, and maintain software.

Developers use different tools, interact with people, and participate in various software engineering processes daily. These interactions leave diverse impressions of their work environment and the tools they use. DX is the aggregate of how developers perceive their work environment and how they are affected by it in turn.

Good DX is reflected in clearer thinking, greater productivity, and enhanced efficiency among developers. It boosts the speed at which developers can work and aligns closely with business objectives. DX design involves crafting tools, APIs, and workflows to provide an exceptional experience for developers.

• Don't underfit. Don't overfit.
• Make errors your priority.
• Embrace the fundamentals.
• Make it for everyone.
• Make it timeless.
• Make it fast.
• Market it.

Source: Guillermo Rauch, CEO of Vercel

Let's get on the same page

Terminology

Here is a glossary of terms we'll be using in the book for quick reference.

User experience (UX)

The overall experience of people using a product, system, or service based on their perceptions of its utility, ease of use, and efficiency.

Developer experience (DX)

The experience developers have while using tools and technologies to analyze, build, test, integrate, deploy, and maintain software. It is UX for users who are developers.

Developer satisfaction

The extent to which developer needs and expectations are fulfilled when working in a specific job role and towards a particular goal.

Developer productivity

The ratio of work done by a developer or team as compared to the progress made towards achieving the business goal, such as advancing the overall quality of user-experience to drive more conversions.

Developer success

The result of anticipating developer challenges and proactively providing solutions and documentation to help them be successful in their roles.

Developer journeys

The sequence of steps that developers follow to accomplish something using one or many products and their interactions along the way.

Why do we need DX?

To ensure that developers who use products are productive, satisfied, happy, and contribute to their organization's overall success, we must equip them with products that provide a good developer experience. Unsatisfied and unhappy developers will give up on the products they are using and look for alternatives. Quality DX is no longer optional - it is necessary to remain competitive.

An example of good DX

A good error message identifies the problem, the cause of the error and the solution. In this case, Next.js identified the problem with this application building (an issue with prerendering a root path), the cause of the error (the path not matching /[...index]) and links to a doc outlining the solution. This is a good example of helpful DX that aims to help unblock developers.

From Wix UX, this is another example of a good error message. It explains the problem (what happened and why), provides reassurance, is empathetic, helps the user fix the issue and gives the user a way out (solutions).

Good DX is important because of its relationship to usage and adoption. A tool that provides good DX increases productivity and satisfaction for its developer users. Developers are likely to adopt it themselves, grow with it and recommend it to others in the community. DX is critical to the success of any product used by developers.

Developers who experience a streamlined development workflow due to good DX are more likely to build better, well-designed products with fewer issues. Thus, good DX can ultimately contribute to a great UX and happy end-users.

Developer Experience (DX) focuses on understanding developers, what they need, what they value, their abilities, and their limitations. Good DX is crucial for developer-facing products because it can affect developer and business performance.

What makes a great developer experience?. Let's start with frameworks and libraries. To keep developers in the flow, you want to enable them to get started as quickly as possible. Optimize for fast iterations and feedback loops to the developer.

Upgrading should be easy.

• Limit the "blast radius" of changes to make it easy to upgrade dependencies
• Make large changes opt-in with months of lead time before landing in a major version
• Include scripts to automatically migrate code and fix issues (codemods)

Write helpful error messages.

• Include hyperlinks in error messages with more context on how to solve the error
• Provide feedback as you type (e.g. type checking, linting) before runtime or compilation errors can even occur

Have strong defaults + escape hatches.

• Have an opinion about the right way to build software
• Make it easy to break from the standard config without having to fully eject

For example, framework defaults (routing, data fetching) + ability to customize (extend config).

Source: Lee Robinson, VP Developer Experience at Vercel

Productivity and Job Satisfaction

Research suggests that unhappy developers can be bad for themselves, the process, and the product they are building. Unhappiness can lower cognitive performance, cause deviations from process and cause delays in process execution, thus reducing the productivity of developers. Deviations in the process can also affect the quality of code. One way of maximizing happiness amongst developers is to minimize negative experiences when developing software.

Negative experiences can result from social and technical challenges when following processes or using development tools. Clear goals, well-defined processes, valuable and easy-to-use engineering tools reduce friction and create positive experiences, thus contributing to developer happiness and productivity.

There is a bi-directional relationship between developer productivity and job satisfaction which is also influenced by other social and technical factors and challenges. The following illustration shows that engineering tools and systems affect both productivity and job satisfaction.

Source

In extreme scenarios, developers with lower job satisfaction would give up, quit and look for a job elsewhere, thus affecting team morale and productivity. Improving DX increases productivity and job satisfaction and also helps engage and retain employees.

Developer Tools and Productivity

One of the key factors affecting productivity in relation to engineering tools is their performance, more specifically, their iteration latency. Software development is an iterative process. We submit the first version of code and keep updating it based on the feedback from the compilation/build/test process. With slow development tools, the feedback (e.g., compilation errors) may take time to generate.

Developers may get distracted at this time or be tempted to switch to other work while waiting for the tool to respond. Frequent context switching can affect the focus, which is essential to cognitive abilities when engineering software. Similarly, tools that are too difficult to understand also require context switches, as developers will have to learn how to use the tools before going back to their original task. With such tools, developers may be more risk-averse to making changes or iterating on the code to make it more efficient, robust, or readable.

Good DX typically looks like this...

• You try for the first time, and you're able to do a hello world quickly
• You see an error, and you're able to fix it yourself
• You can try something without adding a credit card
• You use an API, and it has all the params you need

In contrast, bad DX looks like this...

• You try to install, but it doesn't work right away
• You read the docs, but it doesn't contain what you need
• You try to use, but it requires a "demo" or "call"
• You try to integrate, but there's no SDK for your stack

Source: Zeno Rocha, Founder & CEO at Resend

DX and Business Performance

McKinsey and Company studied the impact of developer productivity or velocity on business performance using a metric they called Developer Velocity Index (DVI). DVI helps to differentiate the most critical factors in achieving Developer Velocity. Among the 440 companies surveyed, the study shows that top-quartile DVI scores correlate with 2014–18 revenue growth four to five times faster than bottom-quartile DVI scores. These businesses also score higher on customer satisfaction, brand perception, and talent management.

The study also found that the four key factors impacting business performance are tools, culture, product management, and talent management. Tools with the most significant impact include software used for planning, collaboration, development, AI assistance, DevOps, and other low or no-code tools.

Source

The companies that have mastered Developer Velocity focus equally on empowering the developer, anticipating critical enablers, aligning investments with customer value, and minimizing barriers to productivity. The study shows that best-in-class tools are the top contributor to business success—enabling greater productivity, visibility, and coordination.

A Forrester Opportunity Snapshot highlights the need for improved developer experience (DevEx) in order to boost efficiency, productivity, and business performance. The study found that the vast majority of respondents (87%) cite increasing developer productivity as a top priority for the next 12 months. However, several obstacles stand in the way, including challenges with onboarding and training due to the pandemic's impact on distributed workforces. The study shows that Internal Developer Platforms (IDPs) can help overcome these barriers by enabling true developer self-service and reducing reliance on ops teams for basic needs.

Importantly, the research demonstrates the potential bottom-line benefits of improving DevEx. As a result of better DevEx, respondents report increases in developer productivity (74%), faster time to market (77%), revenue growth (85%), customer attraction and retention (75%), and customer satisfaction (82%). With smoother and more frictionless developer experiences, teams can work more efficiently to ship higher-quality updates faster. To learn more, check-out the report.

Firebase, Vercel and Netlify have largely removed the friction of deploying full sites to staging or production environments through a combination of automation and great CLIs. They make it straight-forward to leverage SSL, CDNs, CI, scale up/down and build on the Edge. By investing in their DX and ecosystem, they've reduced the time developers and DevOps teams may need to spend worrying about deployment.

Organizations with strong tools are 65 percent more innovative than bottom-quartile companies. The ability to access relevant tools for each stage of the software life cycle contributes to developer satisfaction and retention rates that are 47 percent higher for top-quartile companies than bottom-quartile performers.

My principles for Developer Experience

1. Minimize switching contexts: Interruptions matter even when it’s your tools that are doing it. 

2. Remember, you are a chef cooking for chefs: Respect the craft. The bar is higher because you’re building products for people who build products. 

3. Automate anything that can be automated: Automation is king. Any task that can be run in the background should. 

4. Optimize for TTC (time to code): Just as artists need to see paint on canvas in order to keep creating, developers need to see code running in order to test, get feedback, and ship. 

5. Be dependable: Be mindful of breaking changes. People’s services depend on your services.

6. Don’t bury the lede: Don’t hide pricing, don’t use convoluted marketing language, don’t hide the documentation. If your tool is faster - how much faster is it? 

Source: Kathy Korevec, Product Lead at Google building AI DevEx

DX to serve UX

There is often a case made for prioritizing UX over DX. The idea is that in case of conflict UX > DX. The very first AMP design principle states that "When in doubt, do what's best for the end-user experience, even if it means that it's harder for the page creator to build or for the library developer to implement." This is reasonable because UX investment increases ROI.

However, before applying this principle, we must note that Building a great user experience should also be a great developer experience. Let's consider the two types of web developers we usually come across.

1. Those that build tools, libraries, and other products for other developers to use.
2. Those that use the above products to build end-user-facing application software

While good DX is required for both categories of developers, providing good UX to end-users is the primary responsibility of application software developers. So how can the first group of users promote good UX?

Here are some possibilities to consider:

• Good DX will encourage more developers to create and innovate using a particular technology: Humans are likely to keep opting for what is easy and the path of least resistance when building user experiences. That path needs to set them up for success. A clearer story for DX and UX is thus critical. Good DX may increase the population of developers building for platforms, where they may not have otherwise had the time or experience to build anything in the first place.

  Tools for building experiences should ideally be low-friction for developers to use (DX) and enable delivering high value and quality (UX) to users as quickly as possible. If they can facilitate good UX while applications grow and keep maintenance costs down over time, both developers and their target users may win.

• Good DX can enable a decent UX for less privileged users: In cases where developers are our tool users, we should be doing the right things by default. We should better communicate the trade-offs so they are likewise setting their end-users up for success. Doing so ensures UX isn’t just good for wealthy users but also for users at the margins (think the ninetieth percentile) who may not be on the fastest computers or networks. This can make a real difference when the tools used to produce sites and apps are used for important government services, utilities or even social networks. Making life good for users at these higher percentiles is an optimization point that good DX could target, but doesn’t just yet.
• Good DX can create strong defaults to enforce UX: With an improved DX, APIs and frameworks can use strong defaults where necessary to implement best practices for better UX. Developers have a better understanding of how a tool or API can be implemented and customized to provide a better UX for their users. They will know what knobs are available to them and tailor UX according to their requirements. This principle is used in Tiny's approach to developer experience. They believe in providing a great DX so that developers can provide a great UX.

  Organizations that invest in developer tools and libraries that offer great DX enable UX by establishing an environment that purposefully eliminates speed bumps. Such organizations create pathways that encourage developers to apply their energy more precisely on creativity and ingenuity.

• DX may even be reverse-engineered based on UX requirements: In some cases, UX requirements can also be used as a guide for developer processes. For example, when Facebook re-designed facebook.com using a new tech-stack, one of their mantras was "Engineering experience in service of user experience." The idea was to guide engineers to do the right thing by default. They used automation to reduce engineering overhead and the potential for bugs. They had realized that "With great APIs, tools, and automation, we can help engineers move faster and ship better, more performant code at the same time."

Do note that the claim better DX = better UX when building for platforms like the web is sometimes related so heartily that it suggests ignoring the need to invest in UX as a primary concern. The effect is felt most strongly when the authoring and marketing story for tools like JavaScript frameworks or No-Code paint a picture so appealing, the quality of UX output is taken on good faith vs. being measured. Where it is marketed that DX should deliver better UX, we should remember that serving users first often matters most. A better approach to marketing might showcase real-world metrics quantifying the UX and DX gains for production sites and codebases. When in conflict, UX > DX most of the time, modulo resource constraints.

There are often both legitimate DX improvements that can result in wins for user-experience (e.g. better defaults for how code is optimized and loaded) as well as those that can result in accidentally sub-par UX (e.g. solutions that may be considered over-engineered or overly reliant on client-side script) through improving efforts that primarily lower developer friction. While some tool makers may not be acting in bad faith where the quality of UX output is concerned, others may not be quite as noble. One of the good-faith reasons folks bought the argument that better DX = better UX was that we would do better by users. This is the measuring stick we should use when end-user UX is a selling point. Claims of "Faster" and "Better" UX should ideally be quantified in terms of the realized end-user experiences on representative hardware.

Having established that DX should facilitate UX, developers who build end-user-facing software will still have to prioritize UX over DX in case of conflict. For example, prioritizing a fix for a user-facing production issue over refactoring of hard-to-follow code.

There may be situations where UX needs to be prioritized; however, there is no reason for DX to rival UX entirely. Good DX should instead enable good UX for the two types of developers mentioned earlier.

Here is another idea that provides measurement context for the DX vs UX debate.

When we talk about trade-offs for DX and UX, we might mean metrics like: Build time (DX metric), Page load time/PLT (UX metric).

• Running a build with more optimizations will make it slower, but improve PLT. UX/DX trade-off. Because UX>DX we decide to run the optimizations.
• Instead we might introduce separate prod and dev builds and only run optimizations in the prod build. Built time impact is now amortized 0 for DX with zero UX impact. Win-win.
• Another hypothetical example is, build times were slow and consequently devs weren't bothering to polish the apps they were building. We managed to make build times fast while achieving the UX goals and devs are once again polishing their apps. Outcome: - Fast PLT - More polish

Source: Malte Ubl - CTO, Vercel.

Case Studies that advocate DX

There have been numerous instances where changes to web developer tools and processes translated to business value in terms of developer productivity or end-user experience. The following examples briefly summarize what exactly changed for the developers in each case and how it was a good business decision.

Lyft's migration to Next.js

As the number of services in Lyft's React-based frontend architecture grew, they started diverging, resulting in a heterogeneous code base that was difficult to maintain. To address developer pain points caused due to lack of standardization, they decided to switch to the Next.js open-source framework that is opinionated and provides strong defaults. To enable easy migration, they designed a migration service with jscodeshift and a plugin service with Webpack tapable. With 40% of their services migrated, they could already see an improvement of 350 ms in the developer feedback loop from code change to browser. They also saw an improvement in infrastructure code size (10k lines) and bundle size (845 kB).

Bloomberg's migration to TypeScript

Bloomberg engineering decided to migrate more than 10,000 JavaScript apps to TypeScript. Developers usually prefer developing new features over migration projects. However, developers were self-starting conversions and championing the process in this case. The DX principles implemented were:

Scalability: High development speed with minimum time spent installing, compiling, and checking code.

Ecosystem Coherence: Packages work together. Upgrading dependencies is pain-free.

Standards Alignment: Stick with standards, such as ECMAScript, and be ready for where they might go next.

Lineup Ninja's migration to Hasura

When Lineup Ninja, an agenda management software company, decided to migrate their backend from Firebase to GraphQL, they went for Hasura's developer-focused tools to connect to GraphQL. It is easy to get started with Hasura with a short learning curve. Hasura provided real-time GraphQL over Postgres. Lineup Ninja could migrate and have a fully functional production-grade backend ready with very few developer resources on a very tight deadline. Hasura also enabled them to leverage serverless and not worry about DevOps. Hasura's high performance helped them save significantly on infrastructure costs.

Pan Macmillan benefits after migrating to Netlify

Publishing house Pan Macmillan wanted to improve their discoverability and engagement metrics. Their technology team optimized their legacy .NET CMS using Netlify to adopt a modern Jamstack architecture. Moving to Netlify empowered their small in-house team to instantly ship new content and changes while dramatically improving site speed and SEO rankings. Netlify's simple development workflows helped improve development speed and

provided a 650% increase in deployment agility. Site maintenance costs were reduced by 20, and the speed of their sites improved by 8x, leading to better engagement metrics.

Workwave replaces Webpack with Vite.

The UI team at Workwave RouteManager works with a codebase of more than 150K LOC. They found that Webpack was very slow for their code base and developers had to wait a long time for yarn (~2 mins) and app refresh (~25s). This negatively affected developer productivity and DX. After switching to Vite, they observed substantial gains in build performance with faster yarn times and quicker hot reloads of React components. Overall, Vite's performance and DX proved to be an order of magnitude better than Webpack for the Workwave team.

Why did Gitlab choose Vue?

Gitlab chose Vue.js for its JavaScript framework for simplicity and ease of use. It allowed the team to write simple JavaScript quickly. It helped them keep their programming efficient and while managing DOM-related issues. Real-life usage with Vue was as simple as the examples in their docs. Previously, all JavaScript at Gitlab was written in jQuery, and much code was required per use case. They found that with Vue.js, they could immediately and consistently solve complex problems in less time.

Datadog used Temporal to automate database upgrade workflows.

Datadog is a cloud-scale monitoring, analytics, and security platform. The Database Reliability Engineering (DRE) team at Datadog ensures the reliability and continuity of their numerous domain-specific databases by handling dynamic incidents and upgrades. Historically, they would do this manually by collating the required steps and scripts to address a given situation. Temporal provided Datadog with a reliable and scalable solution for managing their database system by automating critical workflows. This simplified processes for Datadog's DRE team, providing them with a fail-safe method for implementing upgrades and managing incidents. This, in turn, helped to minimize downtime, reduce operational costs, and improve the overall reliability of their database system.

Developer Needs

Developer experience can mean different things for different tools.

Developer experience is so much more than using the product itself.

• Debugging is part of dev exp.
• Documentation is part of dev exp.
• Your error messages SHOULD NOT be coming back looking like cryptic metaphors.
• I should be able to find what I need in your docs in minutes.

Source: Nick DeJesus

Changing Mindsets

Enable great DX in organizations

To enable a DX mindset in the organization, we must agree on the answers to a few questions:

• What do developers want?
• What is their ideal for developer experience?
• What are the factors that affect their coding style and efficiency?

Tools and Languages

• Tools, languages, and frameworks that work well together and enhance productivity.
• Autocompletion, IntelliSense, and immediate error messages when writing code.
• Editor support for every language used in the project with features such as Linting and automatic formatting, Syntax highlighting, Look up documentation at the call site, Jump to the definition, Run a test from the editor, Debug executables from within the editor, Third-party plugin support.
• IDEs use the Language Server Protocol to support the above features via interop with a language server.
• Searching code should be fast with support for wildcard searching or finding identifiers, call sites, usages, and other artifacts.
• CPU and memory profilers are readily available and well integrated.
• Dependencies should work reliably, not conflict with system dependencies, and should be fetched if not already present.
• Comprehensive, updated, and well-organized documentation with an introduction, tutorials, how-to guides on solving complex issues, examples of feature use, and FAQs.
• Changelog containing all the updates for each particular version.

APIs

• Well designed, intuitive APIs with clear grammar.
• Self-service, easy-to-use APIs with accessible and expressive documentation.
• A playground to test requests and responses quickly.
• Error messages that clearly hint at why they happened.
• Instant onboarding with a barrier-free sign-up process.
• A free tier to encourage early use.
• Webhooks that send data to a consuming endpoint. The best API-first companies (Twilio, Stripe, etc) offer webhooks as a way to proactively receive updates.
• Clearly defined SLAs, terms of service, and privacy policies for APIs.
• A set of SDKs available for different programming languages.
• A CLI or code editor plugin to test requests.
• A developer portal that monitors and manages API usage handles keys and enables billing and payments.
• Unified APIs that offer an easy way to integrate multiple APIs of the same vertical simultaneously

Dev Environment

• The environment should be such that developers spend more than 90% of their time programming and less than 10% on overheads.
• Open-source repositories should be well-managed using branches, self-contained pull requests, linting, code reviews, and code merging.
• Development tools should support one-click installation with defaults and options to change the configuration.
• Good quality builds, deployment, and operational experience with automation where possible. For example, managing and provisioning of infrastructure through code (IaC).
• Zero bottlenecks to productivity due to infrastructure issues
• Local, test, and production environments should be such that deployed code behaves identically or near-identically on all.
• Easy to test sites across all browsers with similar browser compatibility.

TypeScript, Twilio, VS Code, and Stripe are often mentioned in the context of good DX. Developers seem to like these tools and APIs because they "just work". Based on the inherent qualities of these developer favorites, developer surveys, and discussion threads, here is what we can surmise about developer needs and expectations. (It is a long list but by no means exhaustive.)

Others

• An organization that acknowledges the importance of DX.
• A pace of change in platforms that allows developers to keep up with changes.
• A developer relations team that is committed and provides a face to dev tools and APIs.

The list above covers specific developer needs at a micro-level. In the next couple of chapters, we will show you how to group these needs into seven distinct characteristics that will create a more nuanced definition of DX and enable its measurement.

The difficulty of centering content in CSS has been a meme in the web developer community for years. While Flexbox and Grid have greatly simplified this in recent times, developers still find themselves needing to look up documentation on how to center. The Chrome DevTools invested in support for Flexbox and Grid tooling that makes centering (and more advanced alignment) just a click away. This improves developer productivity by reducing friction to build good page layouts.

When we think about Developer Experience, we have think beyond a single product.

In a Developer's journey, we begin to prioritize the features that are touch points along the larger system.

What I often find is there are gaps between these products where we have to do intentional work to make things feel seamless.

When making those investments, the most common paths can be defaults, while anything the user needs that's more unique can become configurable options.

Source: Sarah Drasner - Director of Core Developer Web, Google.

What makes for good DX?

DX = UX for developers.

User experience is the overall experience of people using a product, system, or service based on their perceptions of its utility, ease of use, and efficiency.

Good user experience (UX) leads to satisfied and loyal customers, and investing in UX can provide a significant return on investment for software products and services. While any experience is about how individual minds perceive the product, some common measurable traits create that experience. In the case of UX, these traits determine if the product is usable, useful, credible, accessible, findable, desirable, and valuable.

Organizations that create products, services, or tools for developers, focus on improving the UX for users who are developers. Hence we refer to it as DX. Thus we have:

DX = UX_Developers

While the contributing traits for DX are similar to UX, their interpretation is different given the more technical and analytical personas of software engineers, the difference in how they interact with tools, and the impact of their work. Some key differences between user and developer processes are:

1. Developer journeys are often longer and more complex, requiring continuous interaction (and often repetition) with the product, while user journeys are considerably shorter—for example, the journey of creating an e-commerce app vs. ordering using the app. Developer journeys are also more complex as other factors such as requirement/design changes or dependencies on other developers and software cause deviations from a set path.
2. A combination of tools is involved in the developer journey and not just a single app. Typically web developers use a server, framework, languages, IDE, and browser installed on their local machine. Additionally, they may use other tools such as third-party libraries, bundlers, test frameworks, performance tooling, and others. These products should work in tandem to reduce friction.
3. New concepts and upgraded tools or frameworks become available regularly, and developers often expect to understand, evaluate and apply them in a relatively short time frame.
4. The end-product created by the developer is likely to affect more people than the result of a typical user using an app for personal reasons.
5. End-users typically go through a solitary experience when using a product. Developers are usually part of a larger team where every team member's perception can affect the overall experience. In other words, it's a multiplayer experience instead of a single-player experience.
6. DX is usually built for users who are experts/professionals at using technology, while UX targets the general population, often people with little technical background.

Optimizing DevEx is about creating a collaborative environment where developers can be their most productive, impactful, and satisfied.

C = Collaboration, the multiplier across the entire DevEx.

GitHub’s DevEx formula takes into account:

• Productivity: how quickly or simply a change can be made to a codebase
• Impact: how frictionless it is to move from idea to production
• Satisfaction: how the environment, workflows, and tools affect developer happiness

Source: Gwen Davis, GitHub Blog

Applying UX Characteristics to DX

Despite the differences between UX and DX noted above, key UX characteristics may be adapted for developers and development tools.

In your research on DX (or UX), you might find a different set of characteristics or hierarchy being used to define core DX principles. The following is an example from the web.

Source: Zeno Rocha - CEO, Resend

Every approach has its merits. For the purpose of this book, however, we will use the seven characteristics discussed previously to guide the implementation and measurement of a DX strategy.

Fundamentals

Why does good DX matter?

Good DX is reflected in clearer thinking, greater productivity, and enhanced efficiency among developers. It boosts the speed at which developers can work and aligns closely with business objectives.

Empowering Writing Excellence

Our AI writing tool is designed to empower you with exceptional writing capabilities, making the writing process...

How do we enable a DX Mindset?

DX is critical for all products where developers interact with tools, libraries, APIs, services, and platforms. The following steps can enable a DX mindset when building and enhancing product offerings.

1. Establish: Define DX vision and principles.
2. Measure: Establish qualitative and quantitative methods for measuring the success of DX methodology.
3. Implement: Understand existing usage metrics for products, pain points, and developer desires through developer interactions and depict them using DX tools such as journey maps.
4. Refine: Create a feedback loop where measurement of DX helps you refine your DX process and improve your DX maturity level.

DX Vision and Design Principles

DX design is about designing high-quality experiences. It involves understanding the context of use, what developers need to complete their tasks, what they value, the underlying technology, integration points, and focusing on how developers feel while using a product or service. The fundamental design principles are as follows:

The getting started experience matters

The developer experience (DX) is a critical aspect of a platform's success, as developers' first impressions can heavily influence their decision to continue using the platform.

A solid "100th day" development experience can help retain developers and turn smaller developers into larger ones. A solid "100th day" development experience can help retain developers and turn smaller developers into larger ones. However, the "1st day" or "1st five minutes" development experience matters the most when attracting new developers. If a developer's first attempt at using the platform takes several hours, it is not a good first impression.

Once a developer has decided that a platform is not for them, it may be several years before they are willing to give it another chance. Developers have choices regarding the platforms and technology stacks they use. Getting started and ramping up on a new platform should be simple.

A developer who can transition smoothly and comfortably from evaluating a platform with a learning project, then move to a toy project, and then on to their first actual project, where they feel productive and progress towards their project goals, is happy. There's been a wealth of thinking into how DX should be considered through the lens of Developer Relations at Google, including some excellent points made by Fred Sauer, which we'll discuss below.

Creating great experiences

To enhance the developer experience, it's crucial to consider both the advantages of a platform's features and the time and effort required to start using it. To achieve this, it's essential to deliver value as quickly as possible, minimize initial expenses, and smoothly spread costs over time.

To accomplish these goals, it's essential to work on two fronts: enhancing the potential value of features while reducing the developer ramp-up time. Additionally, it's important to consider the timing aspect, guaranteeing that the platform delivers value early on and reduces initial costs. This strategy will attract more developers to the platform and increase its chances of success.

Providing value

To provide value to developers, offering a platform with little friction and whose costs and benefits can be paid down and reaped in small, gradual increments over time is essential. This will help create a positive developer experience that ends with a productive developer familiar with the platform and its tools.

To achieve this, it is necessary to focus on increasing the potential value of the platform's features while also keeping costs low and gradually moving developers along through the platform. This will help to create a continuous net positive developer experience that keeps benefits ahead of costs.

First principles

Based on this discussion, the following is a list of first principles that could help to get started.

1. The developer should be in control. To create a great developer experience, giving developers control over their experience is essential. This means allowing them to dictate the pace at which they proceed and providing them with the resources and guidance they need to learn in the way that best suits them. It is also important to ensure that the developer is always in control and never required to take an unexpected or unnatural action. Progress should be prioritized over compatibility, but compatibility should also be addressed. Additionally, developers should be able to use the tools and languages they prefer unless there is a compelling reason to do otherwise. Overall, the goal is to create an experience tailored to the individual developer, allowing them to learn and progress at their own pace.
2. Fast is better than slow. Productivity is king. It is important to prioritize speed and productivity. This means minimizing wait times and measuring key metrics developers care about, such as response times, lines of code, and the number of concepts or clicks required to access a feature. Developers are users who make decisions and have work to do, and their perceived or actual productivity can significantly impact the success of a platform. To ensure that the developer experience is optimized for productivity, it is vital to involve DevRel early in the design process. This will help to advocate on behalf of developers and ensure that their needs are considered throughout the development process.
3. Friction must be zero at T0. Having zero friction at the beginning of a developer's experience with a platform is crucial. This means making it easy for developers to get started without requiring them to go through multiple steps or click through terms of service. A single click should be sufficient to get started and allow the developer to begin editing and running a hello world program without having to read documentation or watch a video. The first minutes of a developer's experience with a platform is crucial and can determine whether they continue using the platform or give up. Therefore, it is important to provide an excellent getting-started experience that captures the attention of new developers and keeps them engaged.
4. Avoid turbulence in flight. To avoid turbulence in the developer experience, it is important to allow developers to take small, incremental steps. This means providing them with the information and tools they need to progress to the next stage of development without overwhelming them with too much information at once. Using existing standards and conventions can minimize friction and make it easier for developers to start. Additionally, it is crucial to recognize that developers spend significant time maintaining and running existing apps, so providing tools and support for this stage of the development process is vital.
5. Enabling learning by doing. To provide an effective learning experience for developers, it is important to provide hands-on learning and experimentation opportunities. This means providing tools and resources that allow developers to learn by doing rather than just reading about how to do something. It is also important to create learning experiences beyond just providing reference documentation and offering guidance and support throughout the development process. This can be achieved through tools like guided flows, which can help developers quickly and easily learn how to use a platform or technology.
6. Fight complexity at all costs. While having reasonable defaults and deciding for the developer is okay, they ultimately will want the final say. When you're making complicated things easy, don't allow easy things to become complex.
7. Fight uncertainty at all costs. Developers need clear guidance on how to get started and what to do next, and that uncertainty can be frustrating and paralyzing for them. It can be helpful for a platform to be opinionated and show developers the "one true way" of doing things, at least initially, to reduce uncertainty.
8. It’s not enough to solve 80% of the problem. In recent years, the tech industry has seen a surge in the development of "scaffolding" and "skeleton" apps designed to help developers quickly set up the basic structure of a new application. While these tools can help get started, they often need to catch up when creating a functional and production-ready app. Simply solving 80% of a problem is not enough to make a successful app. Instead, developers must focus on creating a fully-functional application with, for example, API calls and real-world authentication and show their code in context rather than in isolation.
9. Harness the power of cloud computing, where applicable. There are several key benefits to using the cloud for developer-centric products. First, it allows developers to access virtually limitless computing resources on demand (including edge computing), which can be particularly useful for tasks that require a lot of processing power, such as data analysis and machine learning. Second, it makes it easy for developers to collaborate and share their work, which can be especially useful for teams working on complex projects.
10. Create magical moments. Think five to ten years ahead and create powerful tools "indistinguishable from magic." This means being willing to reinvent existing products and processes if it means delivering a truly exceptional user experience.

These principles were partially inspired by Google’s own “ten things we know to be true” philosophies

Tools and APIs

Provide functional, clear, consistent, coherent, and reliable tools and APIs

The tools we build should help developers achieve their goals in the most efficient way possible. We can do this by using relevant UX principles to create good DX.

• Tools should be useful and address the core expectations of developers in relation to a specific requirement.
• Tools should be responsive and performant. UX limits for the relation between the user's attention span and responsiveness can also be applied in DX.
• Tools should be credible, consistent, and reliable in the output they provide. They should provide the correct results consistently. Updates should not result in surprises for the user.
• Tools should be designed to be intuitive, simple, and easy to use. Defaults should be available as per standard requirements, but tools should also be configurable and support extensions. Note that ease of use does not mean that tools should hide their inherent complexity from developers. They can be complexity embracing while being intuitive.
• Understand developer pain points to create solutions that are innovative and delightful to use. Some developers may find an engaging visual design or dark mode delightful, and others would like to see features they cannot find anywhere else.
• Create developer-friendly documents for solutions, capabilities, and upgrades and publish them such that developers can quickly discover them. Use tools such as tl;dr's, meaningful diagrams, and screen captures to enhance the quality of documentation. Include relevant dates in the documentation, especially for upcoming releases and trials.
• Create and maintain live examples for use cases using GitHub repos, CodePen, Glitch, and other tools
• Avoid bloated tools. Include only the necessary dependencies and limit the size of binaries, install size, download size, and others.
• Plan for interoperability. Respect the environment that the developer will be using. Be considerate to hardware, operating system, and other software limitations applicable to the environment.

Guidance for developers.

Use field knowledge of user experience to guide developers.

Meet developers where they are and help them get to where they need to go for users. Build developer tools such that engineers automatically take the necessary steps to enhance user experience. One could achieve this through built-in defaults, build automation, suggestions, and other opinionated tooling. Open source tools and frameworks play a relevant part in enabling developers to build modern apps and are an excellent medium to include best practices by default.

Show code in context, not just a “hello world” app

Often, developer documentation is limited to examples showing the basic functions you can implement with the tool or API. It's vital to include use cases and scenarios relevant to the context for which developers are likely to use the feature.

Developer Relations

Engage with the developer community through different channels to understand their needs.

Developer communities for different technologies exist on GitHub, Stack Overflow, Twitter, Reddit, and others. Developers often use these forums to discuss their experiences with technology and highlight their pain points. Product and developer relations teams can engage with developers on the relevant forums, gauge their feelings about tools and technology and provide the required feedback to enhance products further.

Source: Kenneth Auchenberg

The Relationship between Developer Relations and DX

Most developer-facing product organizations have a dedicated Developer Relations (DevRel) team to engage with developer communities who use their products. DevRel engineers may also be known as developer advocates, evangelists, or community managers in different organizational settings. Driving developer success is at the core of everything that DevRel engineers do. There are many ways in which DevRel contributes to this goal.

• Be the first customer: DevRel engineers are the power users who early validate APIs/libraries/products/prototypes with a developer-user perspective and provide valuable feedback. DevRel may also build libraries around APIs to create a smoother developer experience and contribute to samples/open-source.
• Bi-directional feedback: They are the perfect liaison between the product and the developer community. They represent developers in giving feedback to the engineering/product team. They also help take questions from engineers back to developers, triage, and help product teams understand what's causing developer friction.
• Outreach and Education: They create materials such as docs, samples, blog posts, videos, and other training material to educate developers about product capabilities, features, and new releases.
• Community Management: They are masters at community management, socializing ideas at events or through interactions in local and online developer communities.

DevRel and DX are often mentioned in similar contexts, so there is a need to understand the differences between the two. Since the DevRel team interacts directly with the developer community, it forms the human component of DX. There is an overlap between DevRel and DX, but they are not the same. DX involves making the product better in its entirety. DevRel is about taking this DX to the community. Great DevRel would be irrelevant if it was not backed by a great product. Effective DevRel engineers convey empathy towards developer needs, and effective product design embodies the same empathy.

First and foremost, an outstanding Developer Experience starts with your product. DX is fundamentally about your product experience for developers. It's product-led growth for Developers.

Kenneth Auchenberg

If you have a new product/feature launch coming soon, focus on the product first (API design, error messages, visual feedback, etc), then the docs, then the content, and so on, in that order. Overweighting outer circles when the inner circles aren't complete will make the experience feel lacking.

Shawn Swyx Wang

DX architecture starts with the product and then radiates out to DevRel, as shown above. The product team owns the product and shares responsibility for Docs with the DevRel team. The DevRel team focuses on content and community. When both product and DevRel are on the same page, working together towards the mutual goal of creating value for developers - you have great DX.

How do we measure DX?

Measuring the DX offered by our tools enables us to gauge where we are and take the necessary steps to apply the DX principles discussed earlier. There are different frameworks and methods available to measure DX. The following is a summary of these methods:

Measuring UX characteristics

Since we initially used UX characteristics to define DX, metrics for measuring DX can judge the availability of the following UX characteristics in our products.

Usability

Usability tells how easy the product is to install, set up, and use. The product should be intuitive, consistent, and performant to ensure usability. Most methods generally recommended for measuring usability involve getting feedback from real users by showing them the product or prototype. These include:

• Guerrilla tests - Ask random developers to use the product and note down the issues found and sentiments observed.
• Lab tests - are used to gather in-depth information by calling a group of developers to a usability lab where a moderator asks them to complete specific tasks. Metrics such as task times and completion rates may be used to quantify the results.
• Remote usability tests - are unmoderated tests where developers may complete the tasks remotely from their usual work environment.
• Interviews: This method involves interviewing a group of people based on a script. The interviewer collects qualitative data (e.g., how did it feel) and quantitative data (e.g., time to complete the task). This method may be simplified through a survey form to answer specific questions relevant to the product.

When conducting usability testing, be sure to follow the guidelines on recruiting users, so that you recruit users who best represent your user base. This can help to avoid effects of possible bias due to factors such as technical competency or location (remote vs office) of developers.

Accessibility

Accessibility checks how accessible the product is for different roles which can use it. Developer journey maps and the challenges encountered in executing the steps in the map may be used to measure the accessibility of the product. Here are three ways to identify friction and understand if the defined journeys are working optimally:

1. Ask the community about challenges and improvement opportunities.
2. Conduct friction audits to log the friction points at different touchpoints in the journey.
3. Analyze the data collected and assign metrics to each data point for evaluation.

Accessibility testing is especially relevant to critical developer journeys.

Findability

Findability defines how fast a user can find what they need in the product. It could mean finding the product itself, finding a specific feature, or the resolution or workaround for an issue. The primary way to validate this is by measuring the time used by the user to find something in the product. We can use laboratory tests with screen recording for this measurement.

Credibility

Credibility is about delivering stable products with the correct functionality. Measuring credibility is usually about measuring bugs in the software. Traditional manual or automated functional testing methods may be used to test credibility. In addition to measuring issues within the software, we should also consider process bugs that arise due to developers' lack of understanding of how something works.

Usefulness

Usefulness addresses the specific needs of developers. The measurement of this characteristic ensures that we have addressed use cases executed most often by developers. Ensuring that critical developer journeys are fulfilled without accessibility or credibility issues can help determine the product's usefulness and value.

Value

This characteristic indicates the value our products provide to developers. Data that is relevant to the value provided is usually easy to gather. Some metrics that could prove helpful are.

• The number of users signing up or paying for a particular product
• The number of users using it more than once
• The number of users recommending it to others.

Teams can also define the product's value proposition and ask users how the product meets this goal.

Other Methods

The HEART framework

Google's HEART framework is recommended for measuring UX for web applications on a large scale using automated means. This framework can be adapted to measure DX directly or if you are already using it to measure UX, you might be able to determine if implementation of a DX strategy triggered a change in UX.

Developer Productivity

The immediate goal of having a DX framework is to improve the productivity of developers and teams who use our tools. Thus, in addition to improvements in UX, developer productivity also makes a logical metric for measuring DX. We can measure the improvement in productivity that teams using our products experience over time.

Note the use of teams in this context. Traditionally used metrics like lines of code or hours worked though convenient do not tell the true story of developer productivity. They discount the "negative work" that is sometimes done by developers - work that does not add value to the project. Similarly, individual developers' contributions may or may not be relevant to the actual completion of the project. Team velocity or the number of features shipped by the team gives a more accurate picture of teams' productivity. Thus, improvement in team velocity after shipping changes to developer tools or APIs can be used to measure DX.

Implementing a DX Roadmap

To implement a DX roadmap, you would first need to map your product. Everyone in the DX organization should have the same mental map of the product or service offered to create the "complete" developer experience.

Once they have a general idea of the product map, they can start designing the DX for the specific journeys developers can take.

• Toothbrush (frequent and important) journeys and
• Pivotal (infrequent but important) journeys.

A journey map is a tool that helps you understand these journeys better.

Developer Journey Mapping

A Journey Map is a standard tool used in UX design to visualize the user's journey - "A journey map is a visualization of the process that a person goes through in order to accomplish a goal." Journey maps help to deliver a vivid narrative of a customer's interactions, overall needs, and pain points as they use a product. A corresponding tool that is useful in DX is the Developer Journey Map.

A developer journey is the sequence of steps that developers follow to achieve something using our products and their interactions along the way. At a high level, a journey is a combination of

• A goal - what is the developer trying to do - Build, learn, optimize?
• A role - who is the developer - full-stack developer, UI designer, accessibility engineer?
• A context - what is their context - are they existing users or new users?

Journey mapping is a practical and valuable tool that helps visualize the end-to-end experience from the developers' perspective. The following illustration depicts the stages involved in a typical developer journey. Note that many different journeys may be defined for every goal, role, and context combination.

The level of developer-product interaction increases from left to right. The journey involves several internal and external touchpoints where developers might interact with one or more aspects of the product. The success or failure of these interactions in terms of how the developer feels about them creates the overall developer experience. The map helps identify points of friction that can be optimized to create a better overall experience.

The following table defines each stage in the developer journey map.

Journey maps help identify accessibility issues at each stage and ensure that all target users can access the product in their respective roles.

Critical developer journeys

Critical developer journeys are the ones that are either frequent or very important to developers—the ones we have to get right if we, and our developers, are to be successful.

Any non-trivial product or set of related products will have a very large number of possible journeys, which means it can be challenging to identify which journeys should the DX team focus on the most.

The team can start identifying critical journeys by reviewing existing metrics, such as task completion or abandonment rates and customer or support channel feedback. This would help identify areas in the product that cause friction.

When identifying critical journeys - note that.

1. Findability is a crucial characteristic of DX. Discovery and comprehension are just as important as product functionality. Thus, the journey involved in finding information about a product is also critical.
2. Consider both Toothbrush and Pivotal journeys. Pivotal journeys include those which may only apply to a subset of the developer base. For example, developers will only go through some journeys once, such as discovery and registration or installation.

Plugging cognitive leaks

As discussed earlier, bad DX can lead to slower iterations and distractions that derail the development process and cause cognitive drain. Identifying such potential derailers in the developer journey early should be a part of DX design. Kathy Sierra has talked extensively about the effects of cognitive drain and discussed methods to ensure users remain engaged and focused. The first step towards preventing cognitive drain is acknowledging everything that could go wrong or lead to confusion when someone uses your product. Reducing choice through defaults, automating tasks, and making it easier to focus can help to increase developer engagement.

DX Maturity Levels

As companies recognize the importance of DX, they have started actively planning for it. A DX maturity model can help you understand where you are in your DX journey. It can also help you gauge how you measure up against a competitor.

Based on where they are in their DX journey, every developer tool/service company could have achieved one of the following levels of DX maturity.

1. Suffering because of bad DX: This refers to tools and services not taking off because of bad DX. It can be characterized by low usage, low adoption, and negative feedback on developer forums. If a company has not actively thought of DX or pursued the DX mindset, it could be suffering because of bad DX.
2. Understanding DX: This refers to teams or product managers who have realized the importance of DX and are trying to implement it within their organization to reduce the impact of bad DX. It will typically involve product managers trying to understand DX and the principles and methods required to implement it.
3. Applying DX: This is where a company starts applying DX principles to their developer tools. It is an exciting phase where organizations start tracking their developers' journeys, map them out, identify developer needs and desires, identify issues in existing offerings, and find ways to include features to satisfy these needs in their products.
4. Pioneering DX: This is where teams start sharing DX insights on behalf of developers with others by generating content, gathering insights, and creating communities. This could reach a point where the company is known for something outstanding that they did with regard to DX. For example, Stripe/Airtable became known for their contextual documentation. (Stripe docs insert your API key for easy copy-paste).

Developer Experience and AI

Artificial intelligence and generative AI are transforming how software developers build applications and products. As AI capabilities in code completion, bug finding, testing, and documentation improve, developer workflows are enhanced and accelerated. However, thoughtfully incorporating AI into the developer experience remains critical.

When designing AI-enabled developer tools, aspects like trust, familiarity, and control shape how developers perceive and adopt new functionality. Developers want AI to act as a collaborator (think a pair-programmer) not just an auto-complete bot. The concepts that underpin human collaboration and teamwork should guide AI assistant design.

Trust as the Foundation

Trust is essential for developers to rely on AI suggestions and automations. Trust is earned over multiple successful interactions. If AI-generated code behaves unpredictably or suggests inappropriate solutions too frequently, developers will dismiss or disable the functionality.

For AI to seem trustworthy:

• Suggestions must be contextually relevant to the code being written. Generic or overly complex recommendations erode trust quickly.
• The system should avoid unprompted major changes like rewriting code. Incremental assists feel more trustworthy than sudden shifts.
• Explain relevance and provide rationale when appropriate. Transparency into the AI's reasoning helps calibrate appropriate trust.
• Reliability and predictable behavior matter. Flaky or buggy features break trust.
• Start with high precision, modest recall. As developers gain familiarity, expand capabilities.

Source

The Path to Familiarity

Developers build mental models of how systems function through experience. Familiarity with an AI assistant's strengths and weaknesses takes time. With sustained use, developers learn to effectively leverage AI functionality.

Strategies for enabling familiarity include:

• Onboarding guidance and documentation on how best to collaborate with AI. Explain what it can and cannot do.
• Allow users to configure the AI to adapt it to personal preferences and workflows. Customization builds familiarity.
• Provide transparency into the AI's training data and highlight how user feedback improves suggestions over time.
• Plan for co-learning between the user and AI. They will mutually influence each other.
• Design interactions that leverage existing mental models of team collaboration in software development.

Control and the AI Partnership

Developers value flexibility and control over their tools. AI should enhance developer autonomy, not restrict it.

• Allow developers to easily accept, ignore, modify or revert AI suggestions. Mandating acceptance undermines control.
• Make AI functionality configurable and customizable. Users can tune behavior to their needs.
• Consider automated triggers for surfacing AI recommendations, but keep developers able to manually invoke suggestions.
• Provide opt-in/opt-out control for AI capabilities on a per-feature basis. Don't force adoption.
• Design interactions as collaboration between equals. Avoid framing the AI as superior.

By honoring trust, familiarity and control, AI can transform from uncanny automation to trusted partner. Developer-centered AI creates superhuman coder symbiosis.

Key Takeaways

• Build trust through reliable, contextually relevant suggestions. Avoid unpredictability.
• Enable familiarity by supporting co-learning and customization between user and AI.
• Preserve user control through optionality and configurability of AI functions.
• Design interactions that leverage mental models of collaboration and teamwork.
• Focus on assisting humans, not replacing them. Augment developers, don't automate them.

Conclusion

Having a great DX can help enable developers to build great customer experiences. There's a wealth we have yet to learn about this topic, but hopefully you've found some of the learnings written in this book helpful on your journey to better supporting developers and users.

As a friendly recap, the following table summarizes some of the UX and DX principles discussed previously and the techniques available to measure them.

Enabling a DX mindset can go a long way in addressing developer needs, improving developer happiness and unlocking better experiences for everyone. Until next time, thanks for reading and good luck with the rest of your DX journey.

Read Our Latest Blogs

Recommended Reading

Great community write-ups for even more nuance on Developer Experience.

Developer experience vs. User Experience - Malte Ubl

Malte Ubl

Developer Experience at Netlify - Sarah Drasner

Sarah Drasner

Reduce Friction - C J Silverio

C J Silverio

DX Tips: The DevTools Magazine - Shawn Swyx Wang

Shawn Swyx Wang

Curated Developer Experience resources - Zeno Rocha

Zeno Rocha

Developer Experience - MS engineering playbook

Microsoft Engineering