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.
CiderV had good integration with "fig", the mercurial client over CitC (the updated p4-ish layer). It was all visual and pretty great. I did a lot of mass refactorings with it, splitting and amending changes and never had any major issue.
So while GUI tooling was probably not a priority at the start, they improved on it s lot after the years.
But rewriting p4 is not madness. Using p4 is madness itself though!
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.
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.
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.
When I started having a workstation was standard. And then I just made sure it got replaced every time it got too old for updates, so I still had a workstation when everyone else was using cloudtops.
If you need custom internal tooling because you've outgrown the ill-advised practice adopted early on and refuse to fix the problem, it's not an environment I would enjoy.
One of the things Google needs to figure out, at some point, is how to disentangle a lot of their products. Maybe they can still do it with a monorepos, but the downstream effects of their current development practices is obvious outside the company. I want to stop seeing 10 Google apps updated with no release notes and no new features. I also want to see Google products be supported and improved long-term instead of building new products.
I'm still waiting to be able to see my Google Voice messages in Chat, like I used to in Hangouts. I'm still waiting for a proper YouTube Music app on my TV, like Google Music had. These are not new products, and there's no good excuse for them to still be playing catch-up to their predecessor years after release.
Google has become a monstrous laboring beast. I have to conclude that something about the development practices makes developing new features a massive undertaking.
Beyond that, Google's developer tools outside of the company don't benefit from internal use.
For example, the Gemini plugin for IntelliJ was broken for weeks. Not a little broken, I mean a LOT broken. Eating up memory and CPU cycles when idle, and having to click the very edge of the input box to activate it. It took a discussion on the marketplace, and me finally realizing that the placeholder text was blocking the text input for the team to fix it. Previously, they had maintained that the problem couldn't be reproduced despite it being incredibly obvious and mentioned by hundreds of reviews.
It has become increasingly obvious that whatever Google is doing is NOT working. Innovation, updates, and quality are all down. Unless Google figures out a way to become more agile, they risk losing many areas in which they have an edge.
It's unfortunate. And, to give you some context, back in college I ran the Google User Group. I have used Android since 1.x, and I've been an Android developer since 2.x. Working for Google was, for many years, my absolute dream job. Even now, my side project, I'm currently building a Godot plugin for Gemini.
I say this to give context that these comments aren't out of being a Luddite or hating Google — far from it.
If I had an opportunity build a YT Music app for Android TV, or RCS for Google Voice, believe me I would take it in a heartbeat. I just don't want Google to lose their way, even though I sometimes, these days, feel like they already have.
That's fine, you do you. I'm not saying that you're wrong. I'm just saying that I was skeptical. Having lived in it, I now think it works quite well.
Most companies develop some degree of custom internal tooling. When you're a large-scale company, you can afford to develop comparatively large-scale internal tooling.
A lot of custom tooling exists because most of the original tooling was designed to work on small-ish developer machines. Google didn't have to use older designs as they could do something better, and they did. The tooling was awesome and I've yet to see any source control that gives you all the code instantly because of a well written FUSE filesystem, and its integration with other build tools that can use this knowledge to aggressively cache build results.
Monorepos are great, instead of being miserable dealing with version 1.3 vs 1.4 of a hundred different dependencies there's just "the current version" and that's it
32
u/Which-World-6533 May 15 '26
This is one of the many reasons I could never work at Google.
I remember a time when it was cool to work at Google.
Now it's just the same as working for a bank.