The part of the paragraph that really bothered me wasn't the hours, actually. It was the implication that you would be expected to code during those hours. Even

The part of the paragraph that really bothered me wasn't the hours, actually. It was the implication that you would be expected to code during those hours. Even when I've been on-call, I've never expected to write code, outside of business hours, during my on-call shifts. Update configuration? Sure. Roll back a broken deployment? Absolutely. But if devs are writing significant amounts of code (beyond 10-line patches, or updates to config files) in order to put out operational fires, that's a big red flag. It means that the codebase hasn't been designed to be easily changed with configuration. It means that deployments are so difficult, it's easier to try to write a patch in the moment than it is to roll back and see what went wrong in the morning. Furthermore, any code that is written under that kind of pressure isn't going to be high quality. It's going to be code that does the minimum necessary, with no documentation or unit tests. It's tech-debt equivalent of a high-interest payday loan.