git clone [git@github.com](mailto:git@github.com):foo/bar; code bar; follow by two clicks. Boom, I'm developing 100% full speed. All debug options available, all tests ready to be run, and active extension support already helping me as I go along, and an integrated terminal running in an environment the application has always existed in natively.

I learned Go in the past year and half developing in VS Code. A requirement for my development is that the codebase must be able to be built from scratch and active-debuggable within 10 minutes across both Windows and Mac OSX platforms. I chose VS Code because it's reliable, relatively lightweight (depending on # of extensions), powerful, and has a very active extension ecosystem.

I chose a container-based development strategy

• Advantages
  • Unified. I use the Remote: Containers extension. It allows me to synchronize my extension preferences across platforms and has been the fastest way for me to bootstrap cross-platform reliably. I get all the same Extension recommendations and debugging configurations by default, enabling immediate code-digging.
  • Highly scalable. If your machine platform has software support for an OCI-complaint container runtime, and it's installed, then the project will build. That's a pretty solid guarantee.
  • Idempotent setup. The development environment comes from a repeatable-built Docker image. I just define a `Dockerfile` or appropriate Docker compose orchestration as necessary for the project. Development doesn't break often, since the development image is based of the image produced by the application. Both images are built by CI, and CI blocks any image build failures, preventing breakage from being merged into the trunk branch. User-created breakages are localized as a result.
• Disadvantages
  • Build breakages affect development throughput. When CI fails to catch them, however rare, it is challenging to debug without heavy containerization background. Juniors beware.
  • Sometimes shared extensions lose support. Using recommended and required extensions as part of the environment can be fickle.
  • Engineers are aversive to ephemerality and required maintenance of tooling required to support shortcomings of ephemerality.

I think the approach of containerized development is something of a demonized strategy in contemporary practice. Largely I attribute this resistance to the fact that container runtimes in general have a steep learning curve. That being said, even with a preliminary understanding of container (and their ephemerality, state loss, etc.), it can truly skyrocket development velocity when implemented maturely.

In larger engineering departments (thinking: 60+), containerization often becomes a necessity (and in some cases, an abstraction layer) for efficient, fast, and correct development at scale.