I was there 2004-2014 and never used an IDE the entire time. From my perspective the most popular editors were emacs and vim. Life was probably different in the Android and Java areas, but there was also a massive chunk (50%+?) of people writing C++ and Python, and I think IDE-less is/was the standard for those folks.
A History of IDEs at Google
111–120 of 333 posts
Re: A History of IDEs at Google
#112I am very opinionated, but I really don't like Cider V. I have been using neovim at Google since 2017 and it's been great.
same! how do you deal with cloudtop latency though? sometimes my neovim is very slow and laggy because of the remote connection / network file system
I have a (Google-issued) desktop in the same city I live in, so the latency is not so bad.
Re: A History of IDEs at Google
#113Earlier quoted context omitted.
same! how do you deal with cloudtop latency though? sometimes my neovim is very slow and laggy because of the remote connection / network file system
I have a (Google-issued) desktop in the same city I live in, so the latency is not so bad.
I will say that the latency of the filesystem is a different problem. Most of the google filesystem tooling is not built for command line tools that expect to index large subsets of the filesystem at once.
Re: A History of IDEs at Google
#114"the advantages of having a single, extensible platform become even more obvious" -- imagine the impact that could be unlocked if we got the Android and Chromium workflows into CiderV/Critique! The article is framed around "all Googlers" but there is still a very large contingent of Googlers who cannot use these tools.
I would imagine Android development, with its reliance on simulators for local UI testing, is pretty complicated to shoehorn into a web-based IDE? I think cloud-based IDEs would only really work for anything for which a text or web-based UI suffices. (Which is already quite a lot: that covers code, logs and web pages.) For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator runni…
> For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator running in the cloud
This does exist. The network isn't the main problem. The Emulator has to run under nested KVM. That + graphics rendering on the CPU makes it not so responsive. It's useable enough in many cases though.
Re: A History of IDEs at Google
#115Earlier quoted context omitted.
You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.
How do you internalize it? Our bazel system is full of custom skylark code so understanding the build means effectively reading a bunch of ad-hoc code written with varying degrees of competence and with confusing dependencies. I’m kinda ashamed I don’t have a deep understanding of a tool I use daily - but every time I try reading the documentation I quickly give up.
I would recommend learning the various "bazel query" variants starting with a plain "bazel query" https://bazel.build/query/language
Re: A History of IDEs at Google
#116Earlier quoted context omitted.
Very little development in Google3 happens locally. You aren't even allowed to keep the source code on your local disk, and this is true no matter what OS it runs. (Android and Chromium are different though.) You have access to an extremely powerful remote workstation that from a UI perspective functions almost identically to a local workstation, via Chrome Remote Desktop. Plus, no one builds things locally, even on…
> You aren't even allowed to keep the source code on your local disk How is this enforced?
I have no knowledge of actual enforcement mechanisms, but it is way, way, way easier to do all development on the distributed file system that feels like a local disk than it is to copy things over locally.
If you need to do development locally, you are either doing something very wrong or extremely specialized.
So there is effectively no motivation to copy the sources over. And because everything is on this distributed file system and built from it in a very bespoke environment, I would imagine (with no inside knowledge at all), that it is easy for auditors to detect when someone starts copying things out.
Re: A History of IDEs at Google
#117That most engineers use the same IDE at Google allows the company to collect a huge amount of telemetry about what features they are using, how often, and how much. Quite similar to the entire codebase being in a single repo, it allows a certain visibility into what is happening that just isn't possible other places. When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you…
Visibility doesn't always get you value though. See the many companies that unify their ticketing to something like Jira, and end up running reports on in. The actual accuracy of the aggregates is rarely great, and instead leads to people doing "jira optimization" to make reports look good. I once worked at a place where VPs were looking at sprint burndown charts, and asked what happened if the line didn't look a lot…
You have to be very careful in management to not create perverse incentives. I like to use change control processes as an example. In theory, a super strict change process for every single change is great, because it'll ensure everything gets reviewed thoroughly. In practice, that leads to people flouting the change process as much as they think they can possibly get away with, because it becomes a serious impediment to getting work done. A more moderate change process would have higher compliance, and actually lead to more oversight, than a super strict one.
Re: A History of IDEs at Google
#118Re: A History of IDEs at Google
#119Earlier quoted context omitted.
From the article: “ Cider was a light client that opened much faster than traditional IDEs. All the magic happened on a backend that indexes the entire codebase, so that all the data was ready whenever someone opened the webpage. ” Sounds like all other editors were slow compared to Cider.
OK, this was probable me telling other people I have never worked in a large repo without telling other people that...
To be fair, that is a blessing. Large monorepos are a terrible idea.
Re: A History of IDEs at Google
#120"the advantages of having a single, extensible platform become even more obvious" -- imagine the impact that could be unlocked if we got the Android and Chromium workflows into CiderV/Critique! The article is framed around "all Googlers" but there is still a very large contingent of Googlers who cannot use these tools.
I would imagine Android development, with its reliance on simulators for local UI testing, is pretty complicated to shoehorn into a web-based IDE? I think cloud-based IDEs would only really work for anything for which a text or web-based UI suffices. (Which is already quite a lot: that covers code, logs and web pages.) For anything with native UIs, I suppose you could "remote desktop" into an app or a simulator runni…
"Android" here refers to the Android operating system, which (like Chrome) has its own separate development stack. Most of Google's Android apps are developed using the main google3 stack described in the post, or at least were when I was there.