Google allows for normal desktop IDEs, plus having a web based one. The funny thing is, many people move to the web based one because it is so good.
But Google is also unique in how piper/citc[0] (our source control) works. It's effectively designed for web/cloud based style development, so the workflow for web based dev and desktop dev are effectively the same.
So web dev can work, but I don't think the existing tech that most of the software industry has is built well to support it.
[0] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
The cloud environment builds and runs faster but the autocomplete, go-to-definition, etc. are pathetic.
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.
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.
I use Github Codespaces with a Vscode and vscode-neovim. Neovim is running locally.
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.
I don't know how many people would want to use graphic applications over the network however, seems like it would be janky
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.
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/
Edit: Here is the CLI program that helped me set this up:
Seems it would solve all the issues, which are specifically that it mostly works only with VSCode or terminal apps, but with a remoting solution you could run anything you'd want.
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. :)
Jetbrains recently added remote capabilities to IntelliJ, I'm hoping it's going to be usable with codespaces soon.
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.
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
It's pretty configurable. In my experience, it's pretty quick. It's not text editor or VS Code quick but the only thing that ever trips me up is the occasional re-indexing. Well worth it for how well it does everything else.
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.
Parts of gmail run in the browser, the rest runs on servers written in many different languages at Google.
The article describes using pretty much any IDE, so they are just offloading the setup and running of the development environment to the cloud while letting you run your preferred IDE locally.
People who try working offline are exactly the people who want to do it without Stackoverflow.
My company has a remote VSCode setup not that dissimilar from this setup. Big C++ codebase. Many engineers love it, even some of the "old timers." Our interns can be productive on day one and it brings a lot of productivity to not have to worry about caring for your dev environment.
But there are plenty of people who really just want to SSH into a beefy desktop (or directly edit on that desktop) and use their vim/emacs setups. These are the people who know how the whole build stack works, can debug the vscode/codespace magic, and can do amazing things not available in the VSCode plugin library.
So it's good to be able to do both. Allow power users to use their own tools, but don't require everyone to be a power user to sit down and write some business logic. Give nice rails to ride but don't require them.
I bet smaller/poorer companies may want programmers who are ready to fix tooling when it (inevitably) breaks
Additionally, it's not like developer set up is the only thing that test your ability to manage frustration. I would say developer set-up is just something you need to get through to start your actual job, and if that can be eased up then it's worth it imo.
For smaller/poorer companies, they could always hire an engineer that specializes in fixing broken tooling. Ultimately it's a company's job to hire competent engineers.
Thinking back to all the times I had to set up my workspace, I wonder how much did I really learn vs just Googling and getting quick fixes.
While the USA is also litigation happy, it actually takes an incredibly high amount of deliberate destruction for an employer to succeed in suing an employee.
I don't think it's very likely you'd get sued, but I wouldn't want to risk it against well funded adversaries with expensive lawyers.
There are other IDEs besides VS Code and shell based ones.
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?
If you edit a file using some sync over ssh option, and want to run a test - how do you proceed? And how is this not the same thing as just checking out the git repo locally in the first place?
Well you have your files synced over ssh and also have a terminal over ssh which you use to run your tests. Am I missing something?
> And how is this not the same thing as just checking out the git repo locally in the first place?
It's not just avoiding cloning the git repo. It's avoiding building all the dependencies and getting them configured and running. For most of my projects that's not a big deal but I expect GitHub has several databases with specific configuration, memcached or redis, maybe custom patched builds, etc.
If you check out code in RubyMine, it'll try and install the dependencies in the Gemfile regardless, though.
Hear me out:
Toolings are, like the name suggests, a means to an end. If a web IDE is fast, works reasonably, and can continue improve itself. And the learning curve is friendly to engineers with different background and experience. Everyone should be comfortable to be nudged to use it. And if the tool additionally is a critical product of the organization, everyone should be comfortable to be mandated to use it, because it's now a very valuable source of dogfooding.
> Toolings are, like the name suggests, a means to an end.
It goes both ways. Employees are paid to accomplish an end, and I understand employees who are happy to walk away from an employer that micromanages the means to that end down to preferences in tooling. The reason you quit isn't because you miss Emacs (even if you do), the reason you quit is because your boss doesn't even trust you to choose a text editor.
That said, if the thing is your own product, yeah I get it: dogfooding is important. That said, I know of teams at Microsoft who do their (OS-agnostic) work on macOS... at some point accomplishing the end is more important than dogfooding, and you just let the workers use the tools that they're comfortable with.
No hard feelings or anything. I spend 5-8 hours a day working in my IDE. That's a huge chunk of my life and it matters a lot to me to work how I want. I've also found getting this aspect of my worklife right greatly impacts my overall productivity.
*it's always engineers making these statements or I only know engineers
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.
"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.
Hiring is brutal, especially now, so good developers can afford to be picky and find another semi identical job in almost no time.
There should honestly be some good faith on both sides. It doesn't make sense for a job, in most cases, to be strict about an editor. But it's also not a good move for eng to be walking around talking about all the fragile things they'll quit abruptly for.
I feel like you're gradually making this hypothetical engineer seem more ridiculous. If someone quit over training or their unwillingness to try scrum, that would be bananas of course. There's an extremely large gap between that and mandating the main tool to use to do your job everyday.
That said, small things can look trivial from the outside and make your life a living hell at the same time.
In my experience (FAANG, startups in the valley and startups out of state/country), strong engineering talent is not particularly difficult to find, but finding a good fit is the tricky part. And I would wager that eagerness-to-rage-quit is a pretty good indicator of someone who will have trouble finding teams that they fit on.
If you look outside of FAANG (companies in the rest of the world with unattractive stock), finding good engineers is a problem and most codebases are filled with horror.
The plus side is that, once you're a good engineer, you get little stress/pressure and a lot of leverage on flexibility (eg. remote in cheap places, in pre covid times), even if you won't make as much as FANG engineers. Also, interviews don't require 2 months of preparation every time you want to jump ship.
I'm sure if you're paying FAANG money you can find plenty of good engineers happy to do backflips.
A lot of people "rage-quit" basecamp over their no politics thing. I probably wouldn't have, but to each their own.
FWIW, I have also spent lots of time at FAANG, startups, etc and haven't had any trouble finding a great fit. I have also never looked more than a week or two for a job when I wanted to leave, so that does factor into my willingness to leave if I'm not enjoying my job.