Being on call sucks • Hacker News Board

Re: Being on call sucks

#271

Post by morelisp » Thu, Jul 21, 2022, 3:07 PM UTC

adastra22 wrote: post #267

morelisp wrote: post #182

Earlier quoted context omitted.

> I'm a bit worried that it will hamper my career prospects, So honestly, it probably won't, depending on how far you want to go. But lots of the broken teams people are describing here are easily fixed by mandating that the tech lead / architect / whatever participate equally (or more-than-equally) in the on-call process. It's the simplest way to get people with leverage to push back on POs / executives who see it a…

Or work on a product that isn’t a 24/7 hosted service, and enjoy your evenings and weekends. I’ve never been on call, never will be, and it hasn’t impacted my employment.

The number of situations where this applies is pretty small though in employment % though, and probably shrinking.

I'm curious what you work on. Most things boutique enough to eventually present a "fixed product" today are also usually high-end enough for someone to be doing 24/7 support.

Re: Being on call sucks

#272

Post by adastra22 » Thu, Jul 21, 2022, 3:46 PM UTC

morelisp wrote: post #271

adastra22 wrote: post #267

Earlier quoted context omitted.

Or work on a product that isn’t a 24/7 hosted service, and enjoy your evenings and weekends. I’ve never been on call, never will be, and it hasn’t impacted my employment.

The number of situations where this applies is pretty small though in employment % though, and probably shrinking. I'm curious what you work on. Most things boutique enough to eventually present a "fixed product" today are also usually high-end enough for someone to be doing 24/7 support.

I’m a research engineer at a innovation lab.

HN skews the bias towards online startups. I’d wager most software engineers are not in such roles.

Re: Being on call sucks

#273

Post by morelisp » Thu, Jul 21, 2022, 4:54 PM UTC

adastra22 wrote: post #272

morelisp wrote: post #271

Earlier quoted context omitted.

The number of situations where this applies is pretty small though in employment % though, and probably shrinking. I'm curious what you work on. Most things boutique enough to eventually present a "fixed product" today are also usually high-end enough for someone to be doing 24/7 support.

I’m a research engineer at a innovation lab. HN skews the bias towards online startups. I’d wager most software engineers are not in such roles.

I agree about HN's skew towards startup, but I think most full-time software engineers support businesses that are essentially available 24/7 or at least 12/7. Anything involving selling online, handling money, any kind of SaaS, or any company with worldwide customer support needs something, even if the main product engineers aren't aware of it (usually to the detriment of the people who are on-call). That's lots of startups, but it's also most blue chips or any kind of infrastructure.

> I’m a research engineer at a innovation lab.

I mean, assuming this is private, this is either an incredibly biased/exclusive or a very startup-economy-ish job itself. If your company is otherwise big enough to have a lab it's big enough there's on-call teams somewhere, and if you want to be a CTO/VP/DirEng/Architect you'd better know how they work.

Re: Being on call sucks

#274

Post by morelisp » Thu, Jul 21, 2022, 5:02 PM UTC

adastra22 wrote: post #266

4ggr0 wrote: post #265

Earlier quoted context omitted.

> IMHO if you want 24/7 monitoring, then you need 24/7 staffing I've never worked at a company which had 24/7 staff, I guess that would require international teams. > If you try to offer 24/7 service and sell SLAs without actually having support people working 24/7 shifts [...] that's the sign of a poorly run company The reason I almost can't agree with this is, that almost everyone I know who's working in IT Enginee…

They don’t have a concept of “shifts” in Switzerland?

Moving 2/3 of your existing engineering staff to a different shift would raise enormous large communications issues for a company otherwise designed for an aligned workday.

Hiring, say, minimum 4 people to do nothing but waiting for a page would be incredibly wasteful and probably ineffective as they'd have no idea what to do if something went wrong because they didn't work on the system.

Re: Being on call sucks

#275

Post by varispeed » Thu, Jul 21, 2022, 5:20 PM UTC

I only ever agreed to be on call if I was compensated full rate plus an extra for being outside of core hours.

If you are on call, you are working and your job is to pick up the call as soon as you hear it and then act on it for the given period of time.

I don't understand why people agree to do this basically for free.

Re: Being on call sucks

#276

Post by adastra22 » Thu, Jul 21, 2022, 6:27 PM UTC

morelisp wrote: post #273

adastra22 wrote: post #272

Earlier quoted context omitted.

I’m a research engineer at a innovation lab. HN skews the bias towards online startups. I’d wager most software engineers are not in such roles.

I agree about HN's skew towards startup, but I think most full-time software engineers support businesses that are essentially available 24/7 or at least 12/7. Anything involving selling online, handling money, any kind of SaaS, or any company with worldwide customer support needs something, even if the main product engineers aren't aware of it (usually to the detriment of the people who are on-call). That's lots of…

There are vast amounts of software engineering roles you are ignoring. Pretty much all of embedded firmware or hardware driver development. The entire video game industry excluding online play. The many software developers that provide solutions for enterprise software with 9-5 support contracts. Mobile app developers. Whole fields of consulting and integration experts that set their own hours. Pretty much every data scientist or machine learning role ever.

