You don’t have to be an engineer to be familiar with the term “user experience.” But, how about its lesser known cousin, “developer experience”? Developer experience is inching towards the limelight as more and more companies recognize its importance. In this blog post, we’re going to break down everything you need to know to stay ahead of the game.
You’ll learn:
- What developer experience is and a simple way to look at it
- Why developer experience matters for your team and company
- Best practices to help you build a solid foundation for developer experience
Let’s dig in.
What is developer experience?
Developer experience, or DX for short, describes the overall feelings and perceptions a developer has while interacting with a technical product, “interacting” having a two-fold meaning. Whether the developer is using your product (for instance, your product is an API or software development kit and developers are your consumers) or the developer is creating your product (e.g. your product is an app and the developer is your employee making it), you’re dealing with developer experience.
Great DX is all about optimizing the developers’ workflows, processes, work environment, and more, so that they can have a more meaningful and delightful experience. The easiest way to understand developer experience is to take a concept you’re likely more familiar with: user experience. Krzysztof Wróbel, Director of Engineering at Codilime, proposes three pillars of developer experience: usability, findability, and credibility. Notably, these three items are also on UX pioneer Peter Morville’s famous list of pillars for user experience.
Wróbel writes, “When it comes to software development itself, there are three pillars of developer experience: usability, findability, and credibility. Usability is how easy your digital or software product is to use. It is removing barriers, such as unnecessary steps when using an app. Findability is how quickly and easily users (in this case — developers) can find the functionalities they are looking for. If you pursue perfect findability, you should support the user (developer) journey across changing tasks. Last but not least, credibility, a long-term pillar, is that your users trust your app or software to solve their problems.”
Long story short: When you improve developer experience, you look for ways to support the developer by orienting yourself to their needs. Before we continue to the how, you need to understand the why behind dx.
Why is developer experience important?
If you’re in the business of creating and selling software, then developers are pretty much the backbone of your entire operation. Your end users and customers are important, yes. But like any business, none of it is sustainable unless your internal employees (i.e. your developers) are getting as much support as they need. Plus, as mentioned, developers are your consumers in the case of APIs and SDKs.
Improved employee well-being and employee retention are obvious byproducts of great developer experience. With the Great Resignation underfoot, it’s strikingly clear that companies that genuinely care for their employees will inspire loyalty and better performance. But that’s not the only thing. As Harness points out, “One paradigm of thinking is that if you improve your internal customer experience [dx], then your external customers will benefit too.” In short, happy and supported developers create better products.
Moreover, developer experience is great for DevOps, the methodology that integrates development and operations and closes the gaps in the overarching software development life cycle.
To that end, let’s take a look at how a developer experience team achieves that.
What does a developer experience team do?
A developer experience team has many functions, including:
Writing technical documentation
Technical documentation includes release notes, knowledge bases, user manuals — any type of writing that describes the use cases and “how-to” behind a product or service. The developer experience team should provide documentation pertaining to the processes and workflows of the development team. This will not only help to standardize things, but it will also come in handy when onboarding new developers. Further, technical documentation is crucial for external developers who are using your app’s API or SDK.
Selecting developer tools
A developer experience team makes sure that the development team has all the tools they need to get the job done well. They should choose tools based on their functionality and ease of use, and they should make sure that tools are standardized across the team. According to Codilime, such tools may include deployment pipelines, tools for testing frameworks, tools for observability and monitoring, and more.
Defining workflows
Along with standardizing developer tools, the developer experience team also standardizes workflows. Great DX aims to find opportunities to make processes and procedures more efficient, identify and minimize bottlenecks, and overall just make things easier for the developers.
Choosing the programming language
Here’s a great example of how programming language selection is also a matter of developer experience. According to the same blog post mentioned above, “The choice of programming language is of high importance — frontend developers often opt for using TypeScript instead of JavaScript. The language enables them to detect errors quickly (thanks to the type safety and the support of an IDE) and has many features you cannot use with JS (such as template literal types of JSX Factories).”
Now you’re a little more acquainted with what a developer experience team does. But what does the team look like? What are the roles?
Developer experience roles
In many engineering and development teams, it’s common for the role of Developer Experience Engineer (DXE) to rise organically. Out of necessity, an engineer becomes a steward for better processes and tools that make the whole team’s lives easier. On the other hand, some organizations might intentionally create an entire team dedicated to developer experience.
According to Rob Zuper, Chief Technology Officer at CircleCI, a developer experience team usually consists of 1-10 members, each with the title of Developer Experience Engineer. Other organizations go further to distinguish roles within the developer experience team. For instance, Uber’s DX team includes developers, educators, and technical writers.
“Our team’s responsibilities range from educating our engineers and managers on development best practices to providing technical documentation and standardizing development flows with programming language support,” shares Nikolay Sokratov, Uber’s Head of Developer Experience. “Take, for example, our Dev Exp engineers. These developers create various tools to increase engineering productivity at Uber such as build systems, integration tests, test systems, scaffolding, and language frameworks. They also work on large-scale infrastructure projects that deal with managing services using serverless platforms and distributed workflow systems.”
On the other hand, the developer experience team might not be a team at all, but a single person — a programmer or developer who prioritizes the developer experience. In that case, that person can claim the title of DXO, Developer Experience Owner.
Codilime writes, “To properly select the DX tools used in a team, many businesses use DXOs — Developer Experience Owners. This role constantly evaluates whether the tools in use are optimal for the current tasks and if not, replaces them. DXOs manage the staging environment and manage the access of the developers to it. They keep the developers in sync — they make sure everyone knows what is going on, and when. They are also involved in testing tools and workflows.”
However you decide to implement developer experience at your company, it all boils down to the same responsibilities. Depending on the size of your development teams and the scope of work you may need, you could assign a single DXO or an entire team of engineers, educators, and technical writers.
API developer experience
As a software company, developer experience encompasses the experiences of your internal software developers as they carry out their work. That involves making sure their tools, processes, and working environment are all conducive to their best work. But that’s not the only way of looking at DX.
If you’ve created an app with API access, then you also need to think about the experiences of external developers who are interacting with your API, or application programming interface. The same thing goes for SDKs (software development kits) which are toolkits that include a compiler, debugger, application programming interfaces, and more.
Think about companies like Stripe and AWS (Amazon Web Services) who have risen to the top by prioritizing the developer experience. They’ve created an ecosystem, a community of developers and stakeholders who work together to drive innovation. Since other developers are the consumer of your platform or interface, then developer experience and user experience are one and the same.
Best practices to improve developer experience
Support Focus Time.
First things first, make sure your developers have enough time to do their work. We all know that software engineering and software development are crafts that require solid stretches of uninterrupted time… but it’s not always so easy to turn that into a reality. If a lack of time or too many meetings are a regular complaint among the developers on your team, try using a tool like Clockwise that automatically finds and creates Focus Time, even in the most meeting-heavy of schedules. Prioritizing focus will not only do wonders for developer productivity but also stress levels!
Document everything.
From your workflows to frequently asked questions and everything in between, put it all into writing. The goal is to create a knowledge base that can act as a single source of truth. There are a lot of moving parts in software development, and creating technical documentation is the single most effective way to keep track of everything. This way, developers have a go-to reference in case any questions pop up, especially new developers — which brings us to our next point.
Reduce ramp-up time.
Ramp-up time is the time it takes for a new developer to start delivering value to a team. Even then, after the first delivery of value, some don’t consider a member to be “fully-ramped up.” Tom Ahi Dror, Co-Founder of Swimm.io writes that it takes 3-9 months for a developer to reach full ramp-up. Documentation, communication, transparency, and a supportive onboarding process — all of these will help to reduce ramp-up time and improve developer experience.
Don’t overlook soft skills like empathy.
Ultimately, good DX is an act of empathy. It requires you to put yourself in the shoes of the developers and consider the developer’s journey, the problems they face, the sources of their frustrations, and the solutions. As you do so, practical solutions will start to arise. Maybe it’s time to switch out a tool or introduce automation into a particular step. Other factors like work culture and team environment are also important to consider and contribute to the overall developer experience.
Going forward
Good developer experience is all about adopting a developer-first approach, putting yourself in their shoes, and looking for ways to improve their journey.
Read next
- What Makes for Good Developer Experience?
- How to Build and Hire a Developer Experience Team
- How to measure developer experience (with metrics!)
About the author
Judy Tsuei is a Simon & Schuster author, speaker, and podcast host. She has been writing for Clockwise for several years while also being featured in MindBodyGreen, BBC Travel, Fast Company, Hello Giggles, and more. As the founder of Wild Hearted Words, a creative marketing agency for global brands, Judy is also a mentor with the Founder Institute, the world's largest pre-seed accelerator. Judy advocates for mental and emotional health on her popular podcast, F*ck Saving Face. Follow along her journey at WildHeartedWords.com.
.gif)
