6 ms·

My experience being "on call" as an engineer has mostly not been that you need to write code at 3am. It usually comes down to restarting a machine, deploying a

My experience being "on call" as an engineer has mostly not been that you need to write code at 3am. It usually comes down to restarting a machine, deploying a new machine or copy, or informing the rest of the company that some 3rd party API that you rely on is currently down.

MadnessASAP 2y ago
But that's not engineering work, that's technician or operator work. The engineer comes in later to discuss what went wrong and how to prevent it next time. Speaking as a technician whose seen 3 AM at work many a time.
- geoelectric 2y ago
  I think the devops-inspired idea of engineers owning what they deploy has become fairly popular, for better or for worse.
  - vizzier 2y ago
    For my own part, this wasn't a huge team. We had the knowledge of if the issue was application/software based but would pass back to ops if it was hardware/OS related. One possible bonus, being on call operating your own software also gives you a solid incentive to not wake yourself up in the morning by writing bad code, and fixing those issues that do arise quickly.
    - Viliam1234 2y ago
      > being on call operating your own software also gives you a solid incentive to not wake yourself up in the morning by writing bad code Unfortunately, my software interacts over network with software written by other people; if something goes wrong at 3 AM the users don't know which part caused the problem, so they wake up a random person.
      - fragmede 2y ago
        if your pagerduty/equivalent is doing that, something has gone very wrong at your company
      - sgarland 2y ago
        That’s an observability problem, not an on-call problem.
    - deleted 2y ago
      [deleted]
- sgarland 2y ago
  When I worked at Samsung Austin Semiconductor, it was absolutely the norm to call or text engineers after-hours to weigh in on machine irregularities.
pc86 2y ago
As others alluded to, there's no reason for an engineer making $200k/yr+ to do that. You can document how to recover from those error states and pay someone 25% to handle that.

MadnessASAP 2y ago

But that's not engineering work, that's technician or operator work. The engineer comes in later to discuss what went wrong and how to prevent it next time. Speaking as a technician whose seen 3 AM at work many a time.

geoelectric 2y ago
I think the devops-inspired idea of engineers owning what they deploy has become fairly popular, for better or for worse.
- vizzier 2y ago
  For my own part, this wasn't a huge team. We had the knowledge of if the issue was application/software based but would pass back to ops if it was hardware/OS related. One possible bonus, being on call operating your own software also gives you a solid incentive to not wake yourself up in the morning by writing bad code, and fixing those issues that do arise quickly.
  - Viliam1234 2y ago
    > being on call operating your own software also gives you a solid incentive to not wake yourself up in the morning by writing bad code Unfortunately, my software interacts over network with software written by other people; if something goes wrong at 3 AM the users don't know which part caused the problem, so they wake up a random person.
    - fragmede 2y ago
      if your pagerduty/equivalent is doing that, something has gone very wrong at your company
    - sgarland 2y ago
      That’s an observability problem, not an on-call problem.
  - deleted 2y ago
    [deleted]
sgarland 2y ago
When I worked at Samsung Austin Semiconductor, it was absolutely the norm to call or text engineers after-hours to weigh in on machine irregularities.

pc86 2y ago

As others alluded to, there's no reason for an engineer making $200k/yr+ to do that. You can document how to recover from those error states and pay someone 25% to handle that.