As software engineers, we spend a huge portion of our time writing or staring at dozens of lines of code in a weird language seemingly built by aliens 👽, day after day, creating incredible products and making our employers or clients happier and successful when things go well and on time.
But not all the glitter is gold everywhere, all the time. Sometimes, you join an organization or project where the only outcome is feeling tired at the end of the week or month - tired of skidding on ice to the point of feeling your legs hurting but realizing that effort didn’t make you go as far as you could. It can be a symptom of a poor DX.
What is DX (Developer Experience)?
We hear a lot about how important it is to make attractive and intuitive user interfaces and how customers value software engineered with thinking in ergonomic usability, strategically well-placed data, responsiveness, and simplicity, also known as UX or User Experience, the reason why most of the software companies have dedicated professionals to handle it.
In parallel with UX, the DX or Developer Experience is the experience we developers face regarding performing our work. Whether working on a greenfield project or an old legacy codebase, we usually join many companies with already consolidated procedures, frameworks, and corporate culture.
DX can be summarized as:
- Onboarding Processes: Efficiency in bringing new developers up to speed.
- Tooling and Infrastructure: The quality and integration of development tools.
- Documentation: Availability and clarity of internal and external documentation.
- Codebase Maintainability: Ease of understanding and modifying existing code.
- Collaboration and Communication: Effectiveness of team interactions and knowledge sharing.
- Agile and Organizational Processes: Appropriateness, flexibility, and effectiveness of agile practices and internal procedures.
- Management and Leadership Style: The degree to which management empowers developers, granting them autonomy, trust, and meaningful support.
Symptoms of a Poor DX
If you land on a new organization or project, it’s natural that you must grasp it all to rapidly become a user (or internal client) of others’ code and understand the “it’s how we do it here” whys.
At the same time, in the most successful, hence long-lasting companies, the original authors probably left the company a while ago. If you’re lucky, the code will be well-designed, and you’ll get some good and updated documentation. It’s rare, but I’ve seen it. I swear!
On the other hand, in work environments or projects where DX is neglected, developers might get constantly burnt out, frustrated, and blamed for not being as productive as they are supposed to be.
The constant feeling of failure can gradually affect self-esteem or, more seriously, bring the haunting ghost of impostor syndrome, making even the best developer doubt their skills.
So why does this happen to so many of us? Why might we end up so stuck and unable to express our creativity through what we do best?
Whether you are in a new environment or you just want to improve your workplace, the first action to take is reading the environment to spot some symptoms.
- Poor Onboarding Experience: New developers struggle to become productive due to inadequate support.
- Outdated Tools and Technologies: Relying on outdated tools or manual procedures can hinder productivity and lead to errors and frustration.
- Lack of Documentation: Insufficient or outdated resources that impede understanding.
- Overengineering Simple Tasks: Implementing overly complex solutions for straightforward problems.
- Inefficient Collaboration: Barriers in communication leading to duplicated efforts or misunderstandings.
- Heavy “Agile” Processes: Poorly applied Agile practices, overloaded with meetings and bureaucratic rituals, impede teams’ agility, productivity and innovation. ⚠️Update: I wrote a dedicated post about broken Agile over a year after publishing this one. Check it here.
- Micromanagement and Lack of Autonomy: Excessive oversight or controlling management styles erode developers’ sense of ownership, stifle creativity, and diminish motivation.
- Vanity Metrics and Misaligned Measurement: Evaluating developers through superficial proxies — lines of code, ticket count, or story points — creates perverse incentives and erodes trust. Developers end up optimizing for appearance rather than impact, while meaningful contributions like refactoring, mentoring, and documentation go unrecognized and unrewarded.
- Constant Context-Switching and Cognitive Overload: Fragmented schedules, excessive interruptions, and poorly structured codebases prevent developers from reaching a state of deep focus — commonly known as flow. When cognitive load is chronically high, creativity suffers, errors increase, and burnout accelerates.
- Lack of Psychological Safety: In environments where mistakes are punished or questions are judged, developers stop raising concerns, avoid experimenting, and hesitate to ask for help. This silent dysfunction compounds over time, masking real problems until they become critical.
Some Steps for Improving DX
If I had to choose one word to be a north to drive this, I would choose empathy. When being empathetic, you put yourself in the shoes of others; you care about new hires and how other developers will feel when understanding, using, and maintaining your code, reading your documents, and following your procedures.
You want to feel and to make your peers feel productive and empowered. You want to make their experience using your art as enjoyable and intuitive as a beautiful and self-explanatory user interface could be.
The days of being a non-replaceable nerd who writes unintelligible code that makes everyone else a hostage of an evil genius are gone for good. As a simple guide, you can start to change the game with:
- Streamlining Onboarding: Develop structured programs to help new hires acclimate quickly.
- Investing in Developer Tools: Adopt modern IDEs, logging tools, and CI/CD pipelines to streamline workflows.
- Improving Documentation: Maintain up-to-date and comprehensive guides for internal processes and codebases.
- Encouraging Knowledge Sharing: Foster a culture where developers regularly share insights and best practices.
- Regularly Gathering Feedback: Implement mechanisms to collect and act upon developer input regarding their experience.
- Refining Agile Practices: Continuously evaluate and adapt Agile methodologies to eliminate unnecessary meetings, reduce bureaucracy, and maintain agility, ensuring that processes serve developers rather than constrain them. True agility comes from agile people over processes.
- Empowering Teams: Cultivate management styles that give developers autonomy and ownership, building trust and accountability.
Symptoms of a Strong DX
On the other hand, as the organizational culture improves towards a good developer experience, you will start to notice (not necessarily all at once) some clear indicators:
- Rapid Delivery and Productivity: When developers can effortlessly master the tools, frameworks, and internal processes, the speed and quality of product delivery improve dramatically. Reduced friction means more time spent on creating value, helping teams meet deadlines and business objectives effectively.
- High Motivation and Engagement: Developers who feel supported by reliable tooling, clear documentation, and collaborative colleagues experience greater job satisfaction. This positivity fuels motivation, inspiring developers to invest their best efforts into their work, creating a ripple effect of enhanced creativity and innovation throughout the entire team.
- Sustainable Growth and Longevity: Organizations with a robust DX are resilient to team changes. Comprehensive documentation, maintainable codebases, and streamlined onboarding ensure continuity. Even when key contributors move on, the organization can efficiently onboard new talent, preserving its culture and operational momentum.
- Strong Industry Reputation: Companies known for excellent Developer Experience naturally attract and retain talented professionals. A great DX creates brand ambassadors and developers who happily share their positive experiences, enhancing the company’s reputation within the tech community and making it a desirable workplace. This is also reflected in social media and workplace reviews such as
GlassdoorandIndeed. I’ve used their criteria before applying for a new job, and so far, it hasn’t disappointed me. - Effective Agile Practices: Agile processes, when implemented thoughtfully, reduce unnecessary meetings and bureaucracy. This streamlined approach allows teams to remain genuinely agile, focusing their energy on delivering tangible value instead of managing processes, resulting in happier, more productive developers.
- Empowering Management Style: Good management empowers developers by granting autonomy and ownership over their work. Trust-based leadership fosters a culture of responsibility, accountability, and innovation, ultimately leading to greater satisfaction and improved outcomes. Future leaders and managers will naturally continue practices they experienced positively, ensuring ongoing empowerment and effectiveness.
- Meaningful Measurement: Teams rely on outcome-oriented indicators — such as delivery lead time, change failure rate, and developer satisfaction — rather than vanity metrics. This builds trust, encourages quality-focused work, and surfaces real bottlenecks instead of rewarding busywork.
- Flow-Enabling Environment: Developers have uninterrupted focus time, manageable cognitive load, and well-structured systems that allow them to enter states of deep work. This is where the best code gets written and real innovation happens.
- Psychological Safety and Open Culture: Team members feel safe to voice concerns, admit mistakes, and ask questions without fear of blame. This openness accelerates learning, surfaces issues early, and builds the trust necessary for genuine collaboration and innovation.
Final thoughts
I hope this resonates with you. DX is one of those things that’s easy to overlook — until it breaks you. Regardless of your position or rank, I encourage you not to settle for a poor developer experience. Your ability to drive change will vary with your influence, but you can always start from where you stand: write cleaner code, improve a README, simplify a process. Small acts of empathy compound over time and build the kind of environment where great work actually happens.