Tooltips: v2.0.0

Today I want to mention a couple of tools I’ve found useful to get developers up and running on a project quickly and safely.

Dev Containers are a specification to define development environments that run in containers. There are loads of tools that are compatible with the spec, but most commonly, I use them with VSCode. Essentially, they give you a way of preinstalling and configuring everything a developer needs to get going with a project and running all that in a sandbox.

I’ve worked with Dev Containers for a while. One nice thing about them I’ve found more recently is that I feel more comfortable giving coding agents like Cursor, Codex, or Claude Code broader controls when using them, since the scope of what they can easily affect is limited, in the sandbox. It’s not fool-proof: with the right kind of prompt injection attack, they could a) wreak havoc within the container b) potentially even break out of the container (highly unlikely). But it limits the attack surface, making it harder to run nefarious actions against other parts of your system.

Note: it does not protect in any way against attacks used to exfiltrate the code you’re working on.

Anecdotally, I switched machines recently and was happy to see that some repos I was working with had decent dev container configurations. I was able to get right back to work quickly with those ones. With other repos that either didn’t have a dev container configuration (or a bad one) it was much more slow and painful to get back to a productive state.

GitHub Codespaces are cloud-based development environments. It’s like running VSCode in a virtual machine in the cloud where the code for your repo is already cloned. You configure them using the Dev Container spec as well, so you can make sure everything you need to get up and running is pre-installed.

You might fairly ask yourself, “why would I need a cloud-based environment, if I can just run Dev Containers on my own machine?” The answer to that is twofold, in my opinion.

Here’s the first answer, as a developer: I like the deep integration with branches and pull requests, which allows me to easily spin up fresh environments to test and run code with all the tools I might want to use without the clutter I would get doing that locally.

The second answer, as a manager: when I’ve used GitHub Codespaces (or equivalent tools like Coder, Ona, and others) I’ve been able to onboard developers much faster with no mention of “it works on my machine.” Dev Containers on their own solve a big chunk of this problem, but cloud-based environments mean I can:

I can think of one example where I had developers working remotely with different operating systems and tooling versions. We spent days trying to figure out different intricacies in the system to get everyone aligned. When I decided to switch to cloud environments, everyone was up and running within an hour of onboarding.

Just keep in mind that the cost of running the cloud-based environments can get pricy.

So, with both of those I think you should be able to improve the speed at which you get your own projects up and running in the future, even if you change machines, or have other changes in your work environment. And I hope they help you work with other developers as well, either as a collaborator or a manager.

Those are my two, deeply intertwined tool selections for this episode of Tooltips. See you in the next one!