TLDR

• Dev Containers are sold as optional but rarely are in practice.
• "Works on my machine" becomes "works in my dev container".
• Still need to deal with cross-platform issues between macOS, Windows, and Linux.
• Standardizing preferences (aliases, workflows, extensions, etc...) does not typically result in added productivity.

Introduction

I won't lie when I first caught wind of dev containers being released in VS Code I was extremely eager to try them out. Docker has been a tremendous improvement for deploying apps, but in my opinion it's an even bigger improvement for developing locally. Dev containers felt like an extension of that to make things even more standardized and avoid issues with setting up repos. However, after using dev containers now for the last year, I tend to prefer to work without them. For starters it locks people into using VSCode, which some might say is a good thing, but I'm of the mindset that people should work in an environment they feel most productive; if that's another editor, so be it. Even if you use VS Code you now need to come to agreement with the rest of the team on what extensions, settings, aliases, etc... will be used, which again means people may have to work in an environment that does not allow for their peak productivity. Also, it's great that you can abstract so much of the setup away, but when something goes wrong, which it will at some point just like your local machine would, you are now left debugging a dev container instead of your local machine. It also doesn't easily solve the problem of people using different operating systems. I’m not saying these problems are impossible to solve, but the time and effort required to build and maintain an ideal dev container often outweigh the value it provides.

Editor Lock In

What I always loved about Docker was that it allowed people to still work in their ideal editor and environment, but ensured that everyone was able to run the app the same way. However with dev containers you are immediately locking everyone into using VS Code. I get that standardization is appealing, but for a more senior engineer who might prefer another editor this can lead to frustration and a lack of productivity. In these cases I have seen the argument "well you don't have to use the dev container" which is true, but if only some people are using them are they really standardizing like people think? For a more junior engineer this might be appealing to them since it abstracts away a lot of the local setup, which is not inherently bad. I can only give my opinion here, but I feel my learning on local scripting and understanding how to work in the command line would have been stunted if I had a lot of that abstracted away for all the repos I worked in as a junior engineer. Maybe some people see editor standardization as a net positive, but I just think you should allow people to work how they are most productive, and that's not always able to be standardized.

When Preference Become Standards

Trust me, I am all for standardization where it makes sense, but when those standards start to bleed into preferences; I stop being a fan. The clearest example I have from dev containers I have used is aliases. I have built up aliases over the years for docker, git, terraform, etc... and coming into dev containers and having to relearn new aliases has been painful. Now I know this is a problem that can be solved with some time and creativity, but it also adds more overhead to know if people are using bash or zsh, if they are on windows, and ensure all those cases are handled. To me, that just does not feel worth the effort just to get dev containers to match a user's preference. Next up here is extensions; if you have used VS Code I am sure you have plenty of extensions that you have grown to love over the years, I know I have. The issue with Dev Containers is an extension I enjoy might not be something someone else enjoys using. Extensions are not inherently changing the standards on what code you deliver, so now you are making preferences standards by using dev containers.

Debugging Frustrations

One of my biggest frustrations when working with any repo, is pulling it down from remote and having issues getting it running. I thought having dev containers would make this even better, especially mixing it with docker to run the app. The challenge when these issues happen is you are now working within docker and not your familiar local machine. The amount of times I have had to completely rebuild my dev container and understand why I'm getting an error no one else is; just made me realize maybe these don't solve as much as I had hoped. Trust me, I am not arguing that these same things do not happen without dev containers, I just find that debugging local machine issues are a lot easier because of my familiarity with my local machine.

Conclusion

I fully understand the appeal of standardizing development environments, and for teams that already work in a highly uniform way, dev containers can be a good fit. Personally, I’ll be opting to keep them optional, as it reduces overhead and makes it easier to jump between repositories without additional setup concerns.