If your goal is detecting earlier configuration issues or limitations induced by the prod environment, it can be enough to have well maintained integration/test

If your goal is detecting earlier configuration issues or limitations induced by the prod environment, it can be enough to have well maintained integration/test environments. And I guess it’s basically the situation the author ended up with. You can have these running on the same stack as your prod (for instance in a similar kubernetes cluster, or at least on a mirrored config by the same provider if you’re on plain VMs), getting that much closer to test/prod parity. Most companies can afford one virtual env per dev, so the remote test environment becomes an extension of their local one. Demoing features offline should still be OK as well, you need everything setup locally for dev anyway. If the goal is to get people used to what’s running in production and train them to access the containers and debug them remotely, it’s another beast altogether, and reminds me of all the discussion about learning vim. It brings tremendous value to be proficient in coding in CLI, and not just for simple edits, but to actually be able to use it as the main coding tool. But then is it an efficient time investment for most people ? It’s pretty close to living your life in dim light because one day you’ll have to deal with a blackout and you’ll be super efficient then. It’s good to have a few people doing that, I’m not convinced it’s good for a whole team.