OneMoreGoogler's comments

Ha, busted.

It was in the Android repo, which used Gerrit.

I never dealt with readability, because Android did not require it. In fact that was part of their internal recruiting pitch: fed up with readability? Come work on Android! Heh.

I worked at Google circa 2015, and found the code review process to be actively terrible.

I was writing JS, while my sole teammate was a firmware engineer. He was not willing or able to meaningfully review my code, so I had to try to scrounge random reviewers from other teams. They naturally de-prioritized it, so it took forever. And because they were not involved in my project, they would only have local stylistic feedback.

Months in, I finally figured out that other engineers were just self-reviewing: you can add yourself as a reviewer and just click merge. So I started doing that too.

During my time there, the internal Android repo required VP approval to access. Though I understand this was relaxed later.

Over 16 years I've worked at only four companies, but one of them was Google, and it was honestly my least favorite.

Creature comforts: I have an actual cubicle with >2x the space. Excellent meals are still provided, but now lines are <1 min. I can always find a parking space. I can always find a bathroom stall.

Engineering culture: No more promo or perf review nonsense. There's none of the internal competition / pressure that I felt every day at Google. The org and leadership has vastly less churn. The place is dead at 5:15pm. And the people I work with are incredibly smart.

In terms of company: my new employer is not creepy. My grandmother understands what I work on.

Do follow your heart, but I'm so happy I left.

You know Google's monorepo is successful because they have so many of them! google3, Android, Chrome browser, ChromeOS...

Kidding aside, my point is Google recognizes obvious boundaries between e.g. their web stuff and android, and organizes their code accordingly.

I agree, it's between useful and harmless.

But who considered someone taking a piss and thought "that time could be better utilized?"

Example: my whole building was working in the android repo, but the ToT article would be about some tool for google3 (web) development.

I saw these during my 18 months at Google. They were never relevant to my work.

Working at Google you are bombarded with "nudges." The garbage cans have stop smoking signs. The plentiful candy is famously placed into jars to reduce consumption. There's signs telling you not to sit on the loo for too long. You'll get emails comparing your travel and server expenses to the average. All of this stuff is well-intentioned, but there's clearly part of the company seeking ways to manipulate its workforce.

Honestly it's the opposite. The way you get noticed and promoted at Google is by building something new, even if Google is already doing something else in that space. That's part of the reason there's so much duplication at Google.

The VIPs (Vest In Peacers) are more inclined to do the easier thing of adopting and building on what's already there, which is of course the better thing: virtue of laziness and so forth.

(source: xoogler)

I got overchurned.

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!)

Checkouts are apparently instantaneous. Behind the scenes, there is a FUSE filesystem that faults in files by querying Google's cloud servers. So it does not require a significant amount of space (but does require fast access to Google's servers, which can be problematic).

Almost all engineers have access to the "complete system," which is really Google's server-side software. Other repos like Android have historically been more locked-down, but there's been some recent effort to open them up within Google.

Presumably if you tried to copy all of the files, you'd first be rate-limited, then get an access denied, and lastly a visit from corporate security. I wouldn't want to try.

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.

> It showed that the effective tax rate paid by those Americans jumped in 2013 to nearly 23 percent.

As a data point, my family paid 28% average federal tax, on AGI of $355k. We are California residents. Taxes are regressive on the higher incomes, and that doesn't seem right.

Speaking as a former member of more than one low-performing team at Google, none of the exercises would have helped our performance very much. What would have helped:

1. Being co-located. We would have been more effective sitting and working together, but instead we were distributed across multiple time zones and countries.

2. Working on a project with a future, instead of one that was winding down. It's difficult to "harness the power of diverse ideas" or be "rated as effective" when our team's charter is maintaining a project to its EOL date, with no plans for a successor.

3. Avoiding morale-sapping demotions in responsibility. One of my teams had its responsibilities changed from supporting the system we built and deployed, to assisting one of Google's "partners" deploy an inferior replacement. More than one member left when that happened.

4. Reducing the technology churn. When our leadership changes the product every six months, which forces us to switch to a different technology, we're stuck coming up to speed instead of contributing out of our expertise.

5. Reducing the team member churn. Constantly leaving and replacing team members is both a symptom and a cause of low performance. Here Google's internal mobility works against it.

(These events were due to leadership shifts at the VP level, and had nothing to do with our team's output, which I think was better than it ought to be given our circumstances.)

The point is that a team's performance has more to do with the larger organization than the team's internals. Frankly this article feels like blame-shifting: if we teach them some exercises to do at meetings, maybe they won't notice all these institutional issues.

> Any engineer can build any Google product from source on any machine

A little too optimistic :) You can't build Android, Chrome, ChromeOS, iOS apps, etc. via blaze.

No, not TBR. I was referring to the fact that you can +2 your own CL, which allows it to be merged. Officially this is an "emergency" feature, as you say, but a dirty secret is that it's used routinely. I encountered it in both Android and Chrome.

I've seen lots of self-+2s under the following circumstances:

1. You are the only engineer on your team, or all other engineers on your team are out for an extended period of time.

2. All other engineers have very different skillsets, and are not capable of doing effective review. Think Rails engineer attempting to review a touchpad firmware fix.

3. You have a hard deadline (e.g. product demo or factory build) and you're desperately trying to get as much working as you can. You may even be in a location where coordination is difficult and Internet access is poor.

For SWEs working on, say, web services, you probably have at least a medium-sized team (4+ engineers) and a week's slip is no big deal. But not all software is like that at Google.

You can self-review. That's how people solve the problem.

The smartphone requires awkwardly peering at a glass rectangle, yet it effortlessly reorganized social norms, because it's so damn useful and interesting. So why didn't Glass do the same thing?

> I found that it was not very useful for very much

That's it. That's the real issue, not the camera.