RDEL #131: How does development environment setup affect developer experience and productivity?
Developer setup that used to take a full day was reduced to roughly 15 minutes after implementing a containerized Development Environment as Code solution.
Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership and apply the latest research in the field to drive to an answer.
Every engineering team has a version of the same story: a new developer spends their first day not writing code, but wrestling with setup instructions that are outdated, scattered across Slack threads, and broken on their specific operating system. And it’s not just onboarding. The same friction surfaces whenever a developer switches between teams or needs to spin up an unfamiliar service. This week we ask: Can treating your development environment as code meaningfully improve developer experience?
The context
Developer experience (DX) has become a major focus for engineering leaders, as research shows that how developers feel about their tools and workflows directly affects their productivity, retention, and software quality. Most conversations about DX center on processes like code review, deployment pipelines, or meeting culture. But there’s a foundational pain point that often gets overlooked: the experience of simply getting a development environment up and running in the first place.
Setting up a local development environment is deceptively hard. It involves hunting down documentation that may be outdated, dealing with dependencies that behave differently across operating systems, and absorbing tribal knowledge that lives in people’s heads or buried Slack conversations. For newer developers, this can be demoralizing. For experienced ones, it’s a known tax they’ve learned to tolerate. As teams grow, diversify across platforms, and ship more integrations between products, the cognitive and time costs compound.
The research
Researchers from Aalto University conducted a study within a Finnish software company to examine how development environment setup shapes developer experience and propose a new solution. The proposed solution, which they call Development Environment as Code (DEaC), uses containerization and automation to define, deploy, and replicate a local development environment from configuration files -- eliminating the need for manual setup. The team ran a focus group, semi-structured interviews, continuous participant observation, and external validation of the resulting design principles with seasoned software professionals from outside the company.
Key findings from the study:
The setup process follows a repeatable, costly cycle. DX during environment setup is shaped by three mechanisms: obtaining information, processing it, and using it to install tools. The most frustrating steps were the first two. Hidden, scattered, and outdated documentation drove the most pain. As one participant noted, “People just share information in Slack and if you have to install something additional you might not know about it.”
Manual setup can consume days of developer time. One participant recalled that setup “took like one day to resolve all of the errors” -- compared to roughly 15 minutes after DEaC was implemented.
Cognitive and emotional load from setup are underestimated. Participants described frustration, anger, and stress -- particularly when teammates were waiting on them. One developer noted it gets “too frustrating in the end. Especially if others are waiting for you and expecting some results from you.”
DEaC reduced friction and improved cross-team collaboration. After implementing the containerized solution, developers reported faster, more reliable, and less platform-dependent setup. A lead developer summarized it this way: “Every developer, especially new developers don’t have to solve the same problems. New developers don’t have to fight with the problems with development environments.”
External practitioners rated the design principles as addressing a real and important problem. In an evaluation by six practitioners, the importance criterion received the highest score (mean = 3.5; overall agreement = 100%). Principles were also rated accessible (88.3% agreement) and actionable (67.7% agreement)
The application
Development environment setup can be a meaningful drain on developer experience, onboarding success, and team productivity. The good news is this is a problem with a concrete technical solution: automating setup through containerization and configuration code cuts cognitive load, eliminates hidden knowledge, and creates consistency across platforms.
Here are three things engineering leaders can do to apply this research:
Audit your current setup experience by role and tenure. Ask newer developers how long environment setup took and what blocked them. This surfaces friction you’ve likely normalized. If setup regularly takes more than an hour or generates more than a handful of questions, it’s worth investing in a DEaC approach.
Containerize your most complex or shared environments first. You don’t need to automate everything at once. Start with the product or integration environment that’s most painful to configure. Even a partial DEaC can dramatically reduce time-to-first-working-environment for new developers and cross-team contributors.
Embed documentation inside the environment, not beside it. Add setup instructions and configuration notes directly into the DEaC configuration files. This keeps documentation in sync with the code, reduces hidden knowledge, and makes it easier for developers to self-serve without hunting through Slack or wikis.
—
Happy Research Tuesday!
Lizzie