DEV Community

Cover image for How to Understand and Improve Your Developer Experience
Signadot
Signadot

Posted on

How to Understand and Improve Your Developer Experience

Originally posted on The New Stack, by Nočnica Mellifera.

You need to look at the entire developer journey, from onboarding to day-to-day tasks, and even how feedback and contributions are recognized and rewarded.

Read Part 1 of this series.

Understanding and improving developer experience (DevEx) is not just about adopting new tools or technologies; it’s about fostering a culture that prioritizes the well-being and productivity of developers. This culture shift requires a deep understanding of the challenges developers face and a commitment to addressing them in a holistic manner. Here are some strategies and insights to guide you in enhancing DevEx within your organization.

Understanding Your Team’s Developer Experience

I’ve often heard executives describe how their team is feeling, using a narrative that feels at right angles to reality. I recall statements such as, “They’re excited for new challenges,” as the team struggles to understand our latest pivot. Another was, “People love working here,” when, in reality, the best devs had been interviewing with rivals for months. It’s not always easy to know how your team is doing, and while we can look at outputs, understanding developer experience is its own challenge. I’ve written previously about DORA metrics and how these useful statistics are unlikely to give a full picture.

Embrace a Holistic View of DevEx

First, recognize that DevEx encompasses everything from the physical workspace environment to the software tools used and the processes that guide development work. It’s about how developers feel about their work, how they collaborate with others and how they see their contributions affecting the broader goals of the organization. To truly understand DevEx, you need to look at the entire developer journey, from onboarding to the day-to-day tasks, and even how feedback and contributions are recognized and rewarded.

Conduct Regular DevEx Audits

Regularly assess the state of DevEx in your organization through surveys, interviews and direct observations. This can help identify pain points in the development process, tools that are not meeting needs and areas where collaboration or communication is breaking down. Use these audits to gather actionable insights and prioritize improvements.

Applying the Lessons

Once you have a picture of developers’ biggest points of friction, it’s time to start making things better for them. However, since the causes of these problems are complex, solutions are not one-size-fits-all.

Protect Your Engineers’ Flow at All Costs

Some lessons are old but still applicable: Leadership can make or break a high-functioning technical team. While it’s great to have someone to give good advice, organize tasks and assign work well; the most important thing an effective team lead can do is protect engineers from distractions and interruptions.

Experienced team leads will designate a single developer as the “hero” to be the one fielding technical questions for the whole team, and the team lead herself should handle questions from project managers and leaders about project status.

The most important thing an effective team lead can do is protect engineers from distractions and interruptions.

Ideally, developers will spend up to 80% in a status where they’re only minimally interruptible, able to research problems as needed and focus on the largest task at hand rather than constantly switching contexts. To further protect this focus, the next two points are crucial: creating robust collaboration and giving fast feedback to enable an inner loop of development.

Create Connection to Create Collaboration

At a board game night about a decade ago, engineers from totally separate teams were talking as they traded wood and wool tokens: One was tasked with identifying suspicious login behavior, and the other was offering the user prompts to let them know when their friends were usually online. What they realized over their cardboard tokens was that one could help the other: A tool that told you when an account was usually online could also show anomalous behavior from that account and help flag suspicious behavior.

With real collaboration developers and operations engineers can work together to reduce costs and make DevFinOps a real benefit rather than an awkward portmanteau.

A tool as simple as regular doughnut meetings can build the connections your team needs to wrestle complex problems.

A great developer interview quote from the article “An Actionable Framework for Understanding and Improving Developer Experience” shows how collaboration is the cornerstone of high-quality work:

“I really rely on information from my colleagues. So if I have this spontaneous connection to my colleagues around me, it is much easier to get information and just understand and communicate what needs to happen in certain systems.”

In the post-pandemic world of distributed teams, a tool as simple as regular doughnut meetings can build the connections your team needs to wrestle complex problems.

Faster Feedback

I’d initially titled this section “better feedback,” but in reality, slow, outer loop feedback is perfectly high quality, it’s just that it reaches the developer later than necessary and this interferes with a developer doing their best work.

As team leads and managers we must accelerate feedback to developers. The fabled “inner loop” of development harkens back to a time of a developer working on a local clone of a monolith: The dev can write changes, try them out, experiment and get feedback in a few minutes. When the dev sees code fail repeatedly, it’s easy to see what changed and how it broke things. With dozens or hundreds of opportunities every day to get feedback, a developer is faster and learns the ins and outs of their own codebase better. It’s no surprise that enterprise teams like Brex have an inner development loop as a core goal of their developer experience work.

Modern microservice architectures can’t be run on the developer’s laptop, but it’s possible to share a cluster for testing without affecting other teams. With tools like Signadot, they can easily access a shared cluster running near-to-production versions of services and resources.

Conclusions: DevEx Is Critical. You Can Help

Delivering on developer experience is not just a matter of implementing the right tools or adopting the latest technologies; it’s about creating a culture that values and prioritizes the well-being, productivity and satisfaction of developers. The insights from “DevEx in Action: A study of its tangible impacts” and the subsequent discussion highlight the multifaceted nature of DevEx and the importance of addressing it from various angles.

The journey to improving DevEx begins with understanding the unique challenges and needs of your development team. This understanding should inform the strategies and actions you take to enhance the work environment, processes and tools that your developers interact with daily. Protecting developers’ flow, fostering meaningful collaboration and providing fast, actionable feedback are foundational to a positive DevEx.

However, these strategies are not endpoints, but part of an ongoing process of evaluation and adaptation. The technology landscape and the needs of developers are constantly evolving, requiring a dynamic approach to DevEx. Regular audits, open communication and a commitment to continuous improvement are essential to keep pace with these changes and ensure that your organization remains a place where developers feel valued, supported and motivated.

To see how tools like Signadot have helped enterprise teams level up their developer experience, check out case studies from Brex, Earnest and the platform engineering team at DoorDash.

Top comments (0)