Hacker News Reader

Comment by xtracto | Hacker News Reader

I am quit amazed at the general reaction of this forum to this standard industry practice.

If you want a cushy 9-5 job, go work for a code factory like HCL, TCS and whatnot. That way you can build crap and wash your hands after handling it to the customer.

In a startup environment, you gotta build your shit and maintain it to. It's an environment that's not for everyone.

I've been in oncall roosters several times in the past. And it made freaking sure we wrote the best software we could.

I also have been on the management side of it, and the way I set it up is that whoever was the oncall engineer, if he had to work for more than 2 hours after normal working hours, he would get an additional PTO day. It actually worked quite well.

View on HN

I think most experienced engineers realize on-call is a complete fool's game -- you will never get accolades for fixing shit at 2am. Literally never. Your only "reward" will be to become the escalation point to continue getting called at 2am. It's not only mentally demanding work, but also bottom-feeding work that gets no recognition. No one is doing their best work after being woken up in the middle of the night, it's all band-aid hacky fix shit that is being generated. Also in general the type of personality who would tolerate working 2+ hours beyond their working time is probably the type of person that isn't even going to use up all of their PTO to begin with, so I always find those kinds of rewards laughable.

I don't find your experience to be the general case, though that doesn't invalidate your point. Accolades are an easy intangible reward to hand out so you will often see it given for heroics. Extra cash would be better. PTO is somewhere in the middle. On teams that can rotate through on-call, bonus PTO is more likely to be used than on ones where one or two engineers shoulder the responsibility all year.

Well, putting the pipe dreams people have about a global team so nobody is ever working outside regular working hours aside (hope you've considered holidays, guys), what's the alternative? One I've seen is that there's an ops, or "devops," team, that's responsible for picking up the slack instead. But if it's unfair for engineers to have to do it, it seems even less fair for someone who doesn't even have control over what code ships to do it, and to do it without a rotation.

> what's the alternative?

Let it crash. If you can't afford to pay people enough that someone /wants/ to fix it at 2am, and you can't arrange a retainer for a contractor halfway around the world to be available if needed during their worktime, and you (owner/manager) don't want to do it yourself, then it can be off until someone starts at 9am next business day. (Most products and services aren't life critical).

I think the whole point of the article and the discussion is that many people don’t want to do it even when paid enough.

Nobody on any of the threads is arguing that you should not be paid more for being on call.

The issue with being on call constantly is, that you have to basically give up any private life you should have. Your daughters theatre play? Sad to interrupt! Your long awaited weekend trip with your girlfriend? Would be a shame if you had to cancel!

The quality of life lost by being on call is not insignificant. This is why being on call should always be the absolute exception and not a reliable, planned in, tool at your companies disposal.

If you regularily fail to organize your core business around business hours, maybe you should get someone who is good at planing projects and communicating these plans and put them in charge? Or maybe just close your company and search for a different career path if you are unable to plan your projects?

This is kind of absurd. The point of on-call is not to have regular off-hours work, but to have someone available for emergent situations. Since anybody who intends to operate a service with constant availability must always have someone who can respond to emergencies, on-call is the system used by the world's most successful tech companies, not just two-bit upstarts. It's hard to imagine anybody serious about running any kind of online business who is going to respond to an outage on Friday night by saying "we'll look at on Monday at 9:00 PT." It's unfortunate, but it's really not that different from ER doctors, firefighters, utility workers, and numerous other workers working with similar constraints.

Besides that, the rotation is known, and planned for, long in advance. So your "long-awaited weekend trip" shouldn't have been scheduled during your on-call shift in the first place.

They can pay me enough that I’ll do it but not enough that I’ll want to do it.

You've probably just described most jobs.

Yeah, and this is a relatively good one, so let's have some perspective.

I'm replying to the post saying this is an "industry standard" thing--I'm not saying that there is no disaster scenario ever. Obviously not every contingency can be planned.

However, there are certainly signals that a company respects a developers' time. Things like...was there effort put in the product around things that might minimize developer on-call time, like having more user self-serve options, or spending more time on testing, or having a proper feedback loop for recurring issues to be permanently squashes in a timely fashion, etc etc. Are managers regularly a part of these off-hour on-call issues so they're affected too, thus motivated to resolve it? Or does the company just abusively unload all of the burden on the developer and force them to use up their own personal time to maintain a product? Far too often it's the latter, and I think it should be clear to all that this is abusive practice and not "normal" or "standard" nor should any of us consider it that way.

Sure, but no matter how many measures you take, on-call still means you have to be available, so it’s a drag even if it’s quiet.

>If you want a cushy 9-5 job, go work for a code factory like HCL, TCS and whatnot. That way you can build crap and wash your hands after handling it to the customer.

You got it backwards: if you want a crappy quality of life (or have no life and you only identify with the company that sees you as a replaceable cog), and crappy products and customer service from a company that doesn't care (to plan right, to hire accordingly, to treat its staff right) go on call and overwork, producing sleep-derived crap.

Craftsmen and artisans take their time and have boundaries.

"Feature factories", startups, and mass market crap companies forego 9-to-5 and indoctrinate naive employees that they do something important by doing so.

>In a startup environment, you gotta build your shit and maintain it to. It's an environment that's not for everyone.

Yes. It's for starry-eyed naive youngsters right off the bus. The kind of people to believe they're "changing the world" by building a Facebook or Groupon.

> Craftsmen and artisans take their time and have boundaries.

