Hacker News Reader

Comment by vizzier | Hacker News Reader

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.

View on HN

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.

I think the devops-inspired idea of engineers owning what they deploy has become fairly popular, for better or for worse.

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.

> 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.

if your pagerduty/equivalent is doing that, something has gone very wrong at your company

That’s an observability problem, not an on-call problem.

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.

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.

Reply on news.ycombinator.com