Hacker News new | ask | show | jobs
by OneMoreGoogler 3636 days ago
During my 16 month tenure in Google, I worked on:

1. Android, using shell and Make

2. ChromeOS, using Portage

3. Chrome browser, using Ninja

4. google3 (aka "the monorepo") officially using blaze (but often there were nested build systems - I remember one that used blaze to drive scons to build a makefile...)

The diversity of the build systems significantly steepened the learning curve when switching projects. During orientation, they told me "All code lives in the monorepo, and every engineer has access to all code", but this turned out to be not true at all. If anything it was the opposite: more build system diversity at Google than at other places I worked.

5 comments

It looks like you have a bit of a biased experience from working on Chrome. The absolute majority of the code is in the monorepo.
Can you quantify that? Honest question - Android does not seem like a small project to me, but perhaps it really is dwarfed by Google's web services.

What you wrote reminded me of a feeling I had: that these projects are these weird exceptions, only nominally part of Google. They have their own policies (style guide, code review, etc), have their own hardware, etc. The Android building even had their own desks (non-adjustable!)

In terms of percentage of engineers, by far the majority are working in Google3 ("monorepo"). Android and Chrome are the big exceptions, because they are open source projects, but most of us don't work on them.
You can quantify it. Look at the numbers in the OP article, and thinking about how small Android must be: (1) all of Android code fits on a single smartphone (2) Android apps all have a corresponding server side.
You pretty much worked on that tiny 5% of projects that live outside of the monorepo. Good... job I guess? For 95% of engineers that will never happen.
That's not really true. More than 5% of engineers work on Android and Chrome, neither of which are developed in the core repo. There are a wide variety of other teams that choose to not work in the core repo for a wide variety of reasons.
> I remember one that used blaze to drive scons to build a makefile...

Good lord.. then again I have to use MSBuild. Why can't someone write one that consumes something like JSON and is async?

I thought msbuild took json files too nowadays.
You mean Grunt?
This is the key comment in this thread. The article simply does not tell the full story In fact, Google even released a nasty little tool called "git repo" that coordinates simultaneous accesses to multiple git repos.
Sure, but even "only 80% of Google" in a monorepo is still bigger than the combined size of most everyone else's constellation of small repos. And the the separation of repos is based on deployment environment: Server, desktop, and smartphone, where code has almost no cross dependencies because the environments of software never communicate via internal channels.
The article is a fair assessment for "traditional" projects at Google (server-side? hosted? native? not sure the best term. Think "gmail" or "search" or "brain").

As mentioned elsewhere, Android and Chrome are huge exceptions in that they're a) open source and b) pretty much standalone products not closely tied to the rest of the Google ecosystem.

Why did you leave?
I got overchurned.
I have no idea what that means as a non-native speaker. Overworked? Burned out? Fired?
Too many teams in too short a period.