The Complete Guide to Developer Experience (DX)
There’s a direct correlation between Developer Experience (DX) on our engineering teams, and innovation, efficiency, and, ultimately success.
We know it’s a competitive landscape in terms of both the product and job markets. Software development teams jostle for elite talent and are pressured to deliver top-tier products. DX has escalated from being a ‘nice-to-have’ to an absolute essential.
The symptoms of a lacklustre DX can be subtle and easy to overlook. Creating a great DX takes intentionality, but it can be surprisingly easy to make substantial gains if we look in the right places.
In this complete guide to Developer Experience, I’ll cover:
- What is Developer Experience?
- How do we spot a subpar Developer Experience?
- Strategies to improve Developer Experience
- How to measure Developer Experience
Understanding Developer Experience (DX)
Developer experience is the experience that software developers have while working. The term is often used in a similar vein to User Experience (UX).
All kinds of things impact Developer Experience, also known as DX or DevEx.
These include the user-friendliness of your APIs and SDKs, the efficiency of your development workflows, the quality of your documentation and the trust and transparency you achieve in your team.
If you’re losing your top talent or struggling to attract the cream of the crop, a subpar DX is often the culprit. Remember, your standout people are your advantage.
A positive developer experience can lead to more developer productivity, faster development cycles, higher-quality end products, and higher overall satisfaction among developers. With the increasing complexity of software development and the variety of tools and technologies available, focussing on DX can be a competitive double-edged sword. Get it right, and we unlock genuine competitive advantages.
How do we know when we have a developer experience problem?
When not addressed correctly, a poor DX allowed to proliferate leads to numerous issues within your team and the products they develop.
But how can we identify when we are grappling with a DX problem? This takes a keen eye, an understanding of team dynamics, and an appreciation for the red flags that signal potential trouble.
I wrote more deeply about these signs here.
- Ineffective collaboration. Any communication bottlenecks or silos in your team spell trouble, leading to waste, missed opportunities, and a sluggish development process. Don’t ignore the telltale signs of miscommunication, confusion, duplication of effort and so on.
- Disjointed tool integration. Fragmented toolsets are nothing but roadblocks for modern developers. When tools don’t mesh well, it’s a sure-fire productivity killer. Look out for grievances about constant tool switching or manual data transfers.
- Laggy feedback loops. Timely feedback is the lifeblood of progress. Without it, you’re left with wasted time, rising frustration, and a stalled development process. Pay close attention to feedback delays.
- Unsatisfactory documentation and resources. A stellar DX requires comprehensive and accessible documentation. If developers are left in the lurch, scrambling for answers, your DX is taking a hit. Keep an ear out for repeated questions or frustrations around information access.
- Deficient support and community engagement. If developers feel stranded or undervalued due to lacklustre support or disengaged communities, that’s a DX red flag. Note any dissatisfaction with support resources or disinterest in company initiatives.
- Burnout and attrition. A dismal DX is a surefire recipe for exhausted developers and a revolving door of team members. Monitor workload levels and well-being to keep burnout at bay.
- The hard truth shows up in the end product. A suffering DX often manifests as compromised product quality and delayed releases. Keep a close watch on progress and performance as symptoms of underlying DX issues.
Spotting a DX problem early on is the first step towards rectifying it.
Strategies to improve Developer Experience
So, you’ve spotted the symptoms. What are the cures?
1. Get collaboration, visibility and transparency right.
Who hasn’t felt the ache of chasing down project updates or nudging someone for a pull request review? At the heart of smooth collaboration lies visibility and transparency.
I encourage leaders to think about visibility as the availability of operational knowledge. Meanwhile, transparency is the initiative and ability to share this knowledge openly and proactively across the team.
To improve visibility, as leaders, we have to provide the tools and frameworks that allow your team to contribute operational knowledge effortlessly. The right tools will record operational activity by default, in the way Git keeps records of commits simply as part of the everyday workflow. The wrong tools require additional effort to keep up-to-date.
Transparency is about having the right channels open at the right times. But this shouldn’t mean simply creating a bunch of meetings for sharing. In fact, although a common intuition, this can often have adverse effects, like creating “pointless” meetings which drain time and energy covering operational (rather than strategic) matters.
This is one of the hardest parts of developer experience to get right.
Stepsize AI gives you updates, insights and alerts that drive actions right when they are needed.
gives you updates, insights and alerts that drive actions right when they are needed.
You can configure things like a Daily Team Sync, a Stakeholder Update or even Executive Summaries. Plus, you can ask questions about your updates, so you can get what you need without taking people out of their flow.
It works by observing everything that happens across relevant channels, boards and repos in the likes of Slack, Jira, and GitHub.
Then, it builds a unique data graph of your operational activity and surfaces what matters in easy-to-digest updates.
My team at Stepsize have built a solution just for this.
Your operational data is a goldmine.
Get started with Stepsize AI here.
2. The right resources
Are you still asking your engineers to write up documentation by hand, or yet to permit GitHub Copilot?
There’s ample research that shows that teams who are slow to adopt tools that make engineers’ lives easier (not to mention engineering processes more efficient) will fall behind.
70% of engineering teams, for example, are adopting AI, with many teams having an active strategy or even a task force dedicated to safe, fast adoption. Those teams are already shipping 3.5x faster on average.
To put that another way, their engineers are regaining around 3 hours out of every 8-hour day.
I wrote this list of AI tools that software engineering leaders should know about for their teams.
3. Get your development environment right.
We improve developer experience when we reduce friction. Here are steps you can take to reduce friction and improve productivity:
1. Conduct Regular Audits: Start by systematically evaluating your existing tools and processes. Identify bottlenecks, inefficiencies, or any areas causing unnecessary friction. Make this analysis an ongoing practice to ensure your environment continues to support, not hinder, your developers’ workflow.
2. Upgrade Your Tools: Select and upgrade tools that enhance collaboration, streamline processes, and reduce redundancies. Remember, the tools should also have robust integration capabilities to limit time wasted on switching contexts or manually transferring data.
3. Refine Coding Standards: Implement clear, consistent, and well-documented coding practices. This improves code readability and maintainability. Automating code reviews and employing linting tools can help enforce these standards.
4. Automate Tasks: Automating routine tasks, such as code formatting, testing, and deployment, drastically reduces manual work. This lets developers focus more on creative problem-solving and innovation, boosting productivity and job satisfaction.
5. Establish Robust Feedback Loops: Encourage constructive feedback within your team. Leverage AI-powered tools to automate feedback, analyse code changes, and spot performance bottlenecks. Instant feedback allows developers to make immediate corrections, leading to a more efficient development process and a higher-quality codebase.
When we fine-tune the development environment, it elevates the developer experience but also results in a superior product, happier teams, and improved business outcomes.
4. DX and culture.
A solid team culture is more than just good vibes. It may be the least tangible, least quantifiable lever on this list, but you’ll already know it underpins the whole operation. There are so many things we can do to build a positive culture, and I won’t list them all here, but here are ideas you can consider for your team.
1. Empower Decision-making: Let your developers take part in all decisions, big or small. They’re on the ground — they know the score. Trust them and they’ll give you insights that you’d miss otherwise.
2. Celebrate Success: Recognise every win, not just the game-changers. A solved bug, a deployed feature, whatever — they all matter. Acknowledge them to motivate your team and drive a culture of continuous improvement.
3. Foster Growth: Invest in your developers’ growth. Offer opportunities to learn new technologies, attend relevant events, or lead workshops. A developer who’s growing is an asset that adds more value over time.
4. Advocate Work-life Balance: It’s not about clocking out early; it’s about respecting deep work and the need for downtime. Promoting a balance isn’t losing productive time — it’s investing in productive minds.
A subpar DX is a hurdle, but it’s surmountable. The right strategy and culture can turn it into a stepping stone. And remember, in this journey to improve DX, culture isn’t just a part of the plan — it’s the game plan.
How to measure developer experience
Measuring Developer Experience (DX) is a multidimensional task.
We can approach it in a number of ways, and how we approach it is going to depend on the types of organisations we work for, and the cultures within them.
Generally speaking, measuring DX is going to be a job for both quantitative as well as qualitative analysis. It’s not ever just about numbers but the overall sentiment of your developers.
Different methods will suit different organisations. Here are some options you can consider.
1. Developer Surveys: Surveys are a traditional way to collect feedback. Questions can range from simple satisfaction ratings to more complex queries about tooling, workflow, and code quality. The key is to strike a balance between broad questions that provide a general picture and specific questions that pinpoint areas for improvement. Always keep the pulse of your team’s sentiment and don’t forget to act upon the feedback!
2. Interviews and One-on-Ones: Surveys are great, but they can often lack the depth of information a one-on-one conversation can provide. Regular catch-ups can unearth hidden challenges and provide insights into the developer’s daily experiences, their workflows, bottlenecks, and pain points.
3. Retention Rates: Retention is a key indicator of DX. High turnover can signal an unsatisfactory DX. To get a more nuanced understanding, look at the reasons why developers leave. Exit interviews can provide valuable insights here.
4. Productivity Metrics: Tools like Git can provide insights into commit frequencies, pull requests, and code quality. Remember, these metrics are just indicators and need to be interpreted carefully. High commit frequencies, for instance, could mean high productivity, or it could signal a lack of planning resulting in numerous minor fixes.
Always complement data with empathy and an understanding of the individual experiences behind the numbers. It’s all about creating an environment where developers can do their best work and feel valued while doing it. That’s the true measure of DX.
5. Onboarding Time: How long does it take a new developer to make their first commit or resolve their first ticket? A quick start could suggest good documentation and a supportive onboarding process, both indicative of a positive DX.
6. Usage of Tools and APIs: Track how developers are using the tools and APIs you provide. High usage and low error rates might indicate a great developer experience. On the other hand, if certain features are seldom used, or lead to a lot of errors, it could signal a problem.
But measuring DX shouldn’t just be a passive act of collecting and analysing metrics. The real value comes from reading between the lines, reading the room and actioning insights you uncover.
Wrapping up
Developer experience has a crucial role in driving successful projects over time. The best developer experiences are those that seamlessly integrate powerful tools and streamlined workflows, enabling teams to collaborate more effectively, iterate faster, and solve problems more innovatively. A superior DX not only enhances productivity but also inspires the creative thinking necessary for truly game-changing software solutions.
It leverages data from Jira, Slack, and GitHub, providing you with critical insights, actionable tasks, and relevant updates.
Visibility and transparency are a lynchpin for all of these things.
Until recently, being informed about all the important things that were going on, effortlessly, wasn’t possible.
Now, we’ve built Stepsize AI.
And in general, this shift to smarter, AI-powered product and engineering management has immense potential to elevate team performance and overall project success.
Experience the game-changing capabilities of Stepsize AI for yourself.
Originally published at https://stepsize.com.