5 ms·

I've been at my first software engineering gig for 4 years now, we don't have on call, and I've sworn to myself that I will absolutely never take a position wit

I've been at my first software engineering gig for 4 years now, we don't have on call, and I've sworn to myself that I will absolutely never take a position with on-call. I'm a bit worried that it will hamper my career prospects, especially as I've moved to doing more backend work. But I just can't imagine being tied to a work phone on my personal time -- I have a hard enough time enforcing work/life balance as it is.

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
  - deleted 4y ago
    [deleted]
morelisp 4y ago
> I'm a bit worried that it will hamper my career prospects, So honestly, it probably won't, depending on how far you want to go. But lots of the broken teams people are describing here are easily fixed by mandating that the tech lead / architect / whatever participate equally (or more-than-equally) in the on-call process. It's the simplest way to get people with leverage to push back on POs / executives who see it as just a cost to balance. So if you want to have one of those positions one day, and you want to do it well - you should want to do some on-call, because you need to know if the systems and processes you're designing / managing are hell for those on-call.
- adastra22 4y ago
  Or work on a product that isn’t a 24/7 hosted service, and enjoy your evenings and weekends. I’ve never been on call, never will be, and it hasn’t impacted my employment.
  - morelisp 4y ago
    The number of situations where this applies is pretty small though in employment % though, and probably shrinking. I'm curious what you work on. Most things boutique enough to eventually present a "fixed product" today are also usually high-end enough for someone to be doing 24/7 support.
    - adastra22 4y ago
      I’m a research engineer at a innovation lab. HN skews the bias towards online startups. I’d wager most software engineers are not in such roles.
      - morelisp 4y ago
        I agree about HN's skew towards startup, but I think most full-time software engineers support businesses that are essentially available 24/7 or at least 12/7. Anything involving selling online, handling money, any kind of SaaS, or any company with worldwide customer support needs something, even if the main product engineers aren't aware of it (usually to the detriment of the people who are on-call). That's lots of startups, but it's also most blue chips or any kind of infrastructure. > I’m a research engineer at a innovation lab. I mean, assuming this is private, this is either an incredibly biased/exclusive or a very startup-economy-ish job itself. If your company is otherwise big enough to have a lab it's big enough there's on-call teams somewhere, and if you want to be a CTO/VP/DirEng/Architect you'd better know how they work.

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
- deleted 4y ago
  [deleted]

morelisp 4y ago

> I'm a bit worried that it will hamper my career prospects, So honestly, it probably won't, depending on how far you want to go. But lots of the broken teams people are describing here are easily fixed by mandating that the tech lead / architect / whatever participate equally (or more-than-equally) in the on-call process. It's the simplest way to get people with leverage to push back on POs / executives who see it as just a cost to balance. So if you want to have one of those positions one day, and you want to do it well - you should want to do some on-call, because you need to know if the systems and processes you're designing / managing are hell for those on-call.

adastra22 4y ago
Or work on a product that isn’t a 24/7 hosted service, and enjoy your evenings and weekends. I’ve never been on call, never will be, and it hasn’t impacted my employment.
- morelisp 4y ago
  The number of situations where this applies is pretty small though in employment % though, and probably shrinking. I'm curious what you work on. Most things boutique enough to eventually present a "fixed product" today are also usually high-end enough for someone to be doing 24/7 support.
  - adastra22 4y ago
    I’m a research engineer at a innovation lab. HN skews the bias towards online startups. I’d wager most software engineers are not in such roles.
    - morelisp 4y ago
      I agree about HN's skew towards startup, but I think most full-time software engineers support businesses that are essentially available 24/7 or at least 12/7. Anything involving selling online, handling money, any kind of SaaS, or any company with worldwide customer support needs something, even if the main product engineers aren't aware of it (usually to the detriment of the people who are on-call). That's lots of startups, but it's also most blue chips or any kind of infrastructure. > I’m a research engineer at a innovation lab. I mean, assuming this is private, this is either an incredibly biased/exclusive or a very startup-economy-ish job itself. If your company is otherwise big enough to have a lab it's big enough there's on-call teams somewhere, and if you want to be a CTO/VP/DirEng/Architect you'd better know how they work.