1 karma · joined March 10, 2024
I used to think startups would be one of the few places that actually gave a shit about being lean and efficient - but turns out that's only true if they're bootstrapped.
Since this is Google's side of the story its in their interest to use words that would imply she's overbearing, or otherwise unaccommodating
(for all I know she could be all of those things, but this narration isn't sufficient evidence to prove that)
While there might be a vocal minority here (and elsewhere) that scoff at material wealth, its pretty clear that society at large still measures status by your possessions.
People still seek out more luxurious cars, more gadgets, new fashions year after year without fail; evidenced by the unstoppable growth in those industries.
Even if people might say that material riches are a 'sin', they certainly are not behaving as such.
The policy states that only the Operations team gets paid on-call, because I guess in the old days they would be the expected to deal with production.
Fast forward to today, and the Operations folks are a small team managing 2 datacentres, and all on-call rotations between SREs and developers are considered unofficial and therefore not eligible to be paid.
One of our Sr. Managers tried to take this up the chain, but then got reprimanded for putting developers on-call.
_You_ might not be on call for your code, but _somebody_ will be. Often some poor SRE/ops person that has absolutely no idea what the app is doing/or why it's failing in production.
Not being on-call makes engineers complicit. I've seen it all, known memory leaks shipped into production, apps where half the endpoints couldn't even be compiled, code dumping the production redis at 1AM ... and every time the pain just felt on deaf ears.
If your code is what wakes you up in the middle of the night, you have: - Incentive to fix/mitigate as soon as possible. - No blame game to play. Either the error was made by you, or someone on your team. It doesn't have to go up 3 rungs on the ladder then back down again.
I don't think the author was suggesting that everyone should always be on call, just that you _must_ be responsible for your own code in production