I agree it should be part of the compensation package, but not every place is that progressive (yet?). OP might bring that up, or negotiate some form of compensation (ex: day off after on call, whatever). But I tend to agree with parent -- having an on-call schedule that developers participate in is a normal part of professional software engineering (assuming services of course).
this is so alien to me. are you and GP talking about putting in long days during crunch time, or actual on-call rotations where you're expected to be available in the middle of the night? i agree the former is universally expected, but the latter? not at all, not without discussing it beforehand. that would be obscene. i am so boggled to hear people accepting and defending the practice.
I kind of locked in on my recent experiences when answering that. So I want to clarify -- its not expected in all orgs and is dependent on roles (e.g. if you aren't working on live services, it wouldn't even make sense). I would expect larger shops to have dedicated ops people or site reliability engineers who handle most of the duties. But I think small to medium sized corps that either don't have or cannot afford these would expect developers to handle crashing services, whenever they occur. Having an on-call schedule is a natural next step to prevent everyone from always being on call, or (worse, imo) prevent people from siloing and only fixing "their" stuff. I agree it should ideally be part of the job description, but don't find it unusual to be left out if the job otherwise fits the mold.
