[badminton1]

Waking up a developer should be done as escalation.

If resolving an alert requires to "turn it off and on again" you don't need a developer for that.

Stress and lack of sleep reduces cognitive performance (what you pay for when hire a developer) and kills employee morale.

If you have 2 similar job offers for similar companies, one requires you to be on-call, the other one doesn't... which one would you pick?

If you are having a very bad on-call week and a recruiter reaches to you, you will be more likely to talk to them, or will be more likely to ask for a raise or just quit.

The "skin in the game" argument sucks. Developers are not solely responsible for software quality. Deadlines are often not set by developers.

[ken]

> If resolving an alert requires to "turn it off and on again" you don't need a developer for that.

You need a person to do it, and a developer is-a person. It's funny how our community celebrates stories of startups where they built servers out of Lego and emptied the trash themselves, but can't be bothered to flip a switch ourselves. (Or you could write a program to flip this switch, since that is your profession.)

> If you have 2 similar job offers for similar companies, one requires you to be on-call, the other one doesn't... which one would you pick?

Easy: whichever one was better at the 10 other attributes I value more highly than that. It's vanishingly unlikely that I'd get two job offers from companies which were so similar I'd need to compare the LSB.

> If you are having a very bad on-call week and a recruiter reaches to you, you will be more likely to talk to them, or will be more likely to ask for a raise or just quit.

Perhaps true, but not in any way specific to pager duty. You might be having a very bad debugging week, or a very bad legacy systems integration week, or any other kind of bad week.

> The "skin in the game" argument sucks. Developers are not solely responsible for software quality. Deadlines are often not set by developers.

Deadlines are usually set by managers, and when I worked a place with pager duty, my manager had to be on the rotation, too. That company had a lot of problems, but pager duty was not one of them. He was well aware of how bugs would come back to bite us.

[badminton1]

If your sleep gets interrupted 5 times the same night because of tech debt you are not allowed to fix, or if you are having dinner with your family and you get paged 3 days in a row, I guarantee you that you will lose your shit.

[mrweasel]

Absolutely. I work for a company that does operations, that include 24/7 on-call, monitoring and incident management.

We basically run software that someone bought from a dev-shop or wrote themselves. 90% of the time restarting a service fixes the issue right now. If it happens more than once, you asses if it's worth waking a developer and what the likely hood of him fixing the bug is. Normally you'd need a new deployment anyway, and you don't really want to do that at 3AM, better to wait until the morning.

You do need to have developer on call, to some extend, but if you have to call them more than once or twice a year, something not right. In those cases, where the same buggy software is a fault for waking you multiple times a week, it not a developer you want on call, it's a project manager or what ever type of middle management is involved.

The issue is that the developers actually do want to fix bug, and write stable software. From a middle management perspective: if someone is up during the night to reboot servers and hand held data imports, then that's a fixes issue, and the developers can focus on new features.

I assure you that if you call up managers at 2AM to tell them that the software they are responsible for has a bug, they will start focusing on stability.