Key Takeaways
Developer experience includes all of the technology, process, and people elements that software engineers come into contact with, as they write and implement code.
It might seem like a difficult task to measure developer experience, since it's more qualitative than quantitative in nature. But measuring operational elements of your SDLC is the first step to focusing on improving developer experience for your team.
As a software engineer, your daily tasks probably involve much more than just coding. And no, it’s not just you - the average software engineer only spends 32% of their time writing code.
“[Developers] spend 35% of their time managing code, including code maintenance (19%), testing (12%), and responding to security issues (4%). Another 23% is spent in meetings and on management and operational tasks.”
Many of today’s software development practices make it easy for developers to fall down the rabbit hole of extra tasks, distractions, and inefficiencies. And because of this, software engineers get frustrated and more likely to jump ship if their jobs get too distraction-heavy. Side quests are great for video games, but not for real-life development jobs.
Luckily, the industry is starting to focus on improving developer experience by creating a well-oiled development machine for software engineers to use daily. More companies are minimizing the number of non-coding tasks that developers have to complete, leading to better job satisfaction.
What is Developer Experience (DX)?
Developer experience includes all of the technology, process, and people elements that software engineers come into contact with, as they write and implement code. The technology could include tools such as source code repositories, automation engines, and testing solutions. The process includes documentation, compliance requirements, and the general “way things are done” at the developers’ organization. And people include all of the personnel involved in building the software from beginning to end.
Discomfort in developer experience comes from issues across these three categories: Pieces of your business’s tech stack may not play nicely together, processes might be difficult to upkeep across the organization, and different company culture elements might make it hard for developers to understand which tasks they own and how to delegate correctly to other team members.
Developer experience needs to grow alongside the implementation of DevOps methodology, which focuses on getting previously-siloed teams like development and operations to join forces. Without emphasizing developer experience, a move towards DevOps and agile methodology might become harder for developers, rather than making their lives easier.
Elements of Developer Experience
Developer experience works similarly to user experience- it needs to follow principles around usability, findability, and credibility for developers.Teams assess developer experience elements with the following three questions:
Are the tools and tech stack easy to use?
Can developers find what they need when they need it?
Are the tools and processes of good quality?
In order to answer “yes” to all of these questions, teams need to find the best ways to make the lives of developers easier. This might include streamlining processes with a CI/CD pipeline. CI/CD, which stands for Continuous Integration and Continuous Delivery or Continuous Deployment, puts the correct technology in place to minimize manual tasks and maximize quality and speed in a software development life cycle.
Taking steps to improve your tooling and processes will lead to a better developer experience. The CI/Cd pipeline is a great example of how teams are working to improve the day-to-day life of a developer, and where continued improvements are still encouraged.
Continuous Integration helps improve developer experience in a few ways:
Requiring a source code repository so developers don’t repeat work or create incompatible artifacts. This means that when a developer commits their code, they know that they haven’t just wasted time writing it, or that they won’t have to go fix it so it works with everyone else’s work!
Adding in build automation and automated testing, to minimize the number of manual tasks involved at the beginning of the SDLC. For a developer, this means that they don’t have to spend time manually compiling builds and running tests. And it also means that they minimize the risk of skipping a step by accident, and pushing a faulty build downstream. That’s a win for everyone.
Continuous Delivery can also help by:
Automatically delivering builds out of the source code repository into the test environment. Everyday life for developers gets easier with this step because it means that they don’t have to step away from focusing on code to move builds from one place to another.
Kicking off tests without human intervention. This also helps developers by removing yet another menial task that they’d have to run if Continuous Delivery wasn’t in place!
Continuous Deployment, which is just a more advanced version of Continuous Delivery, improves developer experience by:
Deploying new or updated code, directly from the test environment (if said changes pass the tests). This means that no one has to remember to do the monotonous task of deploying code!
Creating an end-to-end automated “assembly line” for your business. Continuous Deployment is for more mature development teams but when it works correctly, it completely removes human intervention from the equation! Developers just have to write the code, and automation takes care of the rest.
By using the CI/CD pipeline to streamline and automate all of these steps, an organization reduces the number of menial, repetitive tasks that your developer has to do.
Developer experience goes beyond the CI/CD pipeline, involving the meetings, documentation, process management tools, and people that developers engage with on any given day. With developer experience covering such a broad swath of elements, can it even be tracked?
How is Developer Experience Measured and Tracked?
It might seem like a difficult task to measure developer experience. After all, isn’t a person’s subjective experience and feelings about their job a pretty qualitative thing to measure? It turns out that measuring the operational elements of your SDLC can be a pretty good quantitive indication of how your DX is going. Here are a few places to get started:
Asking the big question, “where is the most time wasted within our SDLC?” Is there a specific type of drawn-out task that developers keep needing to do? Think about that one thing that’s causing them to step away from coding and in some cases, work late into the night. Fixing this step with automation or streamlined processes can make a world of difference for DX.
Identifying bottlenecks in software development. Is there something holding up your end-to-end production assembly line? For instance, does someone have to manually run tests that really could just be automated? Or are developers getting caught up in waiting on too many tests at a specific stage? Factors like these can cause major holdups, which leads to frustrated developers.
Keeping an eye on the time to production. Time to production can be a great indicator of how efficient your team is when releasing software. A long time to production could mean that something is going awry in your SDLC and that developers are having a negative experience because of it.
“If we are asking developers to be increasingly responsible for building secure apps, we have to make it as frictionless as possible for them to do so…we need guardrails not gates. We need a focus on usability and speed. We need reduced configuration areas exposed to developers. We need automation. We need developer experience.”
It’s crucial to run a data-driven pipeline for your development process. It’s all about understanding how your development process is going and finding ways to improve it from end to end.
Start Measuring Developer Experience Today
In many organizations, testing is often one of the top elements that make or break your developer experience. You can run an excellent CI/CD pipeline, but if the tests that you’re running throughout it are holding developers up, they are still having a poor experience.
That’s why we focus on making smarter, faster testing cycles. By running a better testing cycle, you can solve all three of the items mentioned above: less time wasted, fewer bottlenecks, and an improved time to production.
Fix developer experience entropy and start measuring your developer experience today with your test suite data and Launchable.
Quickly identify and remove flaky tests: which are tests that provide inconsistent results like false positives or negatives
Track developer cycle time: Keep an eye on stats like test session duration, test session frequency, and test session failure. If any of these seem to be going awry, that’s a good indication that your test suite is harming your developer experience by not running properly and needs to be improved.
Harnessing ML to run fewer tests, focusing on the right tests for a code change and nothing more. By choosing the right tests for each situation, you minimize developers’ wait time.
Launchable’s Dev Intelligence Platform improves developer happiness with faster, smarter testing, pushing more commits, and improving dev velocity. Harness the ML platform with just a 30-minute setup, and start identifying and running tests with the highest probability of failing.
