> I think we've gotten used to development environments being a shitty experience to the point where it seems part and parcel of programming…
I have staunchly refused to allow this at my current employ, and I’ve been there long enough where I can steer this.
This isn’t acceptable and all it does is help introduce inconsistency and regressions.
I realize I am fortunate in that I can effect change at my job in this arena.
Well the short answer is: I defined the workflow/process for our team, everyone bought in, and new people don't really have a choice but to follow along.
The longer answer is, earlier in my career I ended up spending a not-insignificant amount of time helping people debug things, and about 70% of the time the issue was their local build environment. Everyone did it differently and it was very messy.
I only made a few "rules" to follow. 1.) Your local folder structure must mirror exactly the structure in our central repo. 2.) Must use relative paths, which works when you follow rule 1. 3.) No ad-hoc "new shiny things" without team buy-in. If it can be used locally only and won't affect the team obviously I don't care.
Does containerization get you most of the way there? I feel like containerization + one of the tools built on top of nix (e.g. devbox.json) should get teams close to 100% there, that's my goal.
Agree completely. I used to allow every programmer to set up their own dev environment. Inevitably we’d have things that worked for one person but not another, and low confidence in deploying to production.
Eventually I forced everyone to work with a controlled dev environment on a remote server. They can work over ssh with command line tools or VSCode. Dev environments get rigorously maintained to mirror production. I got some grumbling about latency (everyone works remotely from around the world), but that turns out to present much less friction than the almost-daily debugging sessions and dealing with MacOS vs Windows vs Linux inconsistencies.