Code wise, probably Fuchsia. I worked up and down the Fuchsia stack regularly, from bootloaders to GUI programs and all over in-between. For a sizeable code bas

Code wise, probably Fuchsia. I worked up and down the Fuchsia stack regularly, from bootloaders to GUI programs and all over in-between. For a sizeable code base with so many layers and concepts, and regularly moving between these without much memory for what's there (as it also moved around quite quickly in my time), it was the lowest average cost of entry to new areas of most other millions of lines of code repositories I've dealt with in my career. Still plenty of bugs came up, lots of polish and more design work to do, it's not at all to over-sell it, but almost everything was approachable with low impediment. There were also lots of Ruby libraries back in the hayday of the language that were very clean for what they are. I've rarely seen programs structured so well since - some of this is essentially a forced practice by the language - if you don't do it, you'll suffer as there's no types, lsps and whatnot to otherwise save you, but still, it's worth calling out, as I think back occasionally with fond memories of being unimpeded anywhere I needed to go. Tooling wise it's got to be noted as others have that the Google monorepo was well integrated, but it wasn't what I'd describe as "best" at all. I had a fairly broad time at Google having worked in most of the sub orgs over the years and in doing so saw a lot of the variance even with the chosen integrations. I saw teams who regularly built from no where near head cherry picks out of the repo, I ended up owning stuff that always built off of the main branches (most Googlers don't even know exist) setup before my time to avoid running into otherwise hardline constraints around single version policy that couldn't be adhered to for specific product reasons (hi cloud). Exactly how much and which parts of buganizer teams used varied hugely, which service management tools they used varied, which database systems, etc. The single patch system while also fairly well integrated combined with code review practices that often stymied medium scale refactors (large refactors within a single product area), though making large scale changes that touch every single top level directory, while a bit rough on the edges of the tooling, the tooling existed and worked really well - pushes out hundreds or even thousands of patches and automates pinging owners and informing you of failures, etc. In many ways a lot of smaller systems with far less tooling, and far far less integration were more productive - I've never seen such a bad way of _organizing work to be done_, or such a poor volume management of bugs as I have at Google in various teams/areas, despite all the tooling. Any delivery that involved client programs (desktop programs, mobile programs, etc) was always pretty remarkably awful, and only very very small teams were on the hook for making any of this better. They'd always plaster their new thing with "don't you dare make another or use the deprecated thing" meanwhile they never had enough time to make the new thing ready - a common trope in the company, but really highlights there are edges outside of the "pure saas" side of the business which were pretty bad. The best part of the monorepo and monotooling culture for the saas side is the security properties of it all, which were outstanding, and are among the reasons why I still trust Google as the holder of some main accounts. I hope they never start to lose those properties given the scale and impact they could have.