I currently use a Windows 10 dev laptop because I use it for other non-development tasks (ex. Creative Cloud) that require Windows. So I'd already need to run in a VM. And then there's the issue of making SSL certs and setting the hosts file to capture our domains, and installing all the build tools. I've got a 1.5 Mbps connection with horrible latency, my server has gigabit fiber somewhere in NoVa. With this, I can throw up a remote IDE with high quality plugins on our dev server, which is just a low-spec clone of prod. I can do a docker system prune and rebuild everything from scratch in seconds instead of hours because the npm packages download instantly. And it helps to stop "non working code -- push to test" commits in our GitHub.

Another would be developing ARM code using native ARM toolchains on a SoC board.

Scientific computing, specially when you'd like to do visualizations of data that is big/can't leave the server. It's also possible in Jupyter notebooks using port forwarding, but I don't see it for development involving data, as much as for data exploration or presentations.

Until recently I was stuck on a very locked down Windows machine (no vm, no docker, no admin rights..) while we target Linux on the cloud. The only way I could be productive is through remote development. We got macs and I still just develop remotely because the data in all in there.

My work involves a lot of smaller scripts that need to run on very large datasets. Git was impractical for the frequency of my pushes so I resorted to the old scp or ssh and paste to my workstation. With this I can streamline my whole process.

There are many cases where there is a desire not to have a company’s code base floating around on people’s laptops. For these folks remote development is a good option. It mitigates the risk of losing intellectual property.

My understanding is that much, if not all development at Google works like this. I don’t know their specific policy but a friend works on a similar project internally.

Google devs access the repo locally most of the time through a FUSE file mount. So the code is never written to local disk, but still accessible locally as far as you can tell.

(The other ways of writing code aren't publicly mentioned yet in any talks or papers that I know of, so I'll leave that one alone)

From the 2016 ACM paper.

> Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository

https://m-cacm.acm.org/magazines/2016/7/204032-why-google-st...

I've used something like this in the past when working with tools that are difficult to host locally.

Why setup your codebase and all the dependencies to run locally on a laptop when you can just spin up an instance on a server that matches your production environment and remote into it to work?

HIPAA - I want to be able to build data pipelines against patient data without the data itself leaving the server. Having my dev loop live on the same server as sample data is better than working against fake or synthetic data locally

Doesn't that just mean that the data is constantly leaving the server every time you run analysis on it? Or at least the reports on said data.

Potentially but not necessarily. Two thoughts:

1) I may not need to see the data itself during most (or all) of my dev loop, but just see any errors that are thrown.

2) Taken as risk mitigation, data temporarily cached in your browser is less risk than data permanently stored on your laptop, esp. when the threat you are mitigating is lost / stolen laptop.

If the reports contain only aggregated or de-identified data (i.e. no PHI) then that is fine.

Aggregate reports are fine flying on and off. Individual-level data, exactly the opposite.

I could see this being useful if you needed to get some work done and you don't have access to your usual development machine.