Should've read the entire post first. o\

Google has a monorepo in which nearly all of the company's code is stored. The monorepo uses a custom implementation of Perforce. No personal computer could download a whole copy of the repo. So for that reason people need to check out a virtual/cloud copy of the repo in order to do work. This has the added benefit (for google) of not allowing individuals to have code on their device which is bad if the employee loses their device or has it stolen.

There are some exceptions for some teams (like Chrome). And when I was there exceptions for people who did mobile (iOS/Android) development, though Google was moving pretty aggressively towards a world where even iOS code wasn't allowed on the employee's device.

(Opinions are my own.)

It used to be entirely custom, but is currently being re-based on VSCode. Overall very similar feel to Codespaces, just tailed for how Google works.

Currently, VS Code is the primary method of connection to each Codespace, and we do not support other editors officially.

If you’re looking to connect via SSH with your desktop IDE, we do have a workaround here: https://github.com/microsoft/vscode-dev-containers/blob/main... -- and I use this regularly for Jupyter Notebooks. :)

I once had a setup where I could just clone a repository and run a script to get my dotfiles set up. For Vim, I would just need to then run the command to install the plugins and that was that.

Edit: Here is the CLI program that helped me set this up:

https://github.com/thoughtbot/rcm

You can have it clone your dotfiles repo automatically and run a set-up script:

https://docs.github.com/en/codespaces/customizing-your-codes...

I also have a very bespoke dotfiles config that predates Codespaces (https://github.com/wincent/wincent), so I made a thin wrapper around it that makes it work (https://github.com/wincent/dotfiles). For people with less complicated set-ups (ie. basically the entire universe), it is pretty straightforward.

It's totally worth taking the time to sync your dotfiles via git. There's a little bit of maintenance involved whenever you make a config change on one system that you want to propagate elsewhere, but it pays off.

Personally, I just `git init && git remote add ...` in my home directory and have a .gitignore that ignores everything by default, so I have to `git add -f` whenever I want to sync a config. Submodules work well for `.vim/bundle/the-plugin`. It's also nice for syncing important zsh customizations like this one: https://github.com/MatrixManAtYrService/home2/blob/master/.z...

There are also other strategies: https://dotfiles.github.io/

Well, it's a Linux VM/container, so while you could do that, I don't see why you would, I think all a dev would want to do in a dev container would be command-line in nature.

It's very good. The rendering and inputs are done locally. Completion, compilation, linting, and other things are done remotely but they are not instant anyway so the network latency is not really noticeable.

I use Github Codespaces with a Vscode and vscode-neovim. Neovim is running locally.

not op, but amazon uses "cloud desktops" with SSH access company wide, and no one really has latency issues there. So its def something supported at some companies...

I don't know how many people would want to use graphic applications over the network however, seems like it would be janky

I’ve always thought that remoting to edit text files using X or RDP is doing at the wrong level of abstraction.

VSCode editing over SSH works really well in contrast. I think Sublime has a plugin that ain’t bad. Emacs (TRAMP) is probably the worse of the three :/.

Terminal Vim or Emacs over Mosh is a pretty good option too.

Jetbrains has a hosted-IDE pilot project: https://lp.jetbrains.com/projector/

Currently, VS Code is the primary method of connection to each Codespace, and we do not support other editors officially.

If you’re looking to connect via SSH, we do have a workaround here: https://github.com/microsoft/vscode-dev-containers/blob/main... -- and I use this regularly for Jupyter Notebooks.

How is the performance on jetbrain IDE. I love webstorm & intellij but they are Soo slow compared to vscode for me.

At first I liked them because they have lots of great functionalities out of the box, but vscode has caught up and just yesterday I switched back to vscode from jetbrains. For java spring and react

Yes, with special Electron shenanigans that still work in a normal browser well I suppose. The web UI has a few features that make it more device agnostic too (e.g. a hamburger menu to replace the File menu. Yes, you can run Codespaces on an iPad.)

Code server (https://github.com/cdr/code-server) works in a similar way using your own PC as a host, but for whatever reason Codespaces is more performant.

Same regarding the code executed, but not same in that various actions require a round trip to a remote server with attendant latency.

To be clear, the UI is a web app. But that is serviced by out-of-proc servers written in many different languages (e.g. language servers are usually written in the same language that they service).

unless you've used it, then you'd know that its browser backing is nothing to frown at since its a great piece of software that works great.

Dependency management is usually not a big part of programmer workflow (unless you are a devops or something). Download dependencies and docs, go offline, write code.

People who try working offline are exactly the people who want to do it without Stackoverflow.

An internet connection is also required for fairly important things like pushing your code, giving and receiving code reviews, etc.

What skills would developers really lose? Speeding up boarding seems like a win, not many skills are developed imo trying to set up you personal dev environment. It's mostly just frustrating when a company's tools don't work well on your machine.

Probably, but I am more likely to be fired for not doing work

If the company IDE is annoying to use, then rewriting it is probably a net time saver. The time consuming part of coding is rarely typing the code, afterall.

Don't most IDE's have the ability to edit remote files over SSH? I know VSCode can, and I remember reading a comment from an emacs user doing that. It looks like IntelliJ can do that too, though it seems to edit local copies of files and sync over SSH. There's also SSHFS, though I don't know how good of an experience that is.

It can be a pain to set up, but is it more of a pain than setting up a dev environment the old fashioned way?

Mosh provides a noticeable improvement in SSH reliability even on a home fiber connection in the US.

They let you ssh in. So you can run vim/emacs on the machine if you want.

You can ssh in and run actual editors.

It works both ways. There are plenty of companies that will happily take productive engineers, without forcing them to use a slow, poor-quality IDE as their main tool, full-time. It's not a minor annoyance if it's the tool you use throughout the day, to do a job for which you are then evaluated.

"Tools are just means to an end" is just one of the many rhetorical devices that cushy managers use to eschew responsibility. Of course they're means to an end, but some means are better than others, and usually those with better means end up doing a better job.

There are plenty of engineers but few good ones.

Hiring is brutal, especially now, so good developers can afford to be picky and find another semi identical job in almost no time.

I wouldn't call it a minor annoyance when it's a way of working you're practicing for 6-8 hours a day.

I am best placed to determine what tools I work with best to get work done. You wouldn't get an electrician in to do some work and then decide you can suddenly prescribe the tools they use.

I just don't have the patience for this sort of nonsense, there are a dozen clients who won't micromanage the operating system, editor and way of working that I'll be using to get the job done. With that said, obviously it's a two-way street and some willingness to be flexible needs to be shown on both sides. If $client wants me to sync my work with their $uniqueVersionControlSystem then fine, I'm willing to put in the extra effort to try and meet their specific needs within reason. But that doesn't extend to working inside a client-provided VM, using a client-prescribed OS image, using a client-specified IDE or making other such major changes to my established ways of doing business.

And in fact any client trying to micromanage this sort of stuff is a massive IR35 working practices red flag over here in the UK. You're better off terminating the agreement and signing something else as a SoftEng contractor.