I brought an old under-powered Macbook I had not used for a year or two, but I was going to use codespaces so no problem to run the entire stack. I thought. Codespaces works great from my home office PC...
Constant disconnection meant I eventually gave up on codespaces to directly work on my machine, but then had to try to download the world (brew update, git cloning, a new JVM version, docker images, all new SBT and Scala binaries, transitive dependencies, etc). Granted I caused it by not pre-downloading a more up-to-date dev environment but I was not planning on using it locally. :/
Scraping nails on a school blackboard painful hours later I mostly only did theoretical changes, and spent most of the time chatting/networking.
What we did agree was to put in an offer to the co-working space to set up a decent mesh wifi that can handle lots of people downloading all of maven, using devcontainers, zooming etc. So that we can come back.
I can't agree with "perfectly fine" here. Not unless you enabled local echo in your terminal emulator. The keyboard latency, especially for typo correction, was maddening. I still remember what a staggering QoL improvement it was the first time I used a low-latency connection to a server.
I would hazard a guess that the main problem with in-flight wifi is that it is going to DPI'd beyond recognition.
So you're never going to know what is "real" packet loss and what is the DPI saying "computer says no".
The Sandvine/Procera[1] system that many (most ?) airlines use is an ML-based DPI that looks at absolutely everything in an effort to correlate obfuscated traffic to the actual flow. IIRC they claim 98% accuracy.
You can always develop locally if you're on the plane or w/e. In our case local builds try to use a remote runner if available if not they happen locally.
You need to install potentially large packages and images, commit code, and be clear in meetings - that’s a minimal standard for software and if someone can’t do that because they’re on some crazy kbps internet then they’re not suitable for the job.
Don't forget that you don't need a fast ping for development (with local env). "Good internet" is a very broad definition.
I have been working fully remote for years from a rural location. My only connection to the Internet is LTE and while it's decent most of the time, there are some days where it's pretty bad.
Luckily my dev environment is local first, which means that a few hours of high packet loss doesn't prevent me from being productive.
Congrats on trying to make a 35+ year old reference apply to remote work now.