Live data from Hacker News

Breaking Up with On-Call

reflector.dev

1–10 of 202 posts

Re: Breaking Up with On-Call

#2
Not to distract from the article, but I'm pretty sure that photo of the guard tower is from Manzanar, one of the concentration camps in California that interned Japanese Americans during WWII. Probably not in great taste to use that photo to represent the idea of "guard duty" in software.

https://en.wikipedia.org/wiki/Manzanar

Re: Breaking Up with On-Call

#3
From my experience working on SaaS, and improving ops at large organizations, I've seen that "on-call culture" often exists inversely proportional to incentive alignment.

When engineers bear the full financial consequences of 3AM pages, they're more likely to make systems more resilient by adding graceful failure modes. When incident response becomes an organizational checkbox divorced from financial outcomes and planning, you get perpetual firefighting.

The most successful teams I've seen treat on-call like a leading indicator - every incident represents unpriced technical debt that should be systematically eliminated. Each alert becomes an investment opportunity rather than a burden to be rotated.

Big companies aren't missing the resources to fix this; they just don't have the aligned incentive structures that make fixing it rational for individuals involved.

The most rational thing to do as an individual on a bad rotation: quit or transfer.

Re: Breaking Up with On-Call

#4
I have no idea what article was trying to convey since on call was poorly defined

I also couldn’t take it seriously when article opened with this.

> Startups cannot afford engineers to baby sit software, big tech does.

Say what? As ops person, I’ve seen multiple startups where devs are drowning in operational issues because software was written enough for feature MVP, ship with poor testing then constantly poke at with sticks to keep it working in hopes they could get enough revenue to not flame out.

Re: Breaking Up with On-Call

#5
As a current SRE, and having worked in a small startup, this doesn't echo my experience at all. What the author describes is possible what we would call "on duty" work, the grunt/maintenance work that comes with big software systems. It's not fun, and most companies/teams have friction getting this sort of work done. It's also however not how my SRE role is defined by any stretch. Our on-call work is much more about support during exceptional, somewhat rare circumstances.

Re: Breaking Up with On-Call

#6

As a current SRE, and having worked in a small startup, this doesn't echo my experience at all. What the author describes is possible what we would call "on duty" work, the grunt/maintenance work that comes with big software systems. It's not fun, and most companies/teams have friction getting this sort of work done. It's also however not how my SRE role is defined by any stretch. Our on-call work is much more about…

Agreed. Author's point of view seemed to have been influenced by their bad experience being part of the "on duty" work.

Re: Breaking Up with On-Call

#7

Not to distract from the article, but I'm pretty sure that photo of the guard tower is from Manzanar, one of the concentration camps in California that interned Japanese Americans during WWII. Probably not in great taste to use that photo to represent the idea of "guard duty" in software. https://en.wikipedia.org/wiki/Manzanar

Eh, intent matters. They probably just googled 'guard tower' and used the first one that looked close enough.

Re: Breaking Up with On-Call

#8

Not to distract from the article, but I'm pretty sure that photo of the guard tower is from Manzanar, one of the concentration camps in California that interned Japanese Americans during WWII. Probably not in great taste to use that photo to represent the idea of "guard duty" in software. https://en.wikipedia.org/wiki/Manzanar

Apart from anything else, a fire tower is a better metaphor for on-call than a guard tower, too.

Re: Breaking Up with On-Call

#9

Not to distract from the article, but I'm pretty sure that photo of the guard tower is from Manzanar, one of the concentration camps in California that interned Japanese Americans during WWII. Probably not in great taste to use that photo to represent the idea of "guard duty" in software. https://en.wikipedia.org/wiki/Manzanar

Eh, intent matters. They probably just googled 'guard tower' and used the first one that looked close enough.

That’s my assumption and why I said something. I’m guessing they didn’t know.

Re: Breaking Up with On-Call

#10
Was author's big tech experience with Amazon?

Because Amazon oncall is ... well it's something. But I'm not sure it's really indicative of the rest of big tech oncall.

Post reply on HN