Developer experience focuses on sparking joy with the processes, communication methods, and technologies your developers use daily.
List of developer insights on the nuances of their day, and how addressing them can be the difference between a good and excellent developer experience in your organization.
Largest bottleneck for developer experience: Developers want out of this vicious bloated testing cycle.
What’s it like in the shoes of a developer at your organization? And which parts of their days spark joy for them or, on the flip side, make them want to throw their laptops across the room?
Answering these questions is one of the most critical aspects of nurturing a successful development program.
Your entire business benefits when your software engineers feel like they can perform their jobs well and are unhindered by inefficient processes, miscommunication, or technologies. Understanding and streamlining your developers’ daily jobs is part of developer experience.
Developer experience (DX), while a qualitative concept, can be measured quantitatively and improved with tangible actions. For example, some organizations focus on updating their automation, CI/CD pipeline practices, DevOps methodology, and testing, to create a better work environment for their developers. This, in turn, improves developer experience by removing barriers that would prevent them from doing their jobs well. It’s all about “tidying up” your developers’ processes and technologies so they can function better on a daily basis.
Consider Marie Kondo’s techniques for cleaning up houses: keep things that spark joy and retire the things that do not.
Developer experience focuses on sparking joy with the processes, communication methods, and technologies your developers use daily. It starts with picking the right tools, techniques, eliminating the ones that aren’t working, and fostering a company culture of learning, growing, and innovating. Some companies even employ specialized Developer Experience Engineers to improve this aspect of their culture.
But is developer experience just another buzzword being tossed around by executive teams, or is it actually a concern to the developers themselves? Well, it turns out that development teams aren’t quiet about what they think of DX. In fact, every developer could probably list the top ten blockers that impact their daily developer experience.
Many elements nurture great developer experience: culture, tools, product, talent, and DX-focused health metrics, to name a few.
But above all else, listening to your developers and their insights on the nuances of their day can be the difference between a good and excellent developer experience in your organization. Here are some top developer insight categories that support great developer experience.
When developers are writing code, they have to know where their errors are so they can fix them as soon as possible. If they have to go on a wild goose chase to find what’s broken, they’ll end up wasting time and getting frustrated.
Accurate, balanced alerts are very important for developers – not too many arbitrary ones and not so few that they’re left to guess what went wrong. Development teams can set up alerts using the right automated testing (to catch minor errors as they come up) and fine-tuning your alert process with the right technologies.
Unreliable, flaky tests are a common frustration for developers. Often enough, automated testing gets added onto developers’ plates as part of a CI/CD pipeline implementation. Because testing early and often is a foundational element of both Continuous Integration and Continuous Delivery/Continuous Deployment, teams can fall into the misconception that the more tests you tack onto the process, the better.
This is easy to believe because CI/CD highly emphasizes testing at every stage. But problems arise when blindly adding tests at each point of the pipeline rather than taking a strategic look at how each test runs, its accuracy level, and whether it’s a good fit for each stage.
Flaky tests are frustrating for developers because they never know if they can trust their results. And it’s terrible for the entire process because development teams get delayed trying to figure out if they need to actually fix anything or not. The best way to respond to this issue is by eliminating flaky tests and adopting smarter testing practices that relieve bloated testing cycles.
Related Webinar: The state of the art in tackling Flaky Tests
Developers must monitor test suites over time to ensure they work well with your team’s Continuous Integration practices. If your test suites are unhealthy, it becomes an endless cycle of a slow CI feeding into a slow test cycle, and so on.
Developers want out of this vicious bloated testing cycle. The best way to combat it is by consistently monitoring the health of your test suite. It’s important to retire bad tests rather than just adding on more and making testing bottlenecks worse.
It’s also a good idea to look for signs of entropy, such as an increase in test session time, a decrease in how often a specific test gets run, or tests failing more often.
Development teams also talk about the importance of automated, optimized documentation. There’s a strong dislike of actually updating and using documentation. This means that in situations when it would be helpful, documentation either doesn’t get used or isn’t accurate in the first place.
LaunchNotes is an example of an excellent solution for automating and optimizing documentation. It centralizes all product changes into one channel and lets you share your roadmap and updates with stakeholders. With these automated features, your developers don’t need to take care of documentation themselves. Plus, it’s much easier for them to reference and use insights from the optimized documents.
Related Article: Five Steps to Improve Developer Experience Immediately
Built by developers for developers, Launchable focuses on improving testing bottlenecks that developers toil with every day. We know developers are unburdened to focus on innovation with smarter, faster pipelines.
Predictive Test Selection enables developers to only execute the tests that need to run at each stage. This way, your developers don’t have to run all of the tests every time and take time waiting on all those results.