6 ms·

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

by jddddd 4y ago

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 4y ago
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 4y ago
  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 4y ago
    > 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/Arbeitsbedingungen/Arbeitnehmerschutz/Arbeits-und-Ruhezeiten/Pikettdienst.html https://www.seco.admin.ch/seco/en/home/Arbeit/Arbeitsbedingu...
    - adastra22 4y ago
      They don’t have a concept of “shifts” in Switzerland?
      - morelisp 4y ago
        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 4y ago
        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.
        morelisp 4y ago
        Is that really weird? In a factory, time is produced things is money. 3x shifts is 3x things is probably close to 3x, at worst 2x money. In software development we've long learned that with 3x as many developers you're lucky if you can keep the same pace on the project, let alone improve. (It could be 2-3x as many projects, but then you have 2-3x as many operational problems again.)
        adastra22 4y ago
        And then you have companies like HP that outsourced to India, East Asia, and Eastern Europe and then found that they could have 24-hour employment shifts through timezones. Shared integration and testing infrastructure got reused between teams working on different aspects of the same problem. Support requests got handled by whatever team was online when the request came in, and written up and handed off to the next if the clock struck 5pm.
- deleted 4y ago
  [deleted]

by jddddd 4y ago

4ggr0 4y ago

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 4y ago
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 4y ago
  > 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/Arbeitsbedingungen/Arbeitnehmerschutz/Arbeits-und-Ruhezeiten/Pikettdienst.html https://www.seco.admin.ch/seco/en/home/Arbeit/Arbeitsbedingu...
  - adastra22 4y ago
    They don’t have a concept of “shifts” in Switzerland?
    - morelisp 4y ago
      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 4y ago
        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.
        morelisp 4y ago
        Is that really weird? In a factory, time is produced things is money. 3x shifts is 3x things is probably close to 3x, at worst 2x money. In software development we've long learned that with 3x as many developers you're lucky if you can keep the same pace on the project, let alone improve. (It could be 2-3x as many projects, but then you have 2-3x as many operational problems again.)
        adastra22 4y ago
        And then you have companies like HP that outsourced to India, East Asia, and Eastern Europe and then found that they could have 24-hour employment shifts through timezones. Shared integration and testing infrastructure got reused between teams working on different aspects of the same problem. Support requests got handled by whatever team was online when the request came in, and written up and handed off to the next if the clock struck 5pm.
deleted 4y ago
[deleted]