That's why i think devops has some good ideas - you are responsible for the shit you ship. Also developer on calls - if you ship shit that goes down or causes errors, you get woken up in the middle of the night or during your vacation.
I was part of a group that inherited a really buggy service platform, maybe a dozen services, 3 generations of most services still around, no logging, nothing. The previous team had kept some foreign engineers on-call and never taken shifts - and there were daily pages, absurd processes to "fix" things, etc.
In about two weeks of putting engineers on call for their own services, most of the major problems were fixed.
It's easy to write buggy software when you aren't the one who gets called at 2am to fix it. Once you start being responsible for your software, the urge to take shortcuts really evaporates. On the other hand, a team that is not responsible for their output will always cut corners - it's just the way it goes.
there is no model where that becomes unnecessary. If someone who did not create the product is on call, they become the poor sod stuck solving a problem of not their own making.
> half at work on their time off
i mean not constantly. Also if you're on call, you're always paid for doing so regardless of what happens. This talk isn't about compensation, but about the model of work.
There is. You split the team or hire additional engineers in other time zones, such that no one is relied upon to work on their time off. There should always be someone working at all times around the globe, available to support.
