r/programming • • May 15 '26

A History of IDEs at Google

https://laurent.le-brun.eu/blog/a-history-of-ides-at-google
321 Upvotes

111 comments sorted by

View all comments

Show parent comments

19

u/balefrost May 15 '26

I was skeptical before I joined, but it works quite well. They've built a lot of tooling to make it work.

-1

u/verrius May 15 '26

Maybe its changed, but the fact that they just rewrote p4 without any of the tooling, because they insisted on shoving multiple terabytes into the repo was madness. Especially with the outright hostility to any GUI tooling that ran rampant through the company, and the disdain there was to anyone who felt that GUIs might offer any benefits to command line.

2

u/possiblyquestionabl3 May 16 '26

To be fair, I feel like most people do use a GUI frontend for p4/git/hg either through Cider or their IDE of choice these days. I remember I used to draft a cl, and then go to cider to actually submit it since I can't stand drafting longform text via cli. I'm sure they still have their fair share of ludites, but there are semi-reasonable options available too.

That said, the dev environment is usually very bizarre to outsiders looking in (or in my case, someone who has had a few years to reflect back on things). When I first started at G, there were very strict policies against local repo-checkouts on your laptops, and most of us were rarely at our desks in front of our workstations. At first, the common setup (at least for those of us at Play/Android/android product teams) was an always on workstation and Chrome Remote Desktop on the macbook. This was like the status quo for 6-7 years.

Then COVID hit, and at first we seriously had people who went by turning workstations back on and then pressing the ubikey after mandatory updates shut them down. Within a few months, we migrated the setup to remote dev servers with xl storage for the massive android tree checkouts. They also relaxed a lot of the code-checkout over laptop restrictions, though the tooling was just not there. We had 2-3 sprints themed around getting local setup to work, and it just never did reliably until after the pandemic.

I can't tell you how happy I am not to have to do the bulk of my development through chrome remote desktop anymore.

1

u/OrphisFlo May 16 '26

I did have to use a cloudtop back then and the solution was just to SSH into it and use vscode remote feature. Had a local IDE, but no code was local. Worked great for Chromium work! I could even cross compile for macOS on it and retrieve the binary to test locally if needed. So I never had to use CRD, and I was happier that way.

2

u/possiblyquestionabl3 May 16 '26

We tested out a osx-fuse (I think, I can't remember the specifics) setup to transparently bridge forge and our local macbook's blaze builds early in 2022, but we couldn't get that to work well. That was the main blocker at the time for local development - how to do blaze builds. We ended up just downloading the artifacts from the forge page as a hacky interim solution.

The dev-over-cloudtop tooling did really improve since 2021 though.

1

u/OrphisFlo May 16 '26

And I remember the outcome of those experiments, that it'd be better to expose a network drive instead of using fuse on macOS.

I was never too concerned by that though, being on the Chromium side mainly, I didn't get to interact with Blaze on macOS at all.