I would have agreed until I started working at Google. Also, you should completely avoid having Remote Desktop and instead use ssh + an editor that works with remote files.
At Google we have a custom fork of VSCode running in browser and builds can either be distributed or run on my Linux VM to utilize build cache.
I liked it so much I started doing a similar setup for small side projects. Just boot up the Cloud Console on GCP and start coding.
Advantages are:
- Accessible from anywhere (I use my pc, my laptop, etc. The env is always the same)
- More compute (I can attach more CPU + more RAM flexibly)
- Less friction to start (minimum environment setup, most tools are preinstalled)
There are some adjustments that need to be made to your workflow. And for some applications you are dependent on having the correct tooling. However, my personal prediction is most companies will move to this type of development workflow as the tooling improves.
There is one more point I would like to add to the "less friction to start." This is the killer feature for education.
No more do students have to set up their own envs. Figure out PYTHONPATH. No more do educators need to debug installation issues on 3 different OSes.
Teachers distribute a pre setup env which they know works for what they are trying to teach. Students go straight into writing code and building things with minimum friction.
Learning to set up your env can be punted to a problem for later.
Learning to set up my environment to compile my first MUD back in 1999 was my first introduction to Autotools, ./configure, make, etc. I was motivated to solve the problem because I wanted to tinker.
I'm sure someone will say I'm gatekeeping, but seriously these low-level skills have served me my entire career, and I wonder what happens when every dev environment is just a docker pull away. Who learns how to build new environments?
That said, I have recently been tinkering with the Flipperzero firmware, and compared to the old Rockbox days when you had to install an arm-elf-gcc toolchain yourself and pray, embedded development has gotten way easier and this doesn't seem like a bad thing. I don't have an answer, just something to think about!
Its not necessarily gatekeeping, its just assuming that all others who come through are also motivated in the same way you are. Reality is that the same experience likely discouraged countless others and prevented them from pursuing development.
I'm the same as you, but I recognize not everyone is.
Feels like this is happening already. There is no incentive to learn the fundamental concepts. We need more people interested in the why, and not just a quick buck. Folks interested in the why is the only reason we are here to begin with!
On the other hand....it's great job security! Less and less people understand networking everyday it seems!
The kinds of things people are talking about - fiddling with autotools or PYTHONPATH - are not “fundamental concepts” or “the why” behind anything. It’s just tedious, boring nonsense. There are plenty of intellectually curious people who would be turned off by this stuff.
In my experience, "tinkering" with an environment before getting any code working was a recipe for believing "this is too hard, maybe I'm not smart enough to do this".
Getting a feedback loop early on is so important. Once you're convinced that you can write software, setting up an environment starts to look like a tractable problem.
Think of it like a product funnel. If the goal is to get people to learn X, making them learn Y as a barrier first is unnecessary. You risk people abandoning the funnel that way. It's still entirely possible to learn these tools some other way.
Yes, but if learning X beforehand required learning Y, then we might be expecting the value of learning X to be the combined value of learning X + Y.
It should be noted when adopting this approach, that you're lowering the expected value from the people who make it through the funnel. This may be counteracted by more people making it through the funnel, or it may not. The delta in total value is completely unknown.
Those who make it through the funnel with only X are likely more than the X+Y scenario simply because it's less learning and new concepts so drop out will be reduced. This cohort are probably more likely to go on to learn Y if we further assume it was so valuable as to have been "required". In reality requiring X+Y backfires as step 1 because X is all they want and X may be worth 10Y to the student at step 1. The value of Y may increase to >X after learning X.
When I learned basic HTML, CSS and JS. On step 1, JS had essentially no value. CSS sounded like it had value but was a bit nebulous and optional sounding. HTML seemed like an obvious requirement for building a website, so that's where I started. Once I learned HTML, the value of CSS became obvious and I pursued it. JS still seemed esoteric but later once I got HTML/CSS down and wanted to do more JS kept coming up as the solution. So I learned it too. Now, I'd say JS is way more valuable to me than HTML/CSS even though I learned it last.
This was in the 90s BTW and the path wasn't very clear back then. The first book I bought was actually a Perl book and quickly realized it was too advanced of a place for me to start. I learned about Perl after noticing the /cgi-bin/ portion of URLs and wondering what that meant. It had to be something most sites where doing similarly. This was before Google so whatever random SE I used back then told me cgi-bin was associated with Perl scripting for web development. I continued to struggle with the backend stuff (JS was FE only back then) until PHP3 came around. I'm self taught if that wasn't clear.
I mean, if you're self taught, you can take whatever path you want.
My comment was in the context of students, which generally is backed by public funding. I'm worried about getting less value for the same number of public dollars. That being said, maybe it does still work out as an increase in total value, we should probably do a study on that.
That being said, I'm self-taught too, so I actually benefit if these classes provide less value, as it's easier to convince business folks to hire me instead, but it's the principal of the matter in this case (also I'm not really competing against recent college grads anymore).
I think the problem here is ordering. At the end we probably want them to know X and Y but we would rather they learn X then Y.
But to learn X they need to do some steps from Y.
If we can remove those steps we can make more people learn both.
But also in practice I don't think anyone struggling to set up their env before writing a line of code is learning much. They are just following arcane instructions until it works.
> wonder what happens when every dev environment is just a docker pull away
They learn later, when/if they actually need it. And for those who turn out to be unwilling or unable, well, there wasn't much chance they'd have taken the same path as you, anyway.
Speaking of paths, specifically path dependence, autotools and friends really are monstrosities and should rightfully be relegated to history. I hope that simpler, easier environment building really are the future, as you hinted.
If they're so helpless they can't figure out how to even get to an environment other than their corporate standard one, then they have, again, already exited the pipeline before this conversation becomes relevant. Someone incapable of setting up a linux vm was never going to do original ops work, regardless of what the computing ecosystem around them looks like.
> Autotools, ./configure, make, etc. I was motivated to solve the problem because I wanted to tinker. I'm sure someone will say I'm gatekeeping, but seriously these low-level skills have served me my entire career
What skills? 95% of using autotools etc. is tedious memorization or copy-paste, not something you learn anything useful from.
> No more do students have to set up their own envs.
That straight up sounds dystopian though. Speaking as someone who makes software for Linux machines, I'd really hate to hire someone that doesn't know how to play around with the OS side of things.
Handing someone a pre-built dev environment and playing god with them sounds like a great way to get stupid programmers who can't architect.
Check out Repit.com. They’ve added the ability to add dependencies. Having an easy way to hack on some Java with Maven dependencies already installed is pretty great.
I think this is possible using GitHub Codespaces as well…if you have a Java project with a Maven POM, the deps in the POM will get loaded at runtime.
I haven’t tried Python yet, but would imagine it’s similar. It’s all containerized, so you effectively have CI/CD you just don’t see it.
Huh? It's not like the children aren't using Google and Microsoft services by the truckload already. Every single one has Android/iOs phone. They use Gmail and YouTube and browse the web. And the schools use it too - MS Windows, Office, Google Classroom, Drive...
Practically nothing changes with a cloud desktop.
You mean a fully locked down device that allows no tinkering at all. Then they graduate to college and they're again suggested to use a fully locked down environment with no tinkering at all.
The flip side of this is that it's hard to do anything beyond the standard library for some languages. Using PythonAnywhere is great for std-in/std-out programs, but I couldn't figure out a way to import graphics libraries and such. The web is pretty limiting when teaching with anything other than JS/HTML/CSS.
env management is pretty easy considering tools like conda are out there, that will carry you pretty far especially in terms of education. you could create a conda env specific for your class and just email the yaml. its also easy to write a script that will install miniconda and build these needed environments
Remote desktops can work great if you constrain and structure what you do in them.
For me, this means not using traditional desktop environments like gnome/kde/windows/macos, but instead a full screen tiled window manager (i3 in my case) with different virtual desktops assigned to different work items.
Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop).
The result is I never have to search for a dev task related tab or be unsure if the code I'm running is the code I'm editing (which can happen if you are working on many concurrent changes).
I liken the setup to the keyboard-driven text terminals you still see in some shops, hotels, and airport check-in desks.
In general, I think smartly crafting your workflow matters a great deal more than the particular tool you might use.
> Each virtual desktop is split in half between the IDE (vim in my case) and a terminal session for the code under development in that IDE. That's it. No silly weather or chat widgets (all that lives in my local laptop's traditional desktop).
I don't disagree, but if your editor is vim and you run/test in a terminal, why not do the whole thing in tmux in SSH?
Some of the software has a GUI, and some of the tools (i.e. unit test runners) display their output in a locally (to the remote desktop) running web app viewed via a browser.
If I were doing strictly text-based work, I might use tmux, but to be honest i3 scales down so well to the text-only use case that I probably wouldn't bother, since there is no upside to doing so.
Sure, but it's a lot easier just to open a browser in the remote desktop session. It's not like the FPS of the browser matters much when looking at unit test results.
On the 'cloud' (really our own cluster) we use at work most of the nodes have 16 cores and 128gb of memory, its a much beefier system than what is available locally.
> Also, you should completely avoid having Remote Desktop and instead use ssh + an editor that works with remote files.
That's kinda stretching the definition of a 'desktop', isn't it? The sort of tasks someone uses Remote Desktop for seldom overlaps with what someone uses SSH for. Also it doesn't seem to be the point of the article:
Article: > I'm also going to restrict this discussion to the case of "We run a full graphical environment on the VM, and stream that to the laptop"
Though I think it could still work if the applications are built with this in mind. Think Google Docs, Sheets etc as cloud replacements for local Word, Excel.
SSH and Video aren't the only two protocols to interact with a remote machine.
There's not really a way around network dependence when coding at Google. You're not allowed to have code copied to a laptop, unless you get special permissions. Only teams that work on client code like desktop apps are likely to be given access. So this means to even look at code, you have to be connected to the network (via Chrome or a Fuse-based VFS.)
If you're using a desktop, there's not really a case for going offline, so being dependent on the network is ok.
I get nearly all my work done off a laptop, but I do find its weak CPU/memory a mismatch for my heavy use of Chrome.
Damn, when you said Google I thought you were gonna talk about Cloudtop, etc. +1 to your recommendation, but they do a pretty good job Cloudtop too(for non-power users it is pretty usable).
Yeah, to be clear for Google work I am talking about the combination of Cloudtop (VM), Cider (IDE), Blaze/Bazel (Builds).
In addition you also need a version control / file sync system.
It's also nice to have some kind of network proxy especially if you are doing web dev. Tools or web services run on the VM and you just access it directly through the proxy on your local browser.
The integration/combination of these is what allows things to work.
For personal code this is Google Cloud Console. You can actually just jump into it . It has a built in VS Code editor.
But at home it would be GCP VM + VS Code + Git.
GCP also has built in proxy. The only problem I have had so far is it doesn't rewrite URL's which can be an issue for web apps. I think it's solveable I just haven't really tried yet.
Theres some other solutions in the other comments as well.
You also should mention the use of CitC. With CitC, I can build/write code from my work machine at the office and then go home and gmosh into a cloudtop that uses the same network mounted filesystem.
I thought network filesystems were a terrible idea until I used citc + piper, really two incredible pieces of engineering infra. So many problems are reduced to just writing files to disk if you have a magically disk that acts like it is infinitely sized and everywhere all at once with low latency and versioned by the second. Whatever promotions they offered those authors and maintainers, and whatever black magic they had to invoke, it really was worth it.
Yep, I sorta glossed over it with file sync. But I guess CitC is more than that. Its more like a workspace sync.
It acts like a view of the monorepo and holds whatever changes you make. Additionally it integrates with your version control and holds its state as well. For example any local commits or branches.
And this can all be accessed from the browser or the CLI on any connected machine.
There are many ways to approach this sort of thing. For example I work similarly, all code running on a powerful slurm-managed cluster that i can access using anything with ssh, but I just use stuff like tmux and cli editors that are already installed on the server rather than use a gui based editor. we have an lmod system with prebuilt packages of a lot of software we typically use with various versions represented, and we also use environmental managers such as conda/mamba and workflow control tools which are straightforward to use. Seems simple enough imo.
IMO you don't really need it to be a full vnc style remote desktop although, or even have the editor run in the browser. You can get equivalent results with bazel[0] remote execution + cache servers and get a similar horizontally scaling build system, without vnc style jank or full network dependence for your actions as a developer.
Another reason why google likes the remote dev experience is because it doesn't download code to the developers laptop, because they don't trust them.
They said they were using it for side projects. Even if Google is subsidizing the bill, I'm interested to know how much something like this would cost.
assuming ssh and not scp, replacing traditional ssh with mosh in this setup could prove for some interesting benefits wrt network dependency. If the connection was less brittle, and directories could be opened and cached and rewritten later on, after the connection was disrupted and re-established…that’d be awesome.
It’s probably the minority, but I think there are people who it’s helpful for.
For example, I travel with an iPad Pro and a work laptop. If I want to tinker one evening, I can use my iPad instead of bringing a personal laptop. (This also applies to cloud gaming for some people, but I haven’t done that personally).
My partner is also a software engineer and we have a toy server at home with various things running in it (eg game server, home assistant, vpn etc). We have a VSCode instance running so either of us can grab a browser and update the configs, without deal with being in sync. (Imo this is the “most obvious” use case - modifying remote files without worrying about sync).
At work, I also have this setup. (My school had something similar too, just less polished because it was a while ago) The benefits there are big too. Besides everything mentioned before, it also means that there’s basically zero setup time. If you break your laptop, or forget it, or whatever, IT just hands you a temporary chrome book which you log into your work from a browser.
By comparison, my old job pushed a bad MacOS update that bricked my work computer, and they made me remote into a windows VM (AWS workspace) from my personal laptop to do work until a replacement arrived. I lost all my work/files/etc since it bricked unexpectedly, and that job had remote Linux VMs so I had two levels of indirection. Then I had to set everything up again, so I easily lost 3+ weeks of work due to that incident.
I have a website with a worker process doing RSS parsing that occasionally fails. It would be quite nice to be able to spend 10 minutes fixing trivial bugs from my phone while I'm out and about. Or from my iPad. I'm not doing feature development but this would be nice to have for things that are so easy I could do them now but instead must wait hours or days until I'm back in front of my dev machine.
And actually I have a desktop and a laptop that I do dev work on. More than once I've started a branch on the desktop one night but don't quite get far enough to push it up and the next day I take my laptop to the coffee shop and realize the code is still at home.
I mean there are always going to be niche uses for this.
My point is about corporations adopting this sort of a thing because executives got sold on a fancy feature "Accessible from anywhere" but no one really materializes it for 99.99% of the time they are not coding from anywhere but have to suffer latency the entire time.
> executives got sold on a fancy feature "Accessible from anywhere" but no one really materializes it for 99.99% of the time they are not coding from anywhere but have to suffer latency the entire time.
This isn’t the pitch. Not at all. The pitch is “no code (or IP) on local machines that can be stolen” and “no downtime if laptop breaks… IT desk can keep a stack of chrome books ready for backup”. Combined with something like gmail and google docs, the laptop at some employees WFH house contains no business secrets ever.
I’ve never experienced the slightest drag of latency with this approach. If you’re running a compiled language, the compiler is surely the bottleneck. If you’re doing it for work, they’ll probably set it up so it’s always regionalized close to you from a cloud. Maybe fly.io should pitch this.
As a director in a previous job a few years ago I almost introduced apache eclipse orion to our organization strictly to reduce issues with onboarding and junior devs.
I love when senior devs can set up their workspace how they like, but juniors and onboarders often need lots of handholding. Being able to spin up an IDE with exactly what they need with zero effort is incredibly valuable. We lost days and days of productivity because some developers didn't understand how to manage having both a jre and jdk on their machine.
This is a very useful feature the moment you have > 1 development machine. Complex build environments, dependencies, personal preferences all syncing seamlessly between all of them is a godsend.
I already do that in pycharm. Everything else needs to be set once. But you’re actually arguing about multi-machines and I’m arguing about “code from anywhere” even on computers that don’t belong to you. That is an overblown feature that I’d never use.
Latency is top priority for me. It shall not be sacrificed for any multi machine inconveniences.
VSCode is super popular and performant. It runs in a browser (electron) natively. Running it in chrome remotely is literally no different if you have a performant network.
I always found VSCode to perform better than IDEA based tools fwiw, especially if you want to keep a laptop on battery. Latency has never been an issue.
If you don't want to set it all up yourself, GitPod basically has this up and running, with a pretty generous free tier. Think VSCode in the browser, with a docker container (controlled by you!) bash prompt at the bottom.
At Google we have a custom fork of VSCode running in browser and builds can either be distributed or run on my Linux VM to utilize build cache.
I liked it so much I started doing a similar setup for small side projects. Just boot up the Cloud Console on GCP and start coding.
Advantages are:
- Accessible from anywhere (I use my pc, my laptop, etc. The env is always the same)
- More compute (I can attach more CPU + more RAM flexibly)
- Less friction to start (minimum environment setup, most tools are preinstalled)
- Datacenter Network speeds + Artifacts cached (installing dependencies is fast)
Disadvantages:
- network dependence
There are some adjustments that need to be made to your workflow. And for some applications you are dependent on having the correct tooling. However, my personal prediction is most companies will move to this type of development workflow as the tooling improves.