Optimal developer productivity is achieved when developers can direct their attention toward delivering business value through new features and improvements. However, they’re often bogged down with unreadable codebases, outdated tools or tech stack, and accumulating technical debt.
As a CTO, you may find yourself in a tough situation. New features are taking ages to develop. The budget is consistently in danger. Urgencies, putting down fires, and business-as-usual are taking their toll. The bug count is growing exponentially. Onboarding new developers seems like a mission impossible.
Sounds like your reality? Don't worry, there’s hope. Working hand-in-hand with CTOs in your situation is our bread and butter. Let’s explore what Developer Experience is, how it affects your product, and practical strategies to turn things around.
What is Developer Experience?
Many of you are probably familiar with Developer Experience in the context of software tools. It’s pretty much like UX, but the developer is your end user. For example, Stripe gained its popularity because of its developer-friendliness.
Opt for a popular & well-loved tech stack. When selecting the tools you use in product development, use those with wide community support and avoid outdated versions. Ask your development team preferences directly and allow them to impact your decisions.
The less time your developers spend fighting the tools, the more time they’ll have to grow your product.
However, we encourage you to adopt a broader definition of Developer Experience. After all, software tools are just one aspect of DX within your organization.
Let’s look at it from a product development perspective.
The broader definition of Developer Experience
Looking at the bigger picture is crucial. It’s more than useful tools. Sometimes, the answer to “why my organization’s DX is low” eludes you because it isn’t so simple. Let’s look at the broader definition:
DX is a level of satisfaction when working with your product.
Imagine this ideal scenario: a developer encounters your codebase for the first time. The structure is intuitive, clean, and well-documented, making it immediately understandable. As they dive deeper, they find the environment manageable or genuinely enjoyable. Along the way, adding new features is straightforward, akin to fitting pieces into a well-designed puzzle. Maintaining high-quality code standards feels effortless and rewarding — nobody wants to degrade what works beautifully.
Now, consider the opposite: the developer sees your code base for the first time and is overwhelmed. The code is complex and difficult to decipher. Outdated legacy segments clutter the landscape, while redundant or unintuitive lines of code add to the confusion. You can never be sure if you’re changing or breaking something. Documentation is sparse or outdated, turning simple additions into a complex challenge. Adding new features risks further destabilizing the system.
Your reality likely falls somewhere in between.
Before we delve into solutions, let's discuss what's truly at stake.
How does Developer Experience affect your product?
There is a strong correlation between DX and developer productivity.
The lower the DX, the longer it takes to implement new features. It can hinder your product’s growth, as software developers will spend more time trying to decipher the codebase and find a way to work around it.
First, they will try to read it, debug it, implement some changes, and see how they perform. Then, they’ll probably try to isolate the problematic part of your codebase – because otherwise, the amount of unreadable or unmaintainable code would increase.
…and only then focus on what’s important for you. This is particularly detrimental in competitive markets, where the ability to adapt and innovate quickly is a key differentiator.
Of course, this is even more prominent in legacy software. High complexity and accumulated technical debt can severely degrade the Developer Experience. Complex systems are harder to understand, modify, and maintain, leading to slower development and higher error rates.
The technical debt problem often arises when short-term solutions are implemented at the expense of long-term stability and scalability. Encourage your developers to focus on future-proof solutions rather than tickets.
When DX is very low, your code is downright unmaintainable. Somebody might propose refactoring the application. But even then, some questions arise. What if there are parts of the code that do what they should but are hard to understand? Then, the decision between rewrites and refactoring often involves weighing the immediate costs against long-term benefits.
How can you make your developers’ day-to-day life easier?
Actually, you shouldn’t be the only person who cares about DX. In most cases, you’re not. Because everybody who codes your product makes an effort to improve DX on a subconscious level.
Here are some tips to make your software development team’s life easier.
Some of them are not rocket science. But they work.
Temporary solutions
There's no time for elegance when a production bug needs an urgent patch. In such cases, a quick hack isn't necessarily bad but should be handled responsibly.
One effective strategy is to consolidate all your temporary fixes in one place, such as a [Hacks.js] file. Here’s how it works:
- Visibility. It keeps all your temporary solutions in one place, making them easy to track.
- Manageability. This method helps you monitor and manage your technical debt. Since these are not scattered throughout the codebase, they're less likely to be forgotten or overlooked.
- Accountability. Ask developers to include a comment on why the temporary solution has been used. By documenting the reason behind each hack, you maintain a narrative that justifies temporary choices and aids future revisions.
Ensure there's a plan to revisit and properly address these hacks, converting them into robust, long-term solutions when time permits. By maintaining them in a single file, you simplify the task of upgrading or replacing these quick fixes in the future.
Shorten build time
Sometimes, the process of building or compiling code drags on longer than a bad movie. When that happens, developers often dive into the abyss of less productive activities, waiting for the magic to happen.
A tweak here or there can often turbocharge your turnaround to minimize these not-so-golden hours. Take Flutter’s hot code reload, for example — this nifty feature rebuilds your code in real-time (faster than you can say "compilation complete!").
While technical constraints might occasionally throw a wrench in the works, striving for swifter solutions should always be part of your game plan.
Documentation is the underdog
Without clear motivation, many developers might not see the value in taking a detour to Documentville. That’s why your knowledge vanishes quicker than free pizza at a hackathon.
Here’s a pro tip: don’t just stop at API docs with the usual suspects like methods and parameters. Dive deep — think how-to guides, troubleshooting, and more. If your development team has already solved some hurdle, encourage them to write it down. Build up your team’s cheat sheet.
Foster a “writing it down” culture. It will pay off in the future. Encourage everyone on the team, especially senior developers, to document their knowledge and workflows. Building this culture not only helps mitigate the risk of knowledge loss when employees leave, but also simplifies the onboarding process for new developers.
Code style and “clever” code
It’s not just about tabs vs spaces.
Set up clear coding standards and use tools like Prettier or ESlint, leaving consistency and readability to the reliable hands of automation. Why wrestle with formatting when a machine can do it for you?
And remember: clever isn’t always smarter. Cryptic code can actually muddy the waters. Before you condense your code into a clever one-liner, pause and consider: would a junior developer be able to follow along? If the answer is no, it might be time to simplify. Clear code means a smoother ride for everyone on the team.
Automate what can be automated
Automation transforms repetitive manual tasks into standardized operations. This streamlines processes and frees up your team to focus on more complex, value-adding activities.
Setting up automations can be time-intensive, but consider the long-term benefits. If a task that takes five people five minutes each day is automated, even if it takes six days to implement, you will get a return on investment within six months. Within a year, you’ve recouped your time and then some.
You can also leverage AI solutions to speed up the software development process – we can show you how.
Start with:
- automating tedious tasks with scripts,
- automating the build process (CI/CD),
- automating feature branch preview deployments
to allow the best testing and PoC delivery.
Also, get to know your Integrated Development Environment (IDE) inside out. If your developers are unfamiliar with their IDE’s full potential, it can limit your team’s efficiency. For example, some may offer automations, like refactoring or other useful keyboard shortcuts and features. Foster knowledge exchange within your team. At Vazco, we organize sessions where developers exchange their best tips & tricks.
A general tendency for automation leads to shortened everything - including onboarding time. At Vazco, newcomers use the existing tools/scripts instead of figuring things out by themselves. Streamlining peer reviews, regular pair programming sessions and a mentoring system make onboarding a breeze – people are getting integrated into the project and the company simultaneously.
Use good OpenSource packages
OpenSource can work wonders, especially if you’re on a budget. You don’t have to put up everything from scratch. Use out-of-the-box solutions to speed up your developer’s pace and save some pocket money.
Use OpenSource packages that are actively maintained and have good community support.
Specific challenges – that’s where OpenSource packages shine. Take aggregations in MongoDB, for example. Writing it from scratch is sometimes easier than reading and understanding the code. In one project, some aggregations stretched for several hundred lines.
SparrowQL can instantly make it more readable. It doesn’t add new functions, changes the aggregation notation. It’s designed to improve DX.
Plus, OpenSource software is inherently customizable, allowing developers to tweak tools and systems to fit their specific needs. This level of customization can significantly enhance DX.
Why is your Developer Experience low (and how can you fix it)?
Before we show you even more solutions you can implement, ask yourself: what has led my product down this path? What is the root cause of poor DX?
These reasons why might surprise you.
Organizational culture
The culture within your organization can make or break the DX.
For instance, a culture that values rapid delivery over quality can lead to rushed code that is difficult to maintain. This “good-enough” culture doesn’t encourage innovation or experimentation.
Similarly, the structure of your organization can have a huge impact on DX. Cross-departmental silos create communication barriers and misalignment, especially when you silo away members of the same product development team: developers, product managers, designers, and quality assurance specialists.
The way an organization recognizes and rewards work is also a crucial factor. When recognition is based solely on output (e.g., features deployed, tickets closed) rather than on the quality of work or innovation, it does the exact opposite of encouraging.
Solution: shift culture towards growth and innovation
Promote growth and innovation
The growth mindset must be built into your processes – from peer code reviews and pair programming to mentoring and individual self-development paths.
Foster cross-functional teams.
Organize product development teams to include members from all relevant disciplines (development, product management, design, QA). This ensures diverse perspectives are included from the start of a project with regular sync meetings.
Give your developers the autonomy to make informed decisions.
Developers generally thrive in environments with some autonomy over their work, like choosing which tasks to tackle and making technical decisions.
Promote innovation time.
Allocate specific times when developers can work on projects of their choice, whether to explore new technologies, refactor existing code, or develop innovative solutions without the pressure of immediate deliverables. Pair programming can be your gateway to achieving that.
Recognize and reward quality work.
Adjust recognition and reward systems to value quality and innovation, not just output. Celebrate well-crafted code, successful refactorings, and innovative solutions. Allow space for mistakes.
Waterfall disguised as Agile
When Agile methodologies are adopted in name only, with underlying processes still firmly rooted in sequential Waterfall practices, you end up with a problematic hybrid often dubbed “Wagile.”
The Wagile hybrid has many faces.
- Sometimes, it’s a fixed-price project where you try to get more and more done without increasing the budget.
- Other times, projects may still be planned with a rigid structure, and once set, changes are discouraged or managed poorly.
- Or, developers might be expected to adhere to detailed upfront plans and extensive documentation typical of Waterfall yet also deliver working increments frequently as per Agile “sprints”.
This path quickly leads to pressure, excessive overtime, and inevitable burnout.
Solution: team morale reflects the quality of work
We get the picture. You’ve probably created the Wagile monster because you want to meet the deadlines with quality work on the budget. Lean can help you combat these challenges – we’ve written a separate article on the matter.
Don’t build the wrong feature or product
Creating something nobody wants or needs limits your chances of success and affects your team’s morale. In this scenario, your developer’s work doesn’t bring impact, which may lead to discouragement.
Iterative delivery with continuous feedback.
Shift to truly iterative work cycles that deliver working software frequently. Couple these cycles with constant feedback loops from stakeholders to ensure that the project aligns closely with customer needs and expectations. By doing so, you can increase the team’s commitment to driving the product forward.
Limit Work in Progress (WIP)
Assist your team in focusing on completing current tasks before taking on new ones. This reduces the cognitive load on developers, as attention is not split across too many tasks (context switching).
Regular retrospectives and continuous improvement
Hold regular retrospectives to discuss what went well, what didn’t, and how processes can be improved. This encourages a mindset of continuous improvement (known as Kaizen).
Recruitment and Onboarding
You’ve been there, you’ve seen it. The only senior developer who understands your system's intricacies finds the grass greener on the other side. Simply put, they quit. (Perhaps poor DX was a deciding factor? Who knows.)
So, you decide to recruit new developers or lead your juniors into a more senior role. If the second is what you opt for, the major barrier they will probably encounter is knowledge loss. Why? Because as soon as the senior developer leaves, all they know about your product or system flees with them.
So, hiring new developers probably won’t solve your problems.
Solution: Prepare for recruiting new devs even if you’re not planning it right now
Create a knowledge base
Build and maintain a centralized knowledge base where all documentation is kept updated. (Documentation can quickly become outdated, hindering new developer onboarding). This includes everything from setup and troubleshooting procedures to style guides and best practices. Ensure this knowledge base is easily accessible and searchable for all team members.
Establish peer review as a part of the process.
Thanks to regular 1–1 sessions, experienced developers can help rookies grow, and newcomers can ask questions that often lead to significant improvements. Each team member is up-to-date on changes to the project, reducing the risk of a single developer having exclusive insight into the features.
Implement comprehensive onboarding protocols.
Develop a structured onboarding program that includes mentorship, detailed documentation, and initial tasks scaled to integrate new developers into the team progressively. This program should aim to cover both technical and cultural aspects of working within your organization.
Succession planning
Proactively plan for the departure of key personnel by identifying potential future leaders. Providing them with the training and experiences necessary to step into more senior roles when the time comes.
What can you expect from a software development partner when you deal with poor DX?
Chances are, you’re dealing with an augmented team. Perhaps you’ve chosen to collaborate with a product development company due to your troubles. However, choosing the wrong partner can be your final nail in the coffin. That’s a topic for another day.
On the other hand, if you’re developing the product with your own team, there’s no shame in asking for a backup. In many cases, it’s best to start with consulting run by an external team. It’s a great platform for companies to exchange knowledge.
Here are the results of low DX projects we’ve dealt with successfully. Are we a good match?
Sapiens
No-code form composer used worldwide to define custom data flows and processes for the biggest insurance providers.
- ~1500h saved development time in total thanks to migration from multirepo to monorepo
- ~800h saved computing time of GitHub Actions each month thanks to cashing of build and lint steps
- ~100h saved development time each month thanks to local cashing
- ~45% shortening application build time
- ~80% accelerate page rendering time for the most advanced forms
- ~90% reduction of E2E tests flakiness
Fiero Code
Thanks to the end-to-end technical groundwork of the web application, this learn-to-code software platform is primed and ready to embark on new challenges in the upcoming growth phase.
- Improved Developer Experience and code quality, making the app easier to develop, resulting in significant future time-savings.
- Successfully managed technical debt and proposed code refactoring, resulting in better maintainability and faster development of new features.
- The core section of the application experienced a significant performance boost, leading to a 150% faster loading speed for pages with editors.
- The bugs or crashes are less frequent, less complex, and take less time to fix, partially thanks to the introduction of automated testing.
- Our work resulted in a much better technical base for project development, thoroughly preparing it for the future growth phase.
Closing thoughts
Good Developer Experience pays dividends in your team morale and performance.
In contrast, poor DX can lead to obscure, hard-to-maintain code, costly technical debt, and slower future development. Nobody enjoys working with legacy code, especially when building exciting new features is the alternative.
We've covered a broad range of tips to improve your DX. For more insights, or if you have any questions, consider using our pocket coach for engineering leaders – CTO Compass. It’s an AI assistant you can use anytime you need. Plus, it’s free.
Also, we're here to help. Reach out to us anytime, and let's make your development process smoother and more efficient.
Z.B.
category
Vazco
We build digital product fundamentally better, helping startups, scale-ups and enterprises multiply efficiency.
We specialize in innovative projects and build them fundamentally better. We help startups, scaleups and enterprises multiply efficiency by combining technological excellence with business experience. We specialize in JavaScript tech stack (React, React Native, Node, TypeScript, GraphQL), including niche technologies like Three.js. Moreover, we provide teams and processes focused on delivering value.
