Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- That 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 turned them off, later updates would turn them back on. This is very good for your adoption metrics, but might not tell you exactly what you want to know about engineer happiness.
Such a dominant IDE also allows management to ignore the long-tail of users who aren't using it.
by compiler-guy - > When Google wanted engineers to use AI features, it turned them on in Cider-V by default. And if you turned them off, later updates would turn them back on.
How is that good? That would be the first thing that would force me to use IDE that is not controller by 1984 entities.
by krzyk - 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 like the line expected by JIRA. The telemetry is therefore often a curse, as any metric becomes a target. How many companies today have KPIs about having automated code reviews, which are then ignored by the devs, because said reviews are just wrong on almost everything?
The learnings of Seeing Like A State don't apply just to governments.
by hibikir - The last year I’ve been doing all my dev on a vscode VM thingy my company set up. It’s just been getting better and better. It’s like local dev but, tbh, better. It’s at the point where I don’t even install dev tooling locally any more at all. My computer is just a thin client.
The aspect I miss is the distributed compilation hinted at in the article. I remember back at the end of 1990s using distcc and things, but that never seemed to happen in the Java world and the tooling like maven etc is structured to make everything one long dependent chain. Shame.
by wood_spirit - This is the other way people work at Google. You have a Vm and then connect IDE of choice to it via SSH. But honestly it’s a lot more effort that just using Coderby randomCloud
- You want bazel. Once you've internalized the bazel (blaze) system, you want all builds and tests to work that way.by barrkel
- When I left Google in the mid 2010s, there were a couple unusual constraints: 1. They had the majority of their code in a vast++ monorepo. 2. There was a policy that forbade having code from this monorepo on your laptop.
Most companies and projects have orders of magnitude less code, and don't restrict where that code can be stored. It's interesting to learn about Cider and the other things Google built to address their unusual situation, but it's worth keeping in mind that their approach probably isn't ideal in ~most modern dev scenarios.
by kjgkjhfkjf
Was this due to security and/or technical reasons?> There was a policy that forbade having code from this monorepo on your laptop.- I actually think these constraints _help_ the average project as well. By enforcing remote builds and execution you completely remove the need for something like docker. You also get cloud backups for your code automatically.by eddd-ddde
- One less-discussed side effect of google's idiosyncratic project structure & tools is that their open source projects can be a goddamn nightmare to work with. Want to make a CI/CD pipeline for your ChromiumOS builds? Have fun trying to make a container that precisely mimicks a Gentoo chroot that changes every 2 weeks.by ryukoposting
- Was at the big G many years ago.
It was long series of incredible and impressive feats of truly singular engineering talent continuously wasted solving problems of our own making that shouldn’t have existed in the first place.
- I jumped from Google to Facebook on 2019 and while I had thought Google had best in industry developer tooling, Facebook had it better.
Google’s dinky browser based Cider was cute but Facebook in its transition from Atom to VS Code was far ahead. Google might have invented asynchronous web based code review with Mondrian and Critique, but Facebook’s Diff was better with its stacked diff support. Google’s Buganizer was outdated and clunky compared to Facebook’s Tasks.
I left Facebook the year after but I do wonder where Meta’s tooling is up to nowadays. Is it still a glimpse of the future?
by exclipy - And the instant start cloud dev servers complete with shareable full stack preview links! Chefs kissby exclipy
- I jumped from Google to Meta in 2022 (Worst. Timing. Ever.) and by that time Google's IDE had pretty much caught up. Android app development at Meta was super painful because of the repo size. My good morning routine was to kick off a 40 minute sync, and then get coffee and wander the building while I waited.by shaftway
- There is enough flow of engineers between the two companies that many of the things Facebook has done better have been copied by Google. I think in many ways it goes both ways.by surajrmal
- I left Google end of 2022, but we already had the mentioned new version of Cider based on VS Code for a few years before that. It's possible FB did it first, but I don't think Google was far behind at all. I'm fairly certain there was the new VSCode based Cider by early 2020. Certainly was by end of 2020 and entirely common by the time I left.
(I didn't get to use it much because I worked on embedded stuff that was on the Chromium stack and in git, not in Google3)
Buganizer (v1 and v2) was delightfully primitive and simple. That was the point. PMs couldn't play games with it.
- Oh yeah, not to mention the drag and drop GUI mercurial client in the IDE. I still haven’t seen anything as good on the outside.
Regular engineers could use stacked diffs proficiently and regularly, without it being seen as a super advanced 10x engineer power user thing.
by exclipy - I have never worked at Facebook but I have always thought of Critique as the best code review tool I’ve used. It’s way better than GitHub. A few things I miss: (1) it has convenient and intuitive pure-keyboard navigation; (2) you can reply to code review comments in a pending form and then publish them after you update your code, because in the common case you address code review comments by updating the code; (3) until recently GitHub wouldn’t allow you to comment on lines far away from the changed lines but Critique has always allowed it, because obviously this is an important use case when the reviewer needs to point out the changed code affects some other regions; (4) it had support for diffbase so it displayed stacked CLs fine.
Critique had had a redesign between end of 2019 / start of 2020. I didn’t recall adding any significant features but it merely modernized the UI. So did Buganizer and Code Search. So if you thought the UI was clunky well it had been addressed.
Buganizer UI: https://issuetracker.google.com/issues?q=Android%2F
Code Search UI: https://source.chromium.org/chromium/chromium/src
Unfortunately I wasn’t able to find a public instance of Critique.
by kccqzy - "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.
by StilesCrisis - 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 running in the cloud but at that point you might as well run that locally and cut out all the issues introduced by networking.
by keeda - There is in fact a version of cider that does work for folks working outside of google3, such as android. It's not as seamless, but it has been getting better and tries to recreate the google3 experience.by surajrmal
- They're working on it. I think they even have a "beta" for Android/Chrome on CiderV. From what I heard it's slow and doesn't work with most of the existing tooling (want to reformat your source files? Too bad).by IX-103
- Xoogler here (2014-2017). My team (part of Ads) used primarily Java, and we used the Eclipse, then we started switching the IntelliJ.
Cider was used also a lot, but I've heard even back then some folks were free to use whatever they like - vi, emacs, you name it.
by malkia - Yep, I made my own! (Xoogler 2017-2023) this is my noogler IDE story, one of my favorite, proudest hacks!
I developed a fork of the IntelliJ IDE on my second week at google out of raw frustration over latency. At the time I was commuting 2-3hrs/day SF<>MTV on the gBus.
Connectivity on the bus wasn't optimal, and there was high latency. Cider didn't have deep integration, and wasn't able to let me explore and understand the internal APIs effectively. I found it easier to enter a debug session within Intellij then 'vibe' and explore the internal apis via superComplicatedObject.ini<tab>.
Faced with an alien architecture + ADHD-unfriendly flow-crushing remote desktop latency -- and the lack of discoverability, I started hacking at it and without any knowledge of the system and architecture. Just tracing Intellij execution, subprocesses and network calls.
I was able to hack together a prototype in a few days that allowed me to run IntelliJ on my Mac, while the heavy bits ran on my corp desktop. The system would mount the remote filesystem over sshfs, would monitor and patch network connections and setup transparent shim binaries. Half of Intellij was running on the Mac (the front end) and the other half ran on Linux. Intellij didn't "know" that that it was running on a mac. This was initially implemented in a ~250 line shell script that patched everything.
It was called MDProxy[1] and ended getting adopted and supported during COVID as more development went remote. This became a source of many peer bonuses and spot bonuses. circa 2017* remote coding options at the time:
[1] https://github.com/bazelbuild/intellij/blob/6b8f03c21172033a...typing | code latency | integration -------------------------- cider low | meh mdproxy low | great ssh+vi med | meh rdp+iJ crushing | greatby achille - The most amazing thing to me about Cider-V was that Cider (without the V) actually went away after a relatively short amount of time, when virtually every other internal service that is officially EOL-ed lives on essentially forever.by phreeza
- It would be nice if they extended their external services the same behavior…by buildbot
- I feel like core dev team learned a lot about actually enabling a web based ide for line 100k engineers across the globe for a gazillion line mono repo. ciderv is really just a skin for the amazing infra. Which is also why I think there was less resistance to the changeby lunarboy
- Initially I had thought so too. But later I realized that it’s quite easy to do so when you force-deprecate the old product. There was no real choice, the old IDE simply stopped working after a certain cutoff date. Adoption metrics felt forced and pushed, but were presented as if users were actively and willingly choosing the newer IDE.by thiagowfx
- That is because the Cider team did an amazing job of managing it, and spent tons of time going bug report by bug report to find and fix the blockers stopping people from preferring Cider-V over Cider, instead of the typical Google deprecation approach of "monkey knife fight"by DannyBee
- Man in building Tritium[1] I have always used the analogy that developers would never program in a web-based IDE. Thus, lawyers would never live in a web-based legal IDE either. In exchange for that we’ve paid the onboarding price of trying to get desktop software installed to even run a demo. This is super timely to push us back towards a reality that web may be viable.by piker