March 29, 2023
min read
Developer Experience (DevEx, DX): A Strategic Guide
Presenting a strategic guide to help you understand what is developer experience, why does DevEx matter, and how you can improve your internal DX.
Presenting a strategic guide to help you understand what is developer experience, why does DevEx matter, and how you can improve your internal DX.
One of the main purposes of modern tools and architectures like Kubernetes and microservices is enabling your company to shorten the time to market. Microservices let you implement new features faster into your application, while Kubernetes makes scaling and zero-downtime deployments easier. But even the best and most modern tools won’t help you much if your developer experience (DevEx or DX) is poor. Arguably, you’d probably be better off with a somewhat outdated stack if it meant you had a premium developer experience. Why is developer experience so important? Read on to find out in this strategic guide to understanding what is DevEx, why does it matter, and how can you improve it.
Developer experience refers to how easy and straightforward or difficult and unclear it is for your developers to deliver software. It includes things like onboarding, documentation, deploying, and managing infrastructure — all the processes that developers need to follow, and how easy it is to ask for help.
The better the developer experience, the faster and more self-sufficient your developers will be. Poor developer experience means developers will spend more time looking for answers and following processes or trying to understand how to deploy infrastructure than writing code.
Developer experience is not something that you can install or implement, mainly because it includes pretty much everything developers need when doing their job. Therefore, it will vary a lot between companies. That’s why there isn’t any golden recipe to follow.
The best way to improve the developer experience is to follow the entire developer’s journey. Go through all the steps that developers need to go through, take notes, find bottlenecks, and mark possible improvements.
What does the developer journey usually look like? Below are the most common steps.
It all starts with onboarding, and it’s already a good starting point for improving the developer experience. The easier and more straightforward the onboarding, the better a developer’s first impression. The quality of onboarding also defines how quickly a new developer will start contributing to the codebase and therefore providing business value.
There are a few things that you need to check. First, the documentation. When a new developer starts, do they have a single all-in-one landing page to read? Is it up to date? Or do they need to read different documentation for different systems? Is it clear what to read first?
Basically, you should give the developer access to your systems and a starting point. After a few hours, they should know how your systems work because they were able to follow clear documentation. If they struggle to understand what to read next or they keep asking colleagues where various documents are, that’s an early sign of a bad developer experience. It’s not just “getting started” documents, it’s understanding how applications are built, what things depend on others, finding the dashboards, bugs, tasks, API documents, etc.
Enabling self-discovery of these resources reduces frustration and onboarding time regardless of whether you’re new to the company or new to a specific project.
But documentation is not the only thing you need to keep an eye on. The ability to find out who’s responsible for what is also important. Clear ownership helps developers know who to ask for access or help when needed.
Last but not least is setting up a local environment. There’s nothing more annoying for developers when starting a new job than not knowing how to set up a local test environment. Especially in the beginning, local environments tremendously help new developers understand the system. Getting from nothing to up and running should be straightforward and not error-prone.
Between your local environment and a source of always-fresh-and-connected documentation, developers can onboard and become productive fast without wasting their time or that of their team members doing something that should be routine.
Once the onboarding is finished, it’s time for a developer to start coding. This is a crucial step. Gathering requirements means finding all the necessary information to fulfill a given task. When given a task that’s not that difficult technically, you can expect the developer to deliver it by a specific time, such as in one sprint. Just keep in mind that delivering a task is half coding and half gathering requirements.
Developers will probably need to find and talk to the current owners of the service they need to work on. Often, the task itself will be described generically, so they’ll need to find the appropriate person who can clarify the requirements. This could be a ticket owner, service owner, or product manager All these “extras” can take a considerable amount of time.
Here’s where the developer experience matters. Poor developer experience will lead to difficulties in finding the answers to all these extras. New developers on a team will want to prove themselves. Being unable to deliver code on time because they spend too much time gathering requirements can be stressful and annoying. On the other hand, if finding all these extras is a piece of cake and a developer spends most of the sprint time writing code, that’s a sign of a great developer experience.
Once the actual requirements are clear, it’s time to do the design work. This is another step in a developer’s journey. And just like the previous steps, it can be challenging if the experience is poor. Design work requires finding all the dependencies for the part of the system they need to work on. They may need some additional infrastructure based on the task. But finding all the dependent services and understanding how they relate to the given task is not the end of the story.
The developer will still need to know how all those dependent services work, which in part means locating documentation and other salient information about them. Do they expose some APIs? If yes, what are the endpoints, how to use them, what are the limitations, etc.?
Internal portals provide a lot of value during this phase. Centralized service catalogs like the one offered by configure8 can help you drastically improve the efficiency of the design step.
As you can see, it took three steps to reach the building stage. That’s important to remember because many companies focus on improving the build stage alone. From a developer perspective, improving the developer experience in this phase consists of first understanding how much effort to invest in improving here and then deciding how to improve.
In terms of how much time to spend, carefully consider how often does your organization ask me to build new services?
Once you understand the relative importance of this phase vs. maintaining a system, consider templating capabilities, which determine how easy or difficult it is to scaffold a new project. But having a template doesn’t automatically mean the developer experience is good. If there’s only one template, it probably can’t be used for everything. Does the template include both frontend and backend services? Do developers actually use it?
Is everything automated, or does the template require manual steps to get it up and running? The answers to these questions will help you understand how good or bad the developer experience is during the build stage.
But templating is only half of the story. What happens after finishing a new service? Does the developer know where to put it? How easy is it to create CI/CD pipelines? Is the security clearance process straightforward? Does the developer know what the life cycle of the new service will look like? Is getting a production database for the service as easy as the development one? These are the things that will make the developer experience good or bad.
Even after the service is over, the developer’s journey isn’t finished. Depending on your company structure, developers may be more or less involved in the maintenance of the service, but they will be involved. For that, there are a few key things to pay attention to when it comes to developer experience.
Once you’re done building a new capability for a service, you’re not done. In fact, your journey is really just beginning. Understanding the usage, performance, cost, and reliability of your new feature is paramount to its effectiveness.
What used to be just classified as “maintenance” is now a living process that changes as the usage patterns and scenarios of what you built evolve over time. Making sure your developer experience in this part of the development journey is simple and effective is another key component of success.
You’ll be making changes, adding new features, making performance enhancements, deploying bug fixes, and more. For this, there are a few things that matter. First, how easy (or hard) it is to assess the blast radius when making a change? And how easy it is to find relevant information in case of an incident?
Having good information like dependencies, and metrics about deployments, such as the successful-to-failed deploys ratio or who made the last change to the service, give developers more clarity and confidence. Additionally, embedding service-level objectives (SLOs), monitors, and other performance and usage information in your service dashboard can help you understand the impact your changes are having on the overall service.
Now that you know what developer experience is, let’s talk about why it’s essential for your company’s success. Unfortunately, developer experience is commonly seen as something extra. It’s nice to have, but it’s usually not very high on the priority list.
The reality is that developer experience directly correlates with your development team’s performance and motivation. Developer experience simply defines how easy it is for a developer to do their job. So, a good developer experience is not a nice “to have.” It’s about providing your developers with the best tools and processes for the job.
Working as a developer in a company where developer experience is good means less frustration and fewer bottlenecks. And that means higher morale and better code, delivered faster.
If you’re convinced that you need to ensure your developers have a good experience, what should you do? The first thing is to simply ask your developers about their experience. Ask them what they like and dislike about their jobs. They will most likely be able to tell you right off the top of their heads what would make their job easier. Your job is to take that information and figure out how to make it happen.
Another easy way to improve developer experience is by using an internal developer portal (IDP) like configure8. A good IDP helps solve all the pain points mentioned above. With features like comprehensive awareness of all the applications, services, environments, and resources used in your system along with key metadata about them like dependency maps, ownership, documentation, CI/CD runs, tickets, KPIs, environments, and more as well as built-in incident response, configure8 brings clarity, fills knowledge gaps, and makes the developer journey more organized and easier to understand.
Developer experience is getting more attention these days, and for excellent reasons. It was overlooked for a long time, but it’s an essential part of high-performing teams. Sure, it requires a bit of effort to create tools and processes that create a good developer experience. But it’s an investment that’s guaranteed to pay off. Don’t treat it like a bonus. It should be obvious that it will make your developers happier and ultimately bring you many benefits in the long run.
Dawid Ziolkowski has 10 years of experience as a network/systems engineer at the beginning, DevOps in between, cloud native engineer recently. He has worked for an IT outsourcing company, a research institute, telco, a hosting company and a consultancy company, so he’s gathered a lot of knowledge from different perspectives. Nowadays, he’s helping companies move to cloud and/or redesign their infrastructure for a more cloud native approach.
Copyright © 2024 configure8, Inc. All rights reserved.
.png)
