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

Developer on Call

henrikwarne.com

Post reply on HN
Print view View original

101–110 of 246 posts

Re: Developer on Call

#101

Post by Verdex_3 »

sevensor wrote: post #90

I see a fair amount of sentiment in this thread that's averse to what from my perspective is a very light on-call schedule. My former employer was a manufacturing plant that operated 24/7. The engineers (not software, mostly chemical, mechanical, and electrical), all of us carried pagers at all times and were expected to phone in within minutes of being paged, any day or night. A bad enough incident would require you…

Like, I can appreciate that things can always be worse. But the other perspective is that what you're describing is objectively bad. And less of a bad thing is still bad.

If I have to option to not do a bad thing (even if it is only minimally bad), then why shouldn't I pursue that option?

If you don't mind doing the bad thing, then you should definitely take advantage of that. But probably shouldn't try to convince other people that the bad thing isn't bad. 1) It reduces your own advantage of willing to do the bad thing which you are hopefully converting into money. And 2) its end game is making people do something they don't enjoy without reason or compensation, which seems bad.

Re: Developer on Call

#102

Post by Verdex_3 »

adetrest wrote: post #94
ownagefool wrote: post #60

Earlier quoted context omitted.

I largely believe developers should be responsible for their work, which includes meeting the support requirements out of hours, and understanding the tooling and instrumentation required to keep their work healthy. However, hiring people and not telling them this is part of the job is insanely unfair. People should get paid for being on-call. Further still, if something is going to wake me up during the night, I wou…

Where it breaks down is when you add a developer are forced to write and deploy shitty code. You know it's broken, told the PO/PM/whoever is in charge, and they refused to listen. Or when new features are more important than fixing bugs.

Hear hear. Give me actual autonomy and I'll happily be responsible for my code. Make me implement a crappy design and then deploy before it's functional and I'll happily send out resumes while other people work nights and weekends trying to fix garbage that was never going to work in the first place.

Re: Developer on Call

#103

Post by dboreham »

Cthulhu_ wrote: post #97
wink wrote: post #89

Earlier quoted context omitted.

This sounds so nice in theory. All those pesky developers refusing to fix their horrible code. While in reality at least in my experience the developer would be very much happy to fix the code, it's just that you don't get any time to do that. It's only new features and new products.

That's exactly a reason why a company should consider having their engineers do support - by the sound of it, there's a support department who - MAYBE - accumulate common questions and send them to a product owner, but in practice they won't and in practice the PO ignores it because there's more important things - in his/her mind - that have precedence.

Pro tip: have your managers do customer support .

Re: Developer on Call

#104

Post by Verdex_3 »

Hendrikto wrote: post #84
ownagefool wrote: post #60

Earlier quoted context omitted.

I largely believe developers should be responsible for their work, which includes meeting the support requirements out of hours, and understanding the tooling and instrumentation required to keep their work healthy. However, hiring people and not telling them this is part of the job is insanely unfair. People should get paid for being on-call. Further still, if something is going to wake me up during the night, I wou…

> I largely believe developers should be responsible for their work Definitely > which includes meeting the support requirements out of hours Definitely not

Division of labor is a thing. I'm good at transforming customer interactions into requirements and then transforming requirements into working code.

I'm not good with dealing with issues with a deployed product while I should be busy living my life.

Re: Developer on Call

#105

Post by ken »

badminton1 wrote: post #22

Waking up a developer should be done as escalation. If resolving an alert requires to "turn it off and on again" you don't need a developer for that. Stress and lack of sleep reduces cognitive performance (what you pay for when hire a developer) and kills employee morale. If you have 2 similar job offers for similar companies, one requires you to be on-call, the other one doesn't... which one would you pick? If you a…

> If resolving an alert requires to "turn it off and on again" you don't need a developer for that.

You need a person to do it, and a developer is-a person. It's funny how our community celebrates stories of startups where they built servers out of Lego and emptied the trash themselves, but can't be bothered to flip a switch ourselves. (Or you could write a program to flip this switch, since that is your profession.)

> If you have 2 similar job offers for similar companies, one requires you to be on-call, the other one doesn't... which one would you pick?

Easy: whichever one was better at the 10 other attributes I value more highly than that. It's vanishingly unlikely that I'd get two job offers from companies which were so similar I'd need to compare the LSB.

> If you are having a very bad on-call week and a recruiter reaches to you, you will be more likely to talk to them, or will be more likely to ask for a raise or just quit.

