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.
That honestly sounds very atypical. I've been at Google 9 years and never experienced the scenario you describe. You should probably have reached outside of your team for assistance or flagged a manager.
Yes, there have been times when code review wasn't super useful, but on the whole I never experienced the kind of dysfunction you're talking about and merging reviews without external review is a pretty big no-no.
2015 was 6 years ago. Google as possibly changed? Doubled in size (or more) by staff? has more rigorous approaches? has more people capable of meaningfully reviewing code?
Your comment seems to be exactly the same as this one [1] from the original HN story in 2018, except with less detail. Are you ridiculous_fish, or is this just a huge coincidence or something that happens all the time at Google?
> 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.
Where? This certainly isn't possible in google3 (and wasn't possible in 2015 either).
That said, there are now some changes made to make, in general, the code review process for people without readability and without teammates who have readability more streamlined.
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.
well, Android was always a bit of a special snowflake compared to the rest of the company. Separate codebase, separate build system, separate SCCM, etc. You can't really compare an Android team to a google3 team.
Culturally, it was worse when Andy was in charge, but it was still true when I left in 2018.
Sounds like a team health issue. Sounds like a hard time, my sympathies.
In my N years of experience, very few engineers are in an environment where only they have meaningful context on what they're working on. Generally any non-trivial project worth staffing is worth having two headcount work in the space, even if one is a TL with divided attention.
You can't. Borg binary authentication is integrated with build and review. A build that does not descend entirely from reviewed, approved, and committed code running as a production user with access to userdata will raise alerts. Individuals are able to run non-committed code on Borg under their own accounts, but not under production role accounts.
You can break glass in emergencies by committing code TBR, or "to be reviewed", however this automatically escalates to owners of the code in question plus your manager and director, and all TBRs have to be resolved by actual review within a short time. An author cannot submit to-be-approved code; they have to be owners of the code in question (personally or transitively included in the OWNERS file) to TBR.
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.
Always interesting to hear these counterpoints. I've never worked at Google, but reading internet comments and such you get the impression that most people consider it some ideal workplace (though to be fair, many people selling you this fantasy are also trying to sell you their Google interview prep courses). Yet when I meet Googlers/ex-Googlers in real life, I never got that same impression. Seems like any other corporate job (I'm personally pretty jaded from corporate), just more prestige and maybe more pay. Also it seems like one's experience will vary drastically depending on what team they get placed on (eg. Google X vs. some internal tool).
I won’t ask what company you’re at, but have you noticed a correlation between size of company and your happiness? Is this new Valhalla a significant smaller organization than Google?
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.
During my ~60 months inside Google, these nuggets sometimes proved to be useful, telling about a newly available tools (e.g screenshot diffing in UI tests), common pitfalls (like mixing up dates from different systems with and without timezone), common best practices (don't use `now()` in test, instead, imitate the flow of time using...). These are just off the top of my head after several years outside Google.
Nothing mind-blowing or earth-shattering. A number of useful things to learn at these 30-60 seconds when you can't read anything more interesting, though.
Using the real-time clock makes your test impossible to reproduce. Using a mock clock leads to reproducible tests. Same with calls to PRNGs: these should be injected so your test failures can be reproduced.
You cannot test how your code behaves when midnight passes, when daylight saving time changes either way, when it's 29th of February, etc.
More importantly, you cannot reliably (let alone quickly) test how your retry and timeout handling works, especially if two threads interact, or when you do (stubbed or mocked) remote API calls. All these things are the daily bread when working with Google's services, and basically at any setup with multiple (micro)services.
The first time I implemented an "IDateTimeService" in one of our applications, I was greeted with disbelief by my colleagues.
Once I challenged them in running tests for certain edge cases, their mind shifted from "well, we cannot test that then" to "makes totally sense".
Another one is hiding the unhealthy drinks (e.g. soda) behind frosted glass in the fridge, so you can't see it. Kind of silly, in my opinion. Googlers are presumably adults, and can make their own decisions on what to consume.
Retail stores put high-margin items in key locations (next to checkout, at eye level, etc.) or companies actually pay for these spots. In a company kitchen/snack area, why not put the healthy options there? Everyone still makes their own decisions, just like anywhere else. Isn't this optimization more in the employees' interest than putting the cheapest items there (e.g. soda)?
(I'm at Google. I think these kinds of nudges are mostly good. Though it's certainly something to joke about.)
Yes, we must free ourselves from the oppression of writing unit tests and having a tool auto-indent our code! How brave to take such a noble stand on this controversial issue!
We must also throw off the shackles of our near-perfect source code revision management system, so we can gloriously adopt the incredibly slow and notoriously unusable industry standard!
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.
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.
> 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.
And there's no way it'd fit on a single hard drive.
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.
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.
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.
> 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.
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.