I believe the OP is referring to "local stack" i.e. being able to run a single command e.g. `make up` (if you're using makefiles) to spawn a local environment and run a "local" version of the site i.e. serving on localhost.
Having such scripts enables one to quickly setup a local environment to make changes and test them before submitting a Pull Request.
I've tried fixing the local dev stack - all of the scripts and Docker containers in the world still can't predict the ways in which something might break when it's running on 100+ different laptops with different developers with different unique preferences for how they like to get things done.
My expectation is that if you roll out something like Codespaces a small minority of your engineers will resist because it doesn't fit exactly how they want to work.
Meanwhile everyone else will get back several hours of productivity per week.
If the solution is to force everyone to do everything the same way... that's a political solution, not technical. That solution could just as easily have been everyone is forced to do everything the same way on their local machine. Maybe its more politically expedient to move everyone to a completely different cloud stack than to fix/standardize the local one.
> My expectation is that if you roll out something like Codespaces a small minority of your engineers will resist because it doesn't fit exactly how they want to work.
I'd expect internal support to be highly dependent on how terrible the alternative is. Beyond personal preferences, I'm really apprehensive about coupling all dev work to a single remote cloud provider. What happens if you lose internet access or when they inevitably go offline? In the case of the later, literally all work stops.
I work at a F50 that has a similar home grown solution. The nice thing is team members can customize their local machine however they want! Then for the actual dev env, its standard.
Works really really well when you allow your employees to explore and do what they want locally. Then when things break or go wrong (either I tweak something, or an incompatible Apple update lands) - I can just reset to the same dev env as everyone else.
It's fantastic. Spin up and throw away a dev env that is so much more powerful than my local machine could be (100+ GB RAM machines are a click away).
>I've tried fixing the local dev stack - all of the scripts and Docker containers in the world still can't predict the ways in which something might break when it's running on 100+ different laptops with different developers with different unique preferences for how they like to get things done.
Running on a remote environment may sidestep the issues of running on local hardware (poor virtualization, resource limitations, etc) but you'll have to standardize and automate the generation and management of your dev environments either way. Otherwise, you'll have the same problems in your remote space as you currently do locally, plus a few more possible points of failure (low latency network reqs, permissions differences, etc).
