Hacker News Reader

Comment by WFHRenaissance | Hacker News Reader

I actually love being on-call, especially as a part of a "you build it, you run it" kind of team.

You essentially get a week to find bugs, fortify the application, and make it so that the next person has an easier on-call.

If everyone goes into it with this mindset, eventually on-call becomes a quasi-freebie week where you can either work on "fun stuff", or it becomes invisible.

Not to mention that no product can survive without love and support from its devs.

View on HN

> Not to mention that no product can survive without love and support from its devs.

That's independent from being oncall.

I prefer to spend my non 9-5 time with my wife and daughter. Sadly, many 'innovative' companies out there don't like this mindset of mine and reject people just because they don't want to do oncall rotations.

Besides that, I simply need my rest and sleep to relax and be able to perform again. I love working in a team, as a team. But work is still work for me. I don't really care about some paid company holiday weekend or something. I'd rather do something nice with family or friends.

I'd prefer that as well, however I end up being the one woken up because your (the generic you) code has errors. If you're not willing to be on call I hope you're at least "willing" to be terminated if your code wakes someone up every day of their rotation (yeah, been there).

This is a management/hiring issue. You (generic you) should stop hiring engineers who don't give a frick about their teammates.

If you are not willing to work outside 9-5, if you are not willing to sacrifice your scarce free time, then you must produce perfect bugfree code. Is that?

I have to give it to the companies and to the whole devops/agile movement. They have truly convinced us that being oncall is the right thing somehow. And that non oncall engineers are a somewhat inferior race.

Maybe it’s not about anting to write perfect code but a higher business unit that starts wildfires because a important and influential stakeholder from that one group of high paying customers complained loudly about something not working at 2am and next thing you know there’s a “planning for on call” meeting on your calendar

Ok simplification of affairs here but…I mean…

When the alternative is expecting someone else to give up their scarce free time, yeah, you'd better be producing perfect code or work somewhere that doesn't care about overnight outages.

> Not to mention that no product can survive without love and support from its devs.

If the business wants a stable and well working application, prioritise it as part of regular dev work. As a dev this is certainly not my problem.

There's definitely an incentives issue here. Product just wants more features. I feel like product managers (bad product managers at least) need a countervailing tendency in the form of a resiliency manager or something.

Actually, a great way of managing this sort of stuff is implementing error budgets and SLOs. If you app isn't performant, the next sprint is dedicated to fixing issues, et cetera.

I think my wife would divorce me if I told her I loved being on-call.

I'm young and unmarried, and I work at a company that I like and on a product that I use, so maybe I'm a bit too passionate about my work to be unbiased here lol.

It's atypical for on-call to come with permission to be any less productive at your normal duties.

Not in my experience, but maybe I'm just lucky to have worked at companies with good on-call cultures.

I don’t understand, is on-call not in addition to your normal duties where you work?

I don’t understand how it could tuen into extra time to work on fun stuff.

On well run teams I’ve been a part of it was always understood that you’re not getting much done on your main projects while being primary oncall

Interesting, I’ve never been somewhere where on call entailed more than maybe an incident or two to handle during the week. I can only recall a single instance that interfered with my current sprint.

From the replies, it sounds like a lot of places have constant fires to be put out by those on call?

That doesn’t sound “well run” to me…

Imo oncall engineer should seize the opportunity and fix that warning alert that’s been firing for ages before it becomes an active fire. So consequently there’s usually no lack of things to do even if no fires occured

Fair enough. I wish we structured it like that, so I could actually spend time on tech debt.

I can't imagine telling an engineer to temporarily take more week on a given week. Every company I've worked at has done it like this:

Not on-call engineers work on 20 story points a sprint (2 week sprints). On-call engineers (if you're on-call for a week) get 10 points of work + on-call.

That depends. If your oncall is spent fixing bugs in your product - great. If you're just chasing whatever "upgrade campaign" some other corp team came up with, but forgot to properly document - not so great.

Unless of course you didn’t build the system, just inherited it

Yeah, this is sort of hell on earth in many ways. Hence why I specified "you build it, you run it". On-call for a legacy system with no owner and few active devs is hell, and I don't recommend it.

Reply on news.ycombinator.com