The problem with the way doc hours are handled is: there's zero back-up. Whether private practice or group or hospital, everyone is utilized at maximum. I had a colleague once get terrible food poisoning - and had to come in anyway. They crawled in. We saw them, stole a bed from the trauma surgeons' on-call room, stuck an IV in him, and told him to sleep.

When he emerged two hours later, clinging to his IV pole, we were grateful for the manpower.

That's not counting all of our "unofficial hours". You officially work, whatever, 9-6. You're packed with patients for those hours, though, with almost no time to chart, so you go home and chart ... and on a daily basis at home, you're catching texts from colleagues for informal consults and requests to see patients the next day. Your "off" hours aren't off - and if you have to take call, and end up driving back to the hospital...

EM "handles it better" (a phrase I'm loathe to use) because they have legit shift work, with no continuity. No one calls them for a consult; they're not responsible for anyone after they leave because all their patients are short-stay, they don't have to see "every patient on X roster," they just have to manage their ER while they're in it. They manage shifts because of features more-or-less specific to their specialty. A handful of other specialties share those features, and manage to do the same. But not most.

Hell, I chose to pursue my specialty specifically because it lacks emergencies. I never wanted to wake up in the middle of the night post-residency; no one pays you enough for those hours (you're generally not paid for those hours.)

Yeah, on the whole I'd say doctor's WLB is a lot worse, especially considering what I've heard about residencies. And I think a developer can find a job with better WLB much easier than a doctor.

I just think that tech, especially startups, don't handle overtime well. A service might not need to have high availability, and if it does there a ways to manage operations well. Leadership focusing on quality, so that production issues are minimized is good. Explicit on-call schedules can provide benefits if it's not a ton of work, being on-call is definitely a negative. But knowing that you don't need to be available at all is better than not having an on-call schedule. Shift work, with the focus on explicitly dividing up the schedule between employees can provide that benefit.

I haven't worked at Google, but the Google SRE book mentions a lot of things I like. Like giving the option for cash compensation for overtime, requiring postmortems for on-call incidents, capping the percentage of ops work, and having multi-site teams to minimize night shifts all sound like great ideas.

I think there are a lot of situations where service reliability could be improved while making things easier on sysadmins and developers.

there's a real open question regarding app downtime. I know being 'on call' is a common occurrence in a number of tech positions, but if the thing really 'needs' to be responsive and up 24 hours VA day 7 days a week and something can explode and take it down, then one should probably look at what other sectors with that kind of need do and have rotating shift/ rosters...

course, that would probably result in lower wages for those shift

(that being said, in my country, doctors working hours in the likes of hospitals are notoriously unsafe/long/unreasonable/unethical as well, so your mileage may vary)