> Counter-argument: Just let it sit there and keep working? Outside of security patches, if there even are any, there's always the option of "just stop touching it."
That's not exactly possible with a monorepo that has no branches and everything has to be maintained 'in step'. Any time a library breaks API, all dependents must pass tests, and/or be fixed so that they do. Any time a runtime API breaks (think things like interfaces to runtime authentication, compute scheduling, database services, network bandwidth scheduling), updated services must be made to conform and then be rolled out. As with real life, this might mean getting a 1 or 2 year old deployment system (configuration for production, roll out code, ...) undusted, understood, probably fixed in turn, etc.
As such, some SRE/SWE team _must_ be responsible for projects that are in the "don't touch"/maintenance phase. This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google.
> As such, some SRE/SWE team _must_ be responsible for projects that are in the "don't touch"/maintenance phase. This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google.
That's Google's problem, and it's a problem they might want to look into solving if they want to turn around their reputation for killing products.
Google pays their engineers a lot and they’d need to recruit a lot more of them if they were going to keep running everything they ever killed. That, or stop launching so many new products.
I know it's beside the point, but you stepped on one of my peeves. Google doesn't have to pay their engineers "a lot". They don't have to keep sucking more and more wealthy people into a concentrated corner of California. They could open a modest office in Nebraska and pay some 5-figure salaries.
They could hire some run-of-the-mill college grads to work on a "dead" project. They could cut their teeth on low-profile stuff within Google and perhaps demonstrate abilities that move them up the ladder.
I'm not saying that Google should do this to keep everything they've ever touched alive. But spreading the talent around geographically would solve a lot of problems for Google and for California and for the world. Same for all FAANGs.
Quit earmarking $billions to solve the housing crisis in SF. Spend $1M in St. Louis and move 100 employees out of SF. Then spend $1M in Amarillo, and $1M in Sioux Falls. Shucks, maybe splurge and spend $20M here and there. $250M to build up 10 offices around the continent will do more to solve the housing crisis in CA than $1B spent in CA. And it would cut FAANG costs in half at the same time.
> Spend $1M in St. Louis and move 100 employees out of SF.
~100/100 SF Google engineers would change teams if they received a mandate that their team was relocating to St. Louis (or basically anywhere). Anyone who couldn't arrange to change teams would quit.
The fact that Google has 70 locations around the world, including 26 around the US, indicates that some Google employees are happy to work outside of SF.
Yes, but not a significant number of the ones living in SF. The parent comment was suggesting to "move 100 employees out of SF", which is clearly not happening. There are 70 locations around the world that these people could theoretically work and they have chosen SF. I'm sure pretty much every person working at each of those 70 locations was hired to work at that location. I'm am a bit appalled by the shittiness of the viewpoint expressed by the original comment, that the solution to lots of people wanting to live and work in high-demand areas is to force them out by moving their jobs somewhere they don't want to live. There are a lot of great reasons to want to live in a global hub city and work at a centralized office instead of working at a satellite office in Amarillo or Sioux Falls.
Recently Google has actually been low balling a lot of candidates and is nowhere near top of market. In many cases they are refusing to match competing offers, and are even offering people less money than what they are currently making
Exactly what happened to me. I had offers from Google, Airbnb, Lyft and Uber. In terms of numbers,
Lyft > Airbnb > Google > Uber.
Google tried to lowball me all the way through, and asked me to share screenshots of actual emails from other companies to prove my other numbers. They increased the numbers but frankly, they weren't anywhere close to Airbnb/Lyft. They did not act like a company that would beat other offers for talent. My offer was in the AI Assistant team under Google Search, so it wasn't an orphaned arbitrary product team either. Broke my heart coz I was so keen on joining Google from the start.
This. Someone has to be in OWNERS and it’s difficult to find people willing to do this because fixing breakage due to API changes isn’t going to be on anyone’s OKRs. And if it’s not on your OKRs, it’s not contributing to your promo.
How is that true? The OKR explicitly doesn't include cloud print because it is deemed not important to Google, and so cloud print is not worked on. Seems to be WAI?
Seems then like the incentive systems have a blind spot: they don't account for pissing off users relying on a service.
Why shouldn't people get promos for doing heroic acts on obscure services that actually delight users in real life? That surely has a benefit for Google. And the lack of it has a cost. Think of it like a PR budget. They'd get fewer grumpy articles about unmaintained services being dropped.
It’s a feature not a product. Not everything has to be about profit and loss if it’s part of a larger ecosystem. Google Cloud Print was a feature of Android as well as other parts of Google’s ecosystem just like AirPrint is a feature of iOS/MacOS.
But Google has always been piss poor at managing an ecosystem. Just look at the state of Android updates.
That's not exactly possible with a monorepo that has no branches and everything has to be maintained 'in step'. Any time a library breaks API, all dependents must pass tests, and/or be fixed so that they do. Any time a runtime API breaks (think things like interfaces to runtime authentication, compute scheduling, database services, network bandwidth scheduling), updated services must be made to conform and then be rolled out. As with real life, this might mean getting a 1 or 2 year old deployment system (configuration for production, roll out code, ...) undusted, understood, probably fixed in turn, etc.
As such, some SRE/SWE team _must_ be responsible for projects that are in the "don't touch"/maintenance phase. This is very unsexy, toil-y and you don't get promoted for it - and as such barely anyone wants to do it at Google.