Live data from Hacker News

Developer on Call

henrikwarne.com

171–180 of 246 posts

Re: Developer on Call

#171
post #12
post #3

> Pay. People on call should get paid extra for it I've been on call for 20+ years. I've never gotten paid extra for it. I just figure it's baked into the normal paycheck. As long as everyone on the team is doing on call about the same amount, it doesn't really matter. At the end of the year, it usually works out pretty evenly. > Scheduling. When I have been on call, it has always been one week at a time, I agree wit…

always the on-call engineer, me (the team lead), and then my manager and then their manager. The best scheme in my experience is to have a 24/7 fully staffed L1 working shifts for initial response triage then waking the appropriate L2 to deal with the actual problem if it isn’t covered in the runbook. No good waking the DBA if you can’t login to the database because a router has crashed and failed to failover. The ne…

If you have 24/7 coverage using run books, perhaps a better system would be to take the money you're spending on the 5ish people you need to do 24/7 coverage, and instead pay two people twice as much to codify everything in the run book so that it happens automatically. Then have the alerts go straight to the L2.

Re: Developer on Call

#172

Earlier quoted context omitted.

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

Bad things can work out for your own personal good. Or even the good of the whole of society. However, that doesn't make them not bad. I'm glad that your situation worked out for your own personal good. Nice things happening to people make me happy. Things working out for people make me happy. However, the situation you describe is the latter not the former. That your bad situation, which ultimately worked out for yo…

So if your measure of "objective" goodness is utilitarian calculus, as it seems to be, you're leaving out the fact that employees getting the shaft tends to correlate with cheaper goods and services. I disagree that this is any more objective than my initial assessment that "this is OK for now" or my later assessment that "this sucks, I'm going back to school." But this all comes back to what I said about "objective" being a slippery term. You and I do not agree about what it means.

Re: Developer on Call

#173

1. for every week of oncall a developer should get 1 day off. 2. If developer had to work nights, he should be compensation with additional days off. 3. no payment would reduce the stress so we should not ask for payment compensation. 4. We as developers have let this on us too easily, to eliminate stress devs must form a group and do not sign contracts which do not provide automatic day off for oncall.

This would be the ideal, but in practice (at least where I work) it would lead to empty offices all the time, since everyone would be constantly getting their regular 9-5 time "comped" dealing with whatever fires come up the night before.

Re: Developer on Call

#174
post #154
post #115

There's a lot of words, in the article and the comments, about being compensated for on-call time. The software field seems very anti-union, for reasons that I don't entirely understand. Protecting your time is one feature that unions offer. Want to be paid for every hour you're on call? Get the union to put it in their rules for employers. The alternative we have now is that each developer is responsible for negotia…

A union is a mechanism by which a class of people with less power (typically workers) pool together to enforce rules on people with more power (typically employers). Right now, software developers have LOTS OF POWER. Companies are constantly courting devs, offering very high salaries, and including incredible perks that simply aren't available in most other industries. Yes, some engineers are exploited, but on averag…

[deleted]

Re: Developer on Call

#175
post #48

Earlier quoted context omitted.

Tell me more about this “contract” you speak of. We must work in very different industries if you get anything remotely like what you describe.

If you're not getting a written contract you're not working in the industry, you're the victim of a fraud.

That is simply not true in the US.

By default, in all but one US State, employees can be fired with no notice for no reason (or for any reason other than a handful of specific exceptions like "because of your race"). The legal departments of most companies feel that having a clearly specified contract would weaken this right, so as a matter of policy they do not have contracts with the majority of employees (this includes most tech employees). They have employees sign separate contracts for things like "keeping all the company's secrets", "granting ownership of copyrights and patents" or "promising not to work for any competitor for some length of time", and these contracts are not tied to their salaries.

You are welcome to decide that you don't like this system, but you will find it difficult to find employment.

Re: Developer on Call

#176

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.

One tactic I've used in the past is requiring the PO to be on the calls, otherwise I won't be. However, ultimatly if you work for someone who doesn't care about your quality of live, you should probably move on.

Re: Developer on Call

#177
post #154
post #115

There's a lot of words, in the article and the comments, about being compensated for on-call time. The software field seems very anti-union, for reasons that I don't entirely understand. Protecting your time is one feature that unions offer. Want to be paid for every hour you're on call? Get the union to put it in their rules for employers. The alternative we have now is that each developer is responsible for negotia…

A union is a mechanism by which a class of people with less power (typically workers) pool together to enforce rules on people with more power (typically employers). Right now, software developers have LOTS OF POWER. Companies are constantly courting devs, offering very high salaries, and including incredible perks that simply aren't available in most other industries. Yes, some engineers are exploited, but on averag…

> Right now, software developers have LOTS OF POWER.

This is actually not true in my experience. Having a high salary and perks isn't the same as having power. On-call is a perfect example where, AFAIK, it's not the norm to get paid for it (as a developer at least), and if you don't like it, you're free to get a new job. Except the new job will likely have the same policy.

There are other work-life examples: for example, I've tried to find a part-time job, and to get jobs to offer me more vacation time in lieu of higher pay. Both of these are more common in countries with strong unions, but I've never been able to get them here.

Re: Developer on Call

#178

Earlier quoted context omitted.

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

So then you should probably only work on products that don't require out of hours support, or where the team is willing and able to hire people in another time zone.

Instead, you think some ops guy should do it?

Re: Developer on Call

#179
post #115

There's a lot of words, in the article and the comments, about being compensated for on-call time. The software field seems very anti-union, for reasons that I don't entirely understand. Protecting your time is one feature that unions offer. Want to be paid for every hour you're on call? Get the union to put it in their rules for employers. The alternative we have now is that each developer is responsible for negotia…

If Silly Valley was run like Hollywood, you'd have Version Control Engineers as a class and no one with their Version Control's Guild cards would have any say in that field. (With how Hollywood is run, you might as well have While Loop Engineers.)

I think you're exaggerating a bit. Making movies is multi-disciplinary, where sound vs visuals vs set design are largely different skillsets at the higher levels. Sounds similar to engineering vs design vs product management to me.

Re: Developer on Call

#180

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, which includes meeting the support requirements out of hours Do you think the same about your previous jobs? If they find a bug you wrote you should come in and fix it?

Bit of a straw man, but I imagine products that need 24/7 support would have more than a single owner and would be doing some sort of code review, thus it's not about you being on-call for eternity, just that you should be involved in the process of supporting code so that you write code that is supportable.
Post reply on HN