3 ms·
The dystopianism comes in because the vast majority of teams are decidedly _not_ 27/4 critical. Sure, some teams really run the 1-Click Buy button or the S3 API
by nighthawk454 6y ago
The dystopianism comes in because the vast majority of teams are decidedly _not_ 27/4 critical. Sure, some teams really run the 1-Click Buy button or the S3 API. Most run some DB behind some API behind another 3 APIs behind 5 other teams that run a widget.
In practice, your workload may not be reduced during on call because it's "expected" and you still have to meet your normal deliverables while the team isn't staffed with "extra" people. It also takes a toll on employees to be mentally-available at all times in case some triviality emerges and raises an alarm. You'll find many engineers not willing to leave a small area or even go out for dinner without bringing their laptop and a hotspot, just in case.
- dudul 6y agoYour "in practice" doesn't match my on call experience over the past 15 years. During "on call" workload is reduced (the author of the post even mentions it). There are ways to implement sane on call policies that benefit everyone. A few I've seen: - use a primary and secondary on call so that the primary can still go get groceries, or play in the yard with their kids, etc - overlap on call and work hours. I did that at a job and I was fine with working 6pm - 2am just to cover this time slot. Won't work for everyone, but may be a nice compromise for some. Like everything else, there are ways to do it right, and way to go complete bananas with it.
- nighthawk454 6y ago> Like everything else, there are ways to do it right, and way to go complete bananas with it. Sure, agreed. Sometimes it's implemented well and sometimes it isn't. I've experienced some of both. When it isn't well-implemented and is particularly non-critical, it can feel a bit dystopian to the engineers. If done well and for a good cause, it should be fine.