Ha, busted.
196 karma · joined December 13, 2014
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 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.
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.
Kidding aside, my point is Google recognizes obvious boundaries between e.g. their web stuff and android, and organizes their code accordingly.
But who considered someone taking a piss and thought "that time could be better utilized?"
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.
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)
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!)
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.
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.
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.
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.
A little too optimistic :) You can't build Android, Chrome, ChromeOS, iOS apps, etc. via blaze.
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.
> I found that it was not very useful for very much
That's it. That's the real issue, not the camera.
Polite requests to take it away are met with "Oh, she's usually not like this, I don't know what's wrong, I'm sure she'll be quiet now..." And nobody wants to be "that guy" by telling the owners to take their dog and GTFO. So the dogs end up staying.
I hate the noise level here. I haven't yet worked up the courage to expense a good pair of noise canceling headphones, but it may come to that.
This is an edict from the design team, which engineering brainstorming cannot overcome. Furthermore, the majority of engineers cannot implement a solution even if they cared to try: they lack permission to access the development Android source repository.
Maybe it's different in other product areas, but from where I sit, the atmosphere you describe feels like a myth that Googlers tell each other, and not part of its culture today.