An Introduction to Developer Experience

Developers are expensive, hard to find, and even harder to keep hold of. Businesses often focus on improving the working experience of development teams, with copious perks, bonuses, and preferential treatment, but often focus far less on the most crucial aspect, can developers work effectively and do they enjoy their work?

Developer experience (DX) is not quite as clearly defined as user experience, with some taking it to mean the experience developers have or create with an individual tool, and others to mean the experience of developers in their company. You could argue that those two opinions are somewhat linked, and can influence each other. Internal development teams who enjoy and appreciate using well-designed tools are more likely to value and create well-designed tools themselves.

In this article I look mostly at improving the developer experience within a company, and touch upon other aspects where relevant, we have future articles planned to help you improve the DX of the projects you maintain.

The goal of this article is to help those in charge of development teams understand what their developers struggle with and complain about and help them do something about it.

Balance Experimentation and Productivity

There is a fine line to tread with getting internal DX right. Developers generally like to experiment with new tools, languages, and practices. Making developers always work on the same problems, or with the same languages or technologies can result in bored, unmotivated developers whom you risk losing. Allowing them to experiment can result in improvements and innovative new features for your application. However, it can also result in time wasted or adding unneeded complexity to your application(s).

Some developer tools are infamous for adding complexity where maybe complexity was not needed. Using a Kubernetes cluster spread across multiple geographical zones with a service mesh and load balancer to serve a static site is probably overkill, and a webserver is enough.

Managers of development teams could consider something like a 20% time scheme that other companies have tried. These schemes give developers a defined time to experiment with ideas, but with no pressure for it to lead to a tangible outcome. This time could be during individual work hours, or an internal hackathon where all team members work together (more on the benefits of hackathons later). It’s worth doing some reading and research around implementing such programs at companies such as Google, as they can end up poorly implemented, leading to backlash against the idea.

Make Choices to Improve DX

Choose Tools that Reduce Cognitive Load

Development is a mentally taxing task, and many of the tips and best practices for improving the DX of tools themselves are about not adding to that mental load.

When you choose tools for your team, try not to choose based on trends or convincing sales calls, but choose tools that have a good DX for your teams.

Look at aspects such as:

• If it’s a commercial project, can you developers try before buying?
• If it’s open-source, what’s the user base and does it integrate with other tools you use?
• Open-source can give unbridled flexibility, but someone has to maintain and manage it.
• What’s the onboarding experience like and how long does it take you to get to a working prototype?
• If a project is hard to get started with, it’s likely to have more issues beneath the surface.
• Does anyone in your development team have experience using the tool, similar tools, or the language it’s written in?
• Is there facing public documentation?
• While you can’t tell much about documentation from a quick read, typos, and lots of bad grammar can show that it’s not looked after.

Choose Tools that Have a Community or Ecosystem

Look at how the community or company behind the project communicates (and if a community even exists). Are they open and honest with explaining problems such as downtime, or bugs? Do they respond constructively to questions or feedback, or ignore and dismiss it? These indications of how users are treated can indicate how committed to the experience those behind a project are.

This research is as important for an open-source project as a commercial product. Something solely developed by one person is prone to vulnerabilities, but a commercial project with an ecosystem also shows extensibility and a company unafraid of collaborating with others.

Does your choice of tools, languages, and frameworks (after a period of adjustment) improve the productivity and experience of your development team, or solve a problem, or are you changing for the sake of changing?

Choose Tools that Abstract Complexity

Look for tools that allow developers (and potentially other teammates) to use them the way they feel comfortable. For example, a developer tool that you can only configure and access through a graphical interface (GUI) is great for those not used to using an API or command-line interface (CLI). However, a GUI is not extensible and makes the service hard to connect to any continuous integration or testing tools.

The best tools (also in terms of general user experience) allow for a user to seamlessly switch between interaction methods and still have access to the same data and (relevant) functionality as they do.

Similarly, does the tool or framework only have an API you have to interact with directly, or does it supply SDKs or toolkits for popular programming languages to make integrating it with your application(s) easier.

Avoid Fragmented Tools Without Standards

Teams do not use tools and frameworks in isolation from each other. While there are always challenges in integration, tools that follow certain standards and patterns should be easier to integrate.

Fortunately, more tools and their makers recognize the importance of following these standards than ever before, so those that don’t are increasingly the exception.

Saying that you follow a standard doesn’t mean you follow it well, so test the integration points most important to you when weighing up which tools to use. Remember that if you can’t find the exact integration tools you are looking for (a helm chart for example), if they exist on a public company roadmap or as a community contribution, these are potentially positive indications to an active community or ecosystem.

Hackathons

Focussing briefly on the DX for your own projects, think how frustrated you feel when you encounter projects that are hard to understand or use. Take an objective and independent look at your project. If you think other users may feel the same way, then you understand the potential frustration of your users and should do something to change that.

Giving advice is one thing, but how do you motivate team members or managers to make a change? I have always found dogfooding or a hackathon one of the best ways to help people realize common struggles.

If you are creating your own tooling for other users, you’d be (un)pleasantly surprised how few developers use the tools they create. For teams experiencing issues with their developer workflow, then a hackathon can help directly show other teammates and their managers the points of struggle or time-wasting. Of course, for this to work, you need everyone to take part in a hackathon, not just treat it as “something for developers.” For everyone to want to make a change, everyone has to know and understand the potential issues between everyone’s workflows.

Streamline Internal Policies and Processes

Good tool choice is one piece of the puzzle, but only takes you so far if your internal policies put up constant roadblocks to productivity.

A company cannot claim to embrace good internal DX (or broader agile practices) if too many tasks a developer attempts to accomplish require lengthy or complex approval processes. For example, does a developer need to raise a ticket or get approval from one of more people to create a new repository or developer environment? And if they do, how long until someone resolves that ticket, and by the time they do, has the developer lost sight of what it was they were trying to do?

It’s understandable that a large company may want to keep an eye on costs from wasted resources, but many platforms have options for handling this automatically, or give you the ability to define resource and budget limits. An approach that an increasing amount of companies are adopting is “psychological safety”. This approach starts from a position of trust in a skilled and experienced workforce to do the right thing, but encourages maintaining metrics on the effectiveness of approaches to justify, or continue to justify their use or need. This way, developers are free to experiment, but a team manager or engineering lead is able to see the effectiveness of these experiments when they need to. A strong feeling of trust between team members can lead to better employee engagement, better DX, and fewer developers looking for roles elsewhere.

Maintain Internal Documentation

Earlier this article mentioned good tools documentation, but internal documentation of processes, workflows, and systems is equally as important. Internal documentation not only helps existing team members know how the tooling a company uses works and fits together (especially for less regular tasks), but provides you with onboarding materials for new team members. Good internal documentation should (ideally) reduce the amount of questions developers need to ask each other, and thus increase and improve their time spent developing.