Live data from Hacker News

Developer on Call

henrikwarne.com

181–190 of 246 posts

Re: Developer on Call

#181
post #85

Earlier quoted context omitted.

Do you think "people who fix bugs for customers" don't deserve full night sleep each night?

I don't think you are reading my comment correctly (or generously, as per HN guidelines). I made no such assertion, nor do I believe, what your question implies.

OK, I'm now lost what are you trying to refute. Perhaps reading the comment I was replying to originally for the context would help understanding the point I was addressing. I never mentioned being on-call or having a good sleep at all.

Re: Developer on Call

#182

Earlier quoted context omitted.

In the US we call employment contracts "employment agreements", and we don't tend to think of them as contracts, even though they're legally enforceable as contracts. One of the weird things about living here.

They are absolutely contracts and people who don't treat them as such are just asking for trouble. I don't care what an employer tries to call it. Anything that has legal language and they're expecting me to sign my name on it is a legal contract and I treat it as such.

https://en.wikipedia.org/wiki/Contract#Formation

Re: Developer on Call

#183
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…

Ugh, please no. This interacts poorly with paid leave, and gives management an extra tool of coercion. This has happened with police work and overtime - if you piss off your boss as a cop, you stop getting overtime allocated to you, and wind up getting a pretty significant pay reduction. Or if you get put on paid administrative leave, well, that doesn't include overtime, so that's also a significant pay reduction for police officers.

IMHO the real selling point for a software union would be a union-sponsored tax advantaged retirement plan that is ruthlessly optimized to being employee favored. Lots of startups don't have retirement plans or have shitty ones. Furthermore, lots of companies run into issues with non-discrimination testing for "highly compensated" line engineers. If you get things set up with a multi-employer plan with a pretty lightweight collective bargaining agreement for employers to sign, you can get significant tax advantages.

Re: Developer on Call

#184
post #89

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, "Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?" If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'…

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.

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

I agree. At GitLab, I'm trying to build our "Support Engineering" group into people that have the time and mandate to fix the things that spring up leaving product devs to focus on new features. It's been working pretty well:

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16511 (40% view speedup)

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope...

Re: Developer on Call

#185

It's interesting that both the article and many comments take as a base assumption that on-call should exist and then go into how it should be compensated or structured. I would argue that on-call shouldn't exist at all. If a company wants a system to be supported 24/7 it should have three eight hour shifts. Of course companies balk at this, saying it's too expensive, but if their product isn't worth paying extra for…

In general, 8-hour shifts are more difficult to do than on-call. When you have an on-call duty, you might not get any call at all during the night. However, a shift means you have to be awake during the night which is really bad.

Re: Developer on Call

#186

Earlier quoted context omitted.

So push the burden onto somebody else? Why aren't they allowed to "be busying living [their] life"?

They should be free to live their life. If it turns out that the company doesn't actually have enough money to hire enough people to perform all of the duties that it needs to continue to exist, then that company should cease to exist. Which is desirable over the alternative of having rich company owners externalize their failure to run their company adequately by stealing the lives of employees who don't have the ab…

Spot on. I ended up with a new boss at a new company through an acquisition. He gently asked about me getting on the on-call rotation. Which meant work 24/7 because the company didn't know how to manage technology. I enthusiastically agreed and gave him a big spiel about how this is expected, yada, I'm a team player, yada. I fucking parachuted immediately and gave one day notice.

Re: Developer on Call

#187
I did on-call duty for about 5 years, first as a developer and later as a product manager. I reliably got an extra 10-20% of my salary in compensation and did not really mind doing it.

We received a fee per week and a fee for every incident (150% normal hourly wage). There were between 0 and 10 incidents outside of office hours in a week. Most of the time 0 to 1.

Even though it was part of the job and the compensation was fair, the only thing I miss about it now is the money ;)

Re: Developer on Call

#188

Kayak.com co-founder Paul English on this topic (2010): "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, "Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?" If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they'…

The trouble is that 90% of your calls will be due to user error, and the vast majority will be something you just can’t improve, like people misspelling their own names.

Re: Developer on Call

#189
post #42

Earlier quoted context omitted.

> 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 So much for 40 hour work week. People would be spinning in their graves if they knew what had become of employer-employee relationship.

Even 40 sounds too high to be honest, I've only been in the industry 4 years but already refuse anything more than 30hrs.

Same here. Thirty hours max.

Re: Developer on Call

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

It's actually more complex than that, even. I'm speaking from being an engineer for some time (~13 years) and a product manager now. The issue is that Customer A, B, C, D, and E want Feature A to behave in one way, and Customer N, M, O, P, Q, R, S, T, U, V want Feature A to behave in another way, and those two ways are mutually exclusive insofar as it can't merely be configurable, since Features B-F rely on Feature A…

The problem is not your alphabet of customers but the insistence on calling it feature "a". If the same feature has mutually exclusive specs, it is not one but two features and it is exactly product development's task to make that distinction.
Post reply on HN