One of my favorite things about being a consulting engineer and coach is all the setup when I join a new project. There's nothing like trying to get a project to build on a fresh, locked-down system when I don't know the environment, app, or support structure. Digging around for configuration and default settings is my favorite thing...
Okay. I'm kidding. As a coach, I tend to have other things to accomplish when I first land at a new client but that isn't the case for new engineers joining a team. What does the future of a developer's workflow look like? I definitely don't know but I would argue Microsoft has some ideas on the topic. Visual Studio Code is used by many clients and Liatrio engineers alike. It's flexible and extendable, giving people the ability to create the best environment for themselves. One of the best extensions for clean, reusable local development environments is Visual Studio Code Remote - Containers.
This extension allows teams to share easily repeatable development environments by committing configuration in their shared repository. A .devcontainer directory will live at the top level of the directory. It will contain Dockerfile and devcontainer.json files to be used in conjunction to get the environment running. This can be set up by using the Remote-Containers: Add Development Container Configuration Files command and choosing a starter environment.
Once the initial environment has been created the engineers on the team can add more details to the configuration files to cater it to the project. This can be adjusting the Dockerfile, adding scripts to create a better environment, setting default environment variables, VSCode extensions, and more! Any engineer who clones the repo will have the option to use the remote container environment. VSCode even notifies the user that an environment is available to use.
Why does this matter? As a coach, watching team members set up their tools and get onboarded was rough. Watching engineer turnover on teams during my 6 weeks with them was even harder. Someone new would join and it would take time to get them up to speed before they were able to contribute causing frustration all around. The ability to join and run the team's bespoke development environment right away, lowering the barrier to entry, can change a team's ability to get work done. It also allows the entire team to follow a configuration-as-code approach to development with pull requests, code reviews, and shared ideas. What this doesn't mean - everyone has the exact same environment. We still believe in using the right tools which work for you but this is a pretty awesome feature in VSCode. Team members can still install extensions on their own machine-like Vim keybindings, color schemes, etc. but keep the common requirements like runtimes, configurations, and tooling available and maintained as a group.
You can check out more details here on the Visual Studio Code docs.
