Hi, fellow Focused Generalist; it’s time for a new post! 👋🏾

Developer pain when moving to a new codebase

You’ve likely spent hours, or even days, trying to set up your environment for a new codebase. 

That experience worsens when you scavenge through out-of-date documentation. Then you’re left hoping someone on the team remembers how to get past those cryptic error messages. 

And if you’re a new hire, the pressure only multiplies:

“I’ve got to make a good impression, but this is taking too long!”

It’s draining. 😩

And worse? It’s avoidable.

The good news? This doesn’t have to be your reality.

Let’s talk about development containers—dev containers—a simple but powerful way to eliminate these headaches.

A better way to onboard with dev containers

Imagine a world where setting up a new codebase means:

• No cryptic error messages.
• No dependency hell.
• No guesswork.

Instead:

1. Clone the repository.
2. Open it in your editor.
3. Start coding.

That’s the promise of dev containers, a feature of VS Code that leverages Docker to create consistent, pre-configured development environments.

A few reasons to consider dev containers in your current project?

Frictionless onboarding:

Devcontainers bundle tools, dependencies, and databases into a reusable configuration file.

Imagine joining a team building a Phoenix app. The dev container comes preloaded with Elixir 1.18, Phoenix 1.7, PostgreSQL, and all required extensions, like ElixirLS. With one command, your environment is ready to go, and you’re writing code in minutes instead of hours.

Consistency across environments:

With dev containers, everyone works in the same environment, reducing bugs caused by mismatched setups.

No more “it works on my machine” nightmares!

Seamless multi-project context switching:

Devcontainers let you isolate environments per project. For example, if you’re working on different services with different stacks or dependency versions, you can switch from one repository to the next without doing anything on top of it.

What does a development container look like?

I announced the Elixir kick-off template for those who may have missed my previous article. I put together a development container in the template repository within that project. 

The project includes a pre-configured dev container to make onboarding seamless. This template allows anyone to spin up an environment preloaded with Elixir, PostgreSQL, and standard tools so they can start coding immediately. If you’re interested, check it out here.

Career reflections on onboarding

Thinking back on my career, I realize the worst onboarding experience took weeks. The documentation was outdated, and dependencies clashed. I spent so much time on Slack, Stackoverflow, and debugging. 

By the end of week two, I finally wrote my first line of code. But the excitement I’d felt on day one had turned into frustration. Worse yet, I knew future hires would face the same hurdles—days spent troubleshooting instead of contributing value. 

Capturing my steps in the onboarding document made it easier for others to onboard after me. But it doesn’t come close to instantly opening the codebase and running the application/service. Looking back, I realize how much time we could have reclaimed with dev containers.

Reclaiming developer time

Devcontainers are more than a tool; they’re a mindset shift. By investing a little time upfront to configure them, you can:

• Accelerate onboarding.
• Boost team productivity.
• Reduce environment-related bugs.

Closing remarks

Assembling dev containers takes some upfront effort, especially for teams without DevOps expertise. However, the ROI becomes evident when onboarding times shrink, and engineers can focus on delivering value instead of wrangling setups. It’s a tradeoff, especially for scaling teams or complex projects.

The true purpose of software engineering is to solve business problems and deliver impact. Devcontainers should be considered if environment setup comes in the way of landing impact. The time it takes to go through manual setup doesn’t warrant investing in automation, especially for a small team. 

No software project we’ll be working on will be perfect, and that’s okay. Everything is about finding balance within your organization. Regarding today’s post, teams should consider simplifying onboarding for the next team member when possible.

How do you manage environment setups today? Share your thoughts in the comments, or try dev containers and let me know how they transform your workflow!