|
|
|
|
|
by _diq5
2160 days ago
|
|
Want to jump in here - I have worked at a company where engineers are not on call for their code, and it was a living nightmare. _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 |
|
...but with that said: I'm glad I only worked in countries where work is properly regulated and "on call" means "I'm getting fucking paid every cent for each hour I _must_ answer that goddamn phone". Which in practice means there's no PagerDuty.
The unpaid on-call culture is bullshit. The company can either pay me or go fuck itself.