Perhaps true, but not in any way specific to pager duty. You might be having a very bad debugging week, or a very bad legacy systems integration week, or any other kind of bad week.

> The "skin in the game" argument sucks. Developers are not solely responsible for software quality. Deadlines are often not set by developers.

Deadlines are usually set by managers, and when I worked a place with pager duty, my manager had to be on the rotation, too. That company had a lot of problems, but pager duty was not one of them. He was well aware of how bugs would come back to bite us.

Re: Developer on Call

#106

Post by WrtCdEvrydy »

grecy wrote: post #56

At my last job I was offered a "promotion". More responsibility, more accountability, overseeing junior staff AND on call. No roster, no clear definition of exactly what that would entail, but it was the kind of place that had thousands of system, and every day something was on fire. All of that was offered for the glorious compensation rise of $0. I happily turned down that "promotion" and it was clear the company h…

I would have taken it, added it to my resume, backdated it to my start date at the company and shopped the resume around.

If there's no raise involved, I can only assume you thought I was good enough to do that job from day one.

Re: Developer on Call

#107

Post by sevensor »

roel_v wrote: post #95
sevensor wrote: post #90

I see a fair amount of sentiment in this thread that's averse to what from my perspective is a very light on-call schedule. My former employer was a manufacturing plant that operated 24/7. The engineers (not software, mostly chemical, mechanical, and electrical), all of us carried pagers at all times and were expected to phone in within minutes of being paged, any day or night. A bad enough incident would require you…

"There was no notion of pager duty -- you just always wore a pager." So how much did that pay?

Enough to get me to sign up straight out of school, but not enough to keep me there forever. Their pay scale is pretty generous out of the gate, but it's also pretty flat. The longer you stay, the worse off you are. Attrition in my cohort was about 40% per year.

Re: Developer on Call

#108

Post by Verdex_3 »

krzrak wrote: post #73
patatino wrote: post #46

On my last job somebody told my it's my turn for the support phone. In our case text messages if web based products are down. I never heard of it before, not during my interview or first month, never. I didn't know how to react and said sure, here's my number. After waking up twice during the night I decided to mute my phone completly from 10pm to 7am. Sometimes I woke up and had 50 messages and would try to solve th…

> After waking up twice during the night I decided to mute my phone completly from 10pm to 7am. Have you considered mentioning this to your colleagues, boss or anyone telling you it's your turn? If not - it's really not cool towards your colleagues, boss and organization in general.

You are right. It isn't cool. But I assert that the not cool party is the employer who sprung an on call job requirement without any warning.

Additionally, if this job duty was actually important, then the employer would actually react with some criticism when they discovered that an employee was not performing this duty adequately. The fact that the employer isn't upset about having the on call employee ignoring messages means that it isn't important. Making employees being on call when the employer doesn't actually care about anyone being on call is also not cool.

Re: Developer on Call

#109

Post by sevensor »

Verdex_3 wrote: post #101
sevensor wrote: post #90

I see a fair amount of sentiment in this thread that's averse to what from my perspective is a very light on-call schedule. My former employer was a manufacturing plant that operated 24/7. The engineers (not software, mostly chemical, mechanical, and electrical), all of us carried pagers at all times and were expected to phone in within minutes of being paged, any day or night. A bad enough incident would require you…

Like, I can appreciate that things can always be worse. But the other perspective is that what you're describing is objectively bad. And less of a bad thing is still bad. If I have to option to not do a bad thing (even if it is only minimally bad), then why shouldn't I pursue that option? If you don't mind doing the bad thing, then you should definitely take advantage of that. But probably shouldn't try to convince o…

"Objective" is a pretty slippery word. It's all about context. I'm glad I had that job and worked under those conditions, and I'm glad I left when I did. It was a good thing for me at the start, but then it got old.

Re: Developer on Call

#110

Post by forgottenpass »

I want to point out a pitfall where developer-on-call incentivizes technical debit. I'm not saying not to do it, I'm saying to be careful of it.

The cost of quality documentation, management tools, system reliability and intelligible logging is real. You either have to spend it up front or every time the operational attention needs deep institutional knowledge. Having a developer there to catch your application whenever it falls down means the software deliverable can be be opaque to a level that would be unacceptable to an exclusively operations-oriented audience.

Loosely related example: the support team for manufacturing/service is our engineering department and I field most software issues. If I'm on site, I can pop down, do a quick investigation, and explain how to get everything running again quickly. When I'm off-site or the issue is at another location, the friction of hand-holding someone through the process is just enough to highlight the places that need enhancement.

Post reply on HN