Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oncall shift should be Tuesday to Tuesday

arthur-johnston.com

Post reply on HN
Print view View original

141–150 of 230 posts

Re: Oncall shift should be Tuesday to Tuesday

#141

Post by ggeorgovassilis »

deathanatos wrote: post #125
sed_zeppelin wrote: post #104

I just want to jump in as a minority voice here. In case anybody is reading the other comments and feeling... alienated. I refuse to accept on-call duties, full stop. If a job posting expects it, I don't apply. If a hiring manager says they have it, I do not accept the offer. If management starts talking about maybe implementing it, I protest. If it becomes enacted, I resign. There is absolutely no situation in which…

You expect to not be responsible for what happens to the software you put into production? (… and I'd like to avoid distracting arguments that amount to "my company does on-call badly" — yeah, those problems do exist and we should strive to fix them. But if I'm to not categorize the argument here as the baby with the bathwater, then we need something to replace on-call with. Prod goes down on a Saturday afternoon; ar…

> You expect to not be responsible for what happens to the software you put into production?

First: IT seems to be rather the exception - most professions have no on-call. Eg. even if my car mechanic screws up a service job, they'll have me bring the car back into the garage during their normal working hours, regardless of how and where stranded I am in the middle of the night.

A second comment: I'll be responsible for anything I have created in my own way. The reality of software development is that we implement functional requirements we've been given with which we disagree, we implement non-functional requirements which don't achieve the goal, we are made to use frameworks and tools we're not familiar with, on a short timeline, a low budget and inadequate infrastructure and we're supposed to take responsibility for code our co-workers wrote.

Re: Oncall shift should be Tuesday to Tuesday

#142

Post by stackskipton »

badgersnake wrote: post #140
stackskipton wrote: post #118

Earlier quoted context omitted.

As SRE, strongly disagree. On Call is like hiring civil and structural engineers then holding them responsible when their poor bridge collapses under the weight of all the traffic. Sometimes, yes, Devs get called out for stuff outside their control like infrastructure failing. However, at my job, we just had two devs that quit over on call and guess what, their service was one of worst offenders in "Opps, we pushed b…

Give them the time and budget to build it like a bridge then. Oh wait, your competitors beat you to market by several years. Making people work 24/7 is not conducive to good anything, thus on call is a terrible way to do things.

On call shouldn't have 24/7 responsibilities. For example, I'm on call and took a call this morning due to MySQL Server running out of space. Terraform change later, it's no longer out of space and I'm back to my day. I'll take 30 minutes it took me to resolve out of my normal time elsewhere.

If on call balloons your 40 hours to 70 hours, yes, you have an issue. That's not normal and you should consider changing jobs.

Re: Oncall shift should be Tuesday to Tuesday

#143

Post by tgma »

crossroadsguy wrote: post #36
tgma wrote: post #33

Earlier quoted context omitted.

Daily might be okay for more ops/SRE types, but it is a hell for a primarily dev team. Can't focus on building shit.

In some cases it might help. Because then it becomes “natural” - on-call thing. It’s not something someone dreads as in “god, that week is coming”. Also, it spreads the fuck-ups and peaceful times better.

Increasing hand-offs by 7x is sub-optimal and interferes with folks wanting to take continuous vacation time. Again, I can see for ops teams that could be true, but very much disagree that on-call should be a "natural" thing for dev teams in the first place. It can be a necessary evil that should be minimized (the personality of people who like firefighting and quiet development are quite distinct and there are people who actually like the former.) On the latter point, I think that benefit is very much a mirage. If there's a flaw in the system causing a "bad week," it actually might be easier for the first person who gets the hang of it to deal with it than to try handing off and teaching the next one in the rotation.

Re: Oncall shift should be Tuesday to Tuesday

#144

Post by [deleted] »

sed_zeppelin wrote: post #104

I just want to jump in as a minority voice here. In case anybody is reading the other comments and feeling... alienated. I refuse to accept on-call duties, full stop. If a job posting expects it, I don't apply. If a hiring manager says they have it, I do not accept the offer. If management starts talking about maybe implementing it, I protest. If it becomes enacted, I resign. There is absolutely no situation in which…

[deleted]

Re: Oncall shift should be Tuesday to Tuesday

#145

Post by Retric »

deathanatos wrote: post #125
sed_zeppelin wrote: post #104

I just want to jump in as a minority voice here. In case anybody is reading the other comments and feeling... alienated. I refuse to accept on-call duties, full stop. If a job posting expects it, I don't apply. If a hiring manager says they have it, I do not accept the offer. If management starts talking about maybe implementing it, I protest. If it becomes enacted, I resign. There is absolutely no situation in which…

You expect to not be responsible for what happens to the software you put into production? (… and I'd like to avoid distracting arguments that amount to "my company does on-call badly" — yeah, those problems do exist and we should strive to fix them. But if I'm to not categorize the argument here as the baby with the bathwater, then we need something to replace on-call with. Prod goes down on a Saturday afternoon; ar…

I don’t put things in production, the company does. And it’s the companies responsible to deal with problems that show up.

24/7 coverage is expensive and mandating someone is on call 24/7 don’t actually provide it.

Re: Oncall shift should be Tuesday to Tuesday

#146

Post by mikeocool »

ggeorgovassilis wrote: post #141
deathanatos wrote: post #125

Earlier quoted context omitted.

You expect to not be responsible for what happens to the software you put into production? (… and I'd like to avoid distracting arguments that amount to "my company does on-call badly" — yeah, those problems do exist and we should strive to fix them. But if I'm to not categorize the argument here as the baby with the bathwater, then we need something to replace on-call with. Prod goes down on a Saturday afternoon; ar…

> You expect to not be responsible for what happens to the software you put into production? First: IT seems to be rather the exception - most professions have no on-call. Eg. even if my car mechanic screws up a service job, they'll have me bring the car back into the garage during their normal working hours, regardless of how and where stranded I am in the middle of the night. A second comment: I'll be responsible f…

> IT seems to be rather the exception

I think there’s actually a fair number of jobs where some level of this is expected.

Doctors are one obvious example — they have on call responsibilities often more onerous than IT, and depending on the situation don’t always receive additional compensation for it.

If you manage people who work different hours from you, in a lot of jobs it’s not uncommon to be called in if shit hits the fan when you’re not working (for example if you’re a hotel manager, to just name one).

I’ve found that any good lawyer I’ve worked with will answer my calls and help me work through things at basically any time of day (their firm might be billing me for the time, but that doesn’t necessarily directly translate to their comp).

Lots of reporters are expected to cover news that breaks on their beat, no matter when it happens.

Re: Oncall shift should be Tuesday to Tuesday

#147

Post by Retric »

al_borland wrote: post #130
deathanatos wrote: post #125

Earlier quoted context omitted.

You expect to not be responsible for what happens to the software you put into production? (… and I'd like to avoid distracting arguments that amount to "my company does on-call badly" — yeah, those problems do exist and we should strive to fix them. But if I'm to not categorize the argument here as the baby with the bathwater, then we need something to replace on-call with. Prod goes down on a Saturday afternoon; ar…

My boss recently started an on-call rotation for us. None of the code I have written is customer facing. If everything I wrote breaks at 5:01pm on Friday, external customers will feel 0 impact if I wait to fix it until I show up again on Monday. Worst case, someone internal has to wait to work on something they’ve probably been putting off for months anyway. There are other things they can work on. If it was a consta…

It is a demotion.

Re: Oncall shift should be Tuesday to Tuesday

#148

Post by Retric »

stackskipton wrote: post #142
badgersnake wrote: post #140

Earlier quoted context omitted.

Give them the time and budget to build it like a bridge then. Oh wait, your competitors beat you to market by several years. Making people work 24/7 is not conducive to good anything, thus on call is a terrible way to do things.

On call shouldn't have 24/7 responsibilities. For example, I'm on call and took a call this morning due to MySQL Server running out of space. Terraform change later, it's no longer out of space and I'm back to my day. I'll take 30 minutes it took me to resolve out of my normal time elsewhere. If on call balloons your 40 hours to 70 hours, yes, you have an issue. That's not normal and you should consider changing jobs…

Waking someone up is going to cost far more than the time spent fixing the issue.

Re: Oncall shift should be Tuesday to Tuesday

#149

Post by regularfry »

> Highly scrum/agile focused people have brought up that sprints start on Monday and that starting the oncall on Tuesday makes sprint planning harder

Wait, what? Don't run your sprints Monday to Monday either. That's been the eventual conclusion on all scrum teams I've been on.

Re: Oncall shift should be Tuesday to Tuesday

#150

Post by mikedelfino »

hn_go_brrrrr wrote: post #135
rufus_foreman wrote: post #129

Earlier quoted context omitted.

>> You expect to not be responsible for what happens to the software you put into production? I'm responsible for the software I put into production from 9 AM to 5 PM for about 200 days a year. At 3 AM, I am responsible for taking care of myself by getting a good night's sleep. If you need 24 hour coverage, taking into account vacations and weekends, you need 5 or 6 people.

"you need 5-6 people" is moving the goalposts. The root comment said nothing about minimum team size.

If the company has enough people in the team, someone just works the night shifts or on scheduled weekends. No one needs to be on-call because there would be someone taking care of it already.
Post reply on HN