[jddddd]

It won't.

On call is a symptom of poorly run company. It's a great signal that you should run far away from any place that requires it.

Most software isn't as critical as we think, and the software that is, is expensive enough to have a properly sized staff.

On call exists for the same reason game devs are paid shit and open source exists... Software engineers don't value themselves properly and love giving away free labor.

[4ggr0]

This sounds like a very software-engineery opinion. Not saying that you're wrong, I understand that on-call is not that important in software development. But as a System Administrator I think that on-call is useful, else we wouldn't notice any outages happening during the night and would then only start working on it in the morning.

Plus, we have customers who actually work during the night, be it timezones or specific industries, so we can't just ignore outages outside of our engineers work-times. And if you're selling SLAs to your customers with promised up-times etc. you better be able to detect and fix something ASAP.

Overall I think "On call is a symptom of poorly run company. It's a great signal that you should run far away from any place that requires it." is a bit too harsh of a statement.

[PeterisP]

IMHO if you want 24/7 monitoring, then you need 24/7 staffing. If you try to offer 24/7 service and sell SLAs without actually having support people working 24/7 shifts and faking it through on-call, that's the sign of a poorly run company who is effectively lying to their customers (by saying you offer 24/7 service when you really don't) and lying to their employees (by saying that they are working a regular-hours job when really they're doing 24+hour work shifts).

[4ggr0]

> IMHO if you want 24/7 monitoring, then you need 24/7 staffing

I've never worked at a company which had 24/7 staff, I guess that would require international teams.

> If you try to offer 24/7 service and sell SLAs without actually having support people working 24/7 shifts [...] that's the sign of a poorly run company

The reason I almost can't agree with this is, that almost everyone I know who's working in IT Engineering/Administration works in on-call. This includes people working at the federal post, railways, biggest banks, largest grocery stores, national TV/Radio etc. And that's all in Switzerland, so I doubt that these companies are all poorly run.

It's also not really lying to customers, because customers know about on-call. They know that people generally fix stuff during business hours, with on-call people watching out for the systems during non-business hours.

I wonder if it's a cultural difference or something. I rarely hear people complain about on-call. Not many especially like it, but it's considered to be a thing you just have to do. Also, everyone I know gets paid extra for on-call, and it being Switzerland, on-call has lots of rules.

If you're interested, here's a webpage where the government writes about on-call and all of its rules and definitions, https://www.seco.admin.ch/seco/en/home/Arbeit/Arbeitsbedingu...

[adastra22]

They don’t have a concept of “shifts” in Switzerland?

[morelisp]

Moving 2/3 of your existing engineering staff to a different shift would raise enormous large communications issues for a company otherwise designed for an aligned workday.

Hiring, say, minimum 4 people to do nothing but waiting for a page would be incredibly wasteful and probably ineffective as they'd have no idea what to do if something went wrong because they didn't work on the system.

[adastra22]

It's a weird thing about the software industry only. I've worked for actual engineering companies (meaning: we build things in factories), where having your factory or expensive integration lab be idle for 2/3 of the day plus weekends is not justifiable. People were scheduled in shifts, and they worked those shifts. And although there was a concentration of people working regular day shift hours, there was always a full team on-site (not on-call!) 24/7. If you weren't on-site, you were never expected to be on-call.