I've been an engineer on-call for 7 years since graduating. In the meantime I handled a handful of business critical situations, developed my ability to keep cool during crisis and put my skills to the test. When I started doing it, I wasn't even paid for on-call. Now I am. The money has no bearing on me having been exploited or not. I've done it because it's cool, and when I think it's too tiring I won't do it anymore.

Am I less of an engineer, not a true craftsman (wtv that means), because of this? There's other opinions in the world, no need to be so close minded.

When you were doing on-call without being paid, that's called wage theft. It's the single biggest kind of theft in North America: https://www.epi.org/publication/wage-theft-bigger-problem-fo...

It's also the kind of theft that insidiously convinces you that it's really cool and that you're actually OK with it because you're learning how to 'keep cool during crisis'. You know how else your employers could have taught you that? By providing actual training during working hours, while you were being paid.

I mean this with all the respect in the world, but I think you've gotten yourself caught in an ideological bubble here. To someone who doesn't already agree with you, this comment sounds like an argument against the concept of wage theft more than an argument against oncall. After all, you can't prove something's bad just by classifying it under a nasty-sounding label!

I purposefully did not make an argument against on-call, although I might have easily done that and others have in this thread. All I said is that doing on-call without pay is wage theft. And this is not an ideological bubble thing, as anyone will quickly understand if they ask a plumber to do on-call for their house plumbing system without pay.

A better analogy would be a plumber you pay a handsome annual salary to maintain and improve your pipes--to what degree should they owe some emergency time in return is the question in this thread.

Plumbers (or companies employing plumbers) warranty their work. Do employees warranty their work for employers? I have never heard of that arrangement in the US.

I haven’t heard of that here either. The closest I can think of are sanctions that can be levied on individual employees by professional standards organizations. I do know trades warranties aren’t provided by employees working in that trade to their employer, just to customer individuals or organizations.

I think a another analogy is that you had a plumber do some work for you a day before a leak, and in the middle of the night the pipes start leaking and you need to call him out to prevent property damage. In that case I would absolutely not expect to have to pay extra because he warranties his own work.

To be fair, if they are so far off the end that they think "man, getting called up at 2am without being paid was great because I learned how to keep my cool during a crisis!" then they are probably a lost cause.

It's fine to drink of the chalice of the corporate kool aid with moderation. Still, one should never get black out drunk out of it.

This "us vs them" concept is where I think we've lost the plot. Remember that we're the experts in complex systems that we've been selling to the business to add value and we've been happily taking their money for decades. When they ask "can the technology support this?" we, like an eager child showing off our new toy, assure them that it can and beg them to let us prove it.

We can't just chunk these complex systems over the wall and say "have fun with that" and demand more money when the solution breaks. This means we failed to properly estimate total cost of ownership when we sold them the system and now they're held hostage. This is borderline legal breach of contract.

If we told them the true sustainable cost of ownership for a follow the sun support model they likely would have never purchased the solution in the first place and we'd be out of a job.

We could have lots of annoying jobs or no jobs at all. I'll happily accept the former.

I don't know about you but I'm not 'selling' my work to the business like a black box, I am working under the direct supervision of the business and any and all work that I do is the result of a team effort and direction from management, non-engineering, and engineering staff. Let me emphasize: all the work that gets put into production is a team effort and a team responsibility.

I'm not begging anyone to let me prove my technology, I'm working with management to come up with a solution that will work for the customer. Oftentimes management will forbid or otherwise prevent me from using a better, more robust technology that would have prevented more production issues because of short-sightedness. If I pointed this out and was still told to go ahead with the short-sighted solution, and it breaks in production, whose fault is that?

I'm not suggesting the 'it's your problem now, have fun' approach, I'm suggesting the 'pay overtime for overtime work' approach. This is nowhere even near to 'breach of contract', please don't throw around lawyer-like terms when you clearly don't understand what's being discussed.

>In the meantime I handled a handful of business critical situations, developed my ability to keep cool during crisis and put my skills to the test.

That's great, but you could still have done all those things if you were being compensated appropriately for the extra time you were putting in.

It's like unpaid internships. I'm sure unpaid interns often do learn useful skills and make useful connections. But the practice is still exploitative.

>The money has no bearing on me having been exploited or not. I've done it because it's cool

Convincing them of the "coolness" of it is the most common way to exploit the naive/fresh.

The same people who do so to others, wouldn't even piss if they weren't compensated for it...

(And being exploited or not is not a personal decision. If you aren't compensated for overtime, then you are exploited. It just means you're ok with it.).

There's nothing in the world you'd do for free for a while for the chance of doing it? And I'm the naive one? Is money all there is in life in this comment section?

Also: For some people these nights might have been the only times they connected to their team mates on a different level.

I had that too, but it was for art projects, films, music, my own programming projects or some other thing that I certainly did not do for money.

The one thing that differs here is that the people I did this for/with would cross the country if I told them I am in need.

i'd never heard of a "feature factory" before, but after reading about them, holy hell, that explains a ton of friction i had in a recent engagement.

they had a laser focus on just shipping and success theater, but little attention on actual utility of the end product. i was berated constantly for slowing things down or wanting to be more careful and do things that weren't necessarily easy but actually had potential to be useful. it's relieving to learn this is a common management deficiency.

> Craftsmen and artisans take their time and have boundaries.

Yeah but most of the people complaining only think they are Craftsmen but their day job is to write bad software to push ads

You do understand that most startups fail, right? Clearly, on aggregate, their practices are not really working or worthy of imitation. For the ones that succeed, there's a huge element of luck. Otherwise people would make guarantees about success.

Reply on news.ycombinator.com