In today’s tech landscape, developers’ productivity has become crucial for companies. This has led to the developer experience (DevEx) concept — encompassing how developers perceive and engage with their work environment. Companies deploy various strategies, from offering free food to company-sponsored pet sitting. But the question is, are these working?

Recently, Microsoft enlisted DevEx expert Dr. Nicole Forsgren, a key contributor to the DORA metrics, to conduct a study on this topic. Based on the insights from the study, this article explores how companies can improve their developer experience including my experience as the founder of an internal developer platform company.

What is Developer Experience?

DevEx is how developers feel about their work and their value for it. It is not just about writing code but about doing it in an environment that is just right. All this depends on the right tools, practices, processes and social setup. The Microsoft study looked at three dimensions that are known to impact developer experience:
● Flow state
● Feedback loops
● Cognitive loads

CI/CD pipelines are key to an engineering organization’s efficiency, used by up to 75% of software companies with developers interacting with them daily. However, these CI/CD pipelines are often far from being the ideal tool to work with. A recent survey found that only 14% of practitioners go from code to production in less than a day when high-performing teams should be able to deploy multiple times a day.

Further, I will share strategies for enhancing DevEx by refining the continuous integration and deployment process. These strategies focus on optimizing flow state, cognitive load and feedback loops.

Rethinking the CI/CD Experience for Developers

Before changing anything with your CI/CD tools and process, measure what you want to improve and set goals. These can be based on current business priorities or past pain points. For example, DORA metrics like deployment frequency, lead time for changes or change failure rate. The more the better; you can set up metrics such as how much every step within the build, test and deploy process takes.

Avoid High Cognitive Load Tasks

Cognitive load is the amount of mental processing necessary for a developer to complete a task.

Companies generally have one programming language that they use for everything. Their entire toolchain and talent pool is geared toward it for maximum productivity. On the other hand, CI/CD tools often have their own DSL. So, when developers want to alter the CI/CD configurations, they must get into this new rarely-used language. This becomes a time sink as well as causes a high cognitive load.

One of the ways to avoid giving developers high cognitive load tasks without reason is to pick CI/CD tools that use a well-known language. For example, the data serialization language YAML — not always the most loved — is an industry standard that developers would know how to use. Even better, modern CI/CD platforms, such as open-source Dagger, offer SDK that allows developers to interact in the language of their choice, avoiding high cognitive load.

Keep the Flow State Intact

Flow state — known by many developers as “being in the zone” — is a mental state where a software engineer is fully immersed in work and can achieve maximum productivity.

Merging, building, deploying and running are all classic steps of a CI/CD pipeline, often handled by multiple tools. Some organizations have SREs that handle these functions, but not all developers are that lucky! In that case, if a developer wants to push code where a pipeline isn’t set up — which can be quite recurring with the rise of microservices — they must assemble those rarely-used tools. However, this will disturb the flow state you wish your developers to remain in.

One way to prevent that is to pick a CI/CD tool that provides a simplified deployment workflow for developers. Modern tools such as Mogenius and Qovery (which I am the founder of) are good examples. These tools streamline the deployment process by simply requiring the application source control repository link, thus automating the remaining steps seamlessly. Another tip is to conduct training sessions for developers on utilizing the CI/CD solution. Despite assumptions that software engineers inherently know best practices, this is only sometimes the case. By providing targeted training, companies equip developers with the knowledge to navigate the CI/CD tools effectively. Doing so reduces the risk of cognitive overload during the code deployment process and cultivates a culture of learning within the organization.

Instant Feedback Loops

In software engineering, feedback loops can be measured by how quickly questions are answered.

Troubleshooting issues within a CI/CD pipeline can be challenging for developers due to the need for more visibility and information. These processes often operate as black boxes, running on servers that developers may not have direct access to with software that is foreign to developers. Consequently, developers frequently rely on DevOps engineers — often understaffed — to diagnose problems, leading to slow feedback loops.

Ideally, developers should have complete visibility over the entire process and fix errors by themselves. Solutions like Datadog and Komodor go above and beyond to provide full transparency over CI/CD pipelines. They make accessible the logs and reports on why the build, test or deployment failed. Software delivery pipeline failures tend to be recurring; building an internal knowledge base of the most recurrent errors is also a good practice to speed up the debugging process from the engineering team. Integrating an LLM-based bot in your CI/CD dashboard is an even more modern approach to help developers navigate errors. The LLM should be trained with external and internal data (knowledge base).

Conclusion

These are just a few examples of how a company can improve its developer experience by tweaking its CI/CD process. Once you have decided on a strategy, look at your metrics and set goals for every quarter. Changing tools and getting your team comfortable with them can be time- and energy-consuming but is worth it. The study found that developers using intuitive tools and processes report feeling 50% more innovative than those struggling with unclear systems. And teams with tight feedback loops report 50% less technical debt than the ones with slow response times.