* Prox mox is great, but it's just a pretty GUI on top of some standard linux tools. My adventure down this path started when XEN was the new hotness and it was being run on dell hardware. Pick your poison here.
* VM > Containers. Your host OS doesn't have to match your host os in prod. Your VM should match your host OS in prod. If you want to run containers on that go for it, but I would work with more VM's... The moment you need to jam something into a container for debugging reasons (profiler, network monitor) the VM will have instantly won (cause your logging in and running apt/yum)....
* Find a style that works for you. How do you get your code from your dev system to where it needs to be? Fuse, Rsync, SCP, SFTP, does your IDE allow for remote dev (and are the systems close enough)....
* Figure out how you're going to deal with scripting: bash works great and you can do a lot with it, and make can be helpful. Sometimes you need more than bash (sometimes bash is the wrong tool)... There are a million choices like ansible, chef, puppet... you can sling around biarys (go/zig/rust)... And if your python/ruby/node, you can just install that everywhere. Candidly "portable binary" and a little bash has become the big winner here.
No matter what you read or look at its going to be a month where you feel "unproductive" cause your screwing around with remote dev. In that regard treat it like a new IDE getting set up or learning a new programing language. The reality is that unless you feel like your already a systems admin your going to spend a fair bit of time becoming intimate with infrastructure.
I now just have 6 core 12 thread 128gb am4 sitting in a corner for most of my day to day work. I can clone environments, make risky changes, run tests against them, and then go back work without being out of commission. When I do have compile tasks, those aren't competing with me responding to emails or doing a code review on my personal machine. The pain of setup opens up a LOT of "I can run this experiment" because you're NOT going to mess up your workflow for hours or a day doing them.
I shouldn't even need to say this, but don't make me waste onboarding time with setting up my development environment. You already know the project I'm going to work on, you already know what I will need, and you should already have a way to reproduce the local environment for that project; the only thing I should have to do is add my SSH key, and everything should work with only that.
Just give me access to a VM with low latency (<=50ms) and let me do my job there. You can set it up however you want, install whatever you think I'll need, configure VPC firewall however you want. Let me take and restore snapshots of the VM itself.
You're going to want something beefy too, for builds and stuff. For some reason, most projects I've worked on take at least 30 seconds (usually longer) between the moment I make a change until the moment I can see it, so not having to wait that much would be nice at least.
Yes, there's disadvantages. For example, you have to know that if I can't access it I won't be able to do anything (and not paying people because of this would be unfair). And also please ensure that other devs can't just sign commits with my keys.
But, as someone biased because I do most hobby development "remotely" (in a Docker container, or in a FreeBSD jail, or in a VPS at ~50ms latency), your scenario sounds nice.
Why are you saying this ? VS code was built with a client/server architecture so that it can support live collaboration from the ground up, which will probably solve the monitor resolution mismatch problem you mentioned. As for the odd ui and plugins, I'm not sure what you're talking about.
VS code is a bad idea for the same reason vim is a bad idea. I can and have sat down at someone else's VS code setup and gone "what the fuck is going on here".
Homginzied, uniform, boring, standard, these are the things you need to have going on to really make it work.
1. Everyone has to use the same IDE 2. Everyone needs to stop doing local dev.
That first one seems like a massive hurdle. It may be one. Vim users tend to look down their nose at IDE's. IDE folks think vim users spend more time playing in vim than working. And we all want to forget about people who use VS code. (I say this having 2 open vim sessions, 2 IDE's running and used VS code today to build some firm ware).
There really is one choice at this moment. Pick intellij (or one of their branded products) and code with me. Dont fuck around with VS code. VIM is NOT an option. You need everyone using the same tools so that you can work in files together (think dual cursors), or in the same tree concurrently. You also need to let someone take the wheel of your machine (think kvm/vnc) or you theirs and work effectively. Someones vimrc file is going to be disaster for you. VS code is just too incomplete and too easy to experiment with odd ui and plugins. If you have a die hard vim user then just put vim in your IDE... and lern how to toggle back and forth if loves vim that much.
This gives you a fair bit of the tooling your going to need. I cant stress enough that all of you are likely going to need desks, and matched monitors... You cant have one of you in 4k and one of you in 1080. Its going to be a nightmare when you need to share screens. And your going to want to share screens.
The other side of this is moving to remote dev. In an ideal world you all live in the same city, still have an office (or access to some rack space) where you could put a server and run prox mox on it. Everyone would get a VM (a whole, real VM) and then run containers/what ever they wanted on that. Why does same city/office matter. Because the spead of light is a bitch... if it takes a 1/3 of a second for the one team member across an ocean they are going to be really unhappy. If your all spread AND every one has good internet AND can poke the holes needed then set up a bunch of mini pcs's at everyone house... You can also just rent servers from someone like OVH (flat rate, unmetered bandwitdh) again pay attention to latency.
Why "remote dev"? 1. easy to backup / restore (even more so with a tool like prox mox) 2. You can now take risks, having back ups, not risking your dev instance do that dumb thing. If it goes badly just turn on the backup. 3. You can do this to someone elses dev env! If your having a problem or trying to recreate a complext bug, or chase an issue through a deep stack you can all trouble shoot on the same instance. Hell you can break that, restore and be back up and running in zero time flat.... At no poit is your personal work computer, with your mail/slack/logins ever at risk of getting knocked out.
The whole goal is to end up with a LOT of parity and a lot of access. You all managed to agree on a programing language, a data base etc... the rest of this is just furthering that standardization. It is going to feel weird, it is going to be rough the first two weeks but if you spend a lot of time with open voice chat and accessing and looking and making an effort to be involved in each others work your going to find you get a LOT of productivity gains.
It is a tough level of collaboration to maintain your going to spend the first month forcing it for an hour a day for 3 days a week. Your going to spend a bit of time over indulging (where you end up spectating too much) ... when you all get comfortable with it the exchanges just turn into "hey can you look at" for 5 mins here and 10 there with some weekly catch ups, group code reviews and really paring for the gnarly changes.