It is online services that are niche. It's just what this website is mostly focused on so it seems more prominent.

Re: Being on call sucks

#277

Post by adastra22 » Thu, Jul 21, 2022, 6:33 PM UTC

morelisp wrote: post #274

adastra22 wrote: post #266

Earlier quoted context omitted.

They don’t have a concept of “shifts” in Switzerland?

Moving 2/3 of your existing engineering staff to a different shift would raise enormous large communications issues for a company otherwise designed for an aligned workday. Hiring, say, minimum 4 people to do nothing but waiting for a page would be incredibly wasteful and probably ineffective as they'd have no idea what to do if something went wrong because they didn't work on the system.

It's a weird thing about the software industry only. I've worked for actual engineering companies (meaning: we build things in factories), where having your factory or expensive integration lab be idle for 2/3 of the day plus weekends is not justifiable. People were scheduled in shifts, and they worked those shifts. And although there was a concentration of people working regular day shift hours, there was always a full team on-site (not on-call!) 24/7. If you weren't on-site, you were never expected to be on-call.

Re: Being on call sucks

#278

Post by morelisp » Thu, Jul 21, 2022, 7:28 PM UTC

adastra22 wrote: post #277

morelisp wrote: post #274

Earlier quoted context omitted.

Moving 2/3 of your existing engineering staff to a different shift would raise enormous large communications issues for a company otherwise designed for an aligned workday. Hiring, say, minimum 4 people to do nothing but waiting for a page would be incredibly wasteful and probably ineffective as they'd have no idea what to do if something went wrong because they didn't work on the system.

It's a weird thing about the software industry only. I've worked for actual engineering companies (meaning: we build things in factories), where having your factory or expensive integration lab be idle for 2/3 of the day plus weekends is not justifiable. People were scheduled in shifts, and they worked those shifts. And although there was a concentration of people working regular day shift hours, there was always a f…

Is that really weird? In a factory, time is produced things is money. 3x shifts is 3x things is probably close to 3x, at worst 2x money. In software development we've long learned that with 3x as many developers you're lucky if you can keep the same pace on the project, let alone improve. (It could be 2-3x as many projects, but then you have 2-3x as many operational problems again.)

Re: Being on call sucks

#279

Post by morelisp » Thu, Jul 21, 2022, 7:38 PM UTC

adastra22 wrote: post #276

morelisp wrote: post #273

Earlier quoted context omitted.

I agree about HN's skew towards startup, but I think most full-time software engineers support businesses that are essentially available 24/7 or at least 12/7. Anything involving selling online, handling money, any kind of SaaS, or any company with worldwide customer support needs something, even if the main product engineers aren't aware of it (usually to the detriment of the people who are on-call). That's lots of…

There are vast amounts of software engineering roles you are ignoring. Pretty much all of embedded firmware or hardware driver development. The entire video game industry excluding online play. The many software developers that provide solutions for enterprise software with 9-5 support contracts. Mobile app developers. Whole fields of consulting and integration experts that set their own hours. Pretty much every data…

> Pretty much all of embedded firmware or hardware driver development.

Any hardware used in something that has an on-call process, itself has an on-call process (or is from somewhere large enough to offer follow-the-sun support). As I said it may not involve the same engineers, but it's there.

> The entire video game industry excluding online play.

That's also a vanishingly small portion of employment in the games industry.

> Mobile app developers.

Again, most mobile apps are... for some kind of web service, or have some kind of backend, and so have some kind of on-call team.

> The many software developers that provide solutions for enterprise software with 9-5 support contracts

Examples? Just because not everyone is paying for the 5-9 contract, doesn't mean it's not there.

> Whole fields of consulting and integration experts that set their own hours.

Yes. What percentage of the industry is independent consultants? Why would you include them when I already qualified "full-time software engineers"?

Re: Being on call sucks

#280

Post by adastra22 » Thu, Jul 21, 2022, 11:25 PM UTC

morelisp wrote: post #278

adastra22 wrote: post #277

Earlier quoted context omitted.

It's a weird thing about the software industry only. I've worked for actual engineering companies (meaning: we build things in factories), where having your factory or expensive integration lab be idle for 2/3 of the day plus weekends is not justifiable. People were scheduled in shifts, and they worked those shifts. And although there was a concentration of people working regular day shift hours, there was always a f…

Is that really weird? In a factory, time is produced things is money. 3x shifts is 3x things is probably close to 3x, at worst 2x money. In software development we've long learned that with 3x as many developers you're lucky if you can keep the same pace on the project, let alone improve. (It could be 2-3x as many projects, but then you have 2-3x as many operational problems again.)

And then you have companies like HP that outsourced to India, East Asia, and Eastern Europe and then found that they could have 24-hour employment shifts through timezones. Shared integration and testing infrastructure got reused between teams working on different aspects of the same problem. Support requests got handled by whatever team was online when the request came in, and written up and handed off to the next if the clock struck 5pm.