The dream of a standardized development environment

The content of this post can be summarized in one sentence: there are still people debating vim versus emacs (vim, obviously). Instead of engaging in this debate, I want to discuss the “dream” of a standardized development environment. Many companies and engineering teams strive to find the right tools for the job, but it is rare to find something that makes everyone happy. Often, I hear about “paved paths”, but there are pitfalls in this concept that we need to be aware of.

A paved path with the freedom to go off the path

In an enterprise context, there’s always this concept of a “paved path”, an easier way to do something. Common paved paths I have worked on (or with) include paved paths for microservices in Go, paved paths for configuring deployable applications and so on. I see value in a company trying to standardize and simplify some processes so that developers can be productive and focus on what matters most to them. This is great, but sometimes paved paths can constrain the ability to do things in a slightly different way that works best for different people. While some things are driven by regulations or compliance constraints that we can’t override, others are just a matter of choice. One of these is development environments where standardization can unlock some opportunities but also introduce challenges.

A paved path for development

Sometimes you have complex codebases for which it doesn’t make sense for everyone to figure out how to set up their own environment. I have worked in some places where setting up a developer workstation was a nightmare. At a previous job, setting up the tools to develop took developers a week. You read that right: a full week. This meant that if a new developer joined the team, they had to invest a week of work just to get their computer configured to do the job. This was quite an investment, which sometimes had very negative effects on the project: if a laptop broke, a developer working on a feature had to disappear for a week to configure their workstation again. What a nightmare! There’s a lot to be said about this situation, but obviously, an improvement to set up a working environment quickly and easily could have had tremendous benefits.

At GitHub, for example, we used to have scripts to setup a developer environment for the monolith, which were quite hard to maintain and often broke, requiring a relatively long time to reconfigure (not a week though!). The use of a single way to develop the project using a tool to simplify the bootstrapping process (Codespaces) has brought many improvements to the experience. The issue, though, is that it also brought many constraints on what developers can do, and not everyone is using the coding setup they would ideally prefer. The tradeoff is probably worth given the previous complexity in developing the project, but the reality is that every person is different, and preferences do matter.

You can’t tell people how to be productive

The reality of life is that we are all slightly different. I’ve seen people being extremely productive using vim with zero plugins and seen people productive only with extremely fancy and complicated editors. There is no right or wrong and there is no perfect combination of tools. The sweet spot between forcing people to accept tools and workflows they don’t love and giving lots of customization opportunities is hard to find. When we talk about developer environments, I’m all in for guiding users while allowing them to customize the setup as much as possible. Recently I closed a PR to add a DevContainer to ExternalDNS because it was making some assumptions on how to develop the project which were not right… For me. Those choices were definitely the right ones for the user and the intent was noble: try to increase and help contributions. However, the problem remains: it’s hard to tell users “this is what you should use to develop this project” and at the same time allow them to customize the setup as much as possible. Standardized DevContainers as a concept can create a constraint on what is possible to do (but not necessarily) and are a better tradeoff in much more complex settings where setting up a development environment is a true challenge.

Make it easy to apply your customization

I don’t want this blogpost to become tool long, so I want to close it with one thought: I think it’s hard to find a sweet spot, but I think it is key to make it easy enough for users to bring their own customizations, but at the same time provide a paved path for people that want to get started quickly. Finding this balance is a journey and it’s important to talk to users, peers and colleagues to understand what works best for them. It’s also important to understand that what works for us might not work for others and that’s not only okay, but also an opportunity to learn a new tool or explore a new perspective.