[skipkey]

Depends on the size of the team. Startup or small team? Yes. Everyone is on call all the time. Large number of developers? Someone on every team is on call all the time, and leads need to be almost always available for large outages.

On call pretty much just comes with the job, and always has.

[vunderba]

I suppose for the vast majority of software engineers working on online / SaaS type products or ones that silo a lot of customer data, this is true.

Always has is a bold assertion. I've worked for companies which produced consumer level software on an annual cycle that was pressed to physical CDs, and there was not even a concept of on-call. Bugs that got reported went from customer support, to QC to corroborate, and finally triaged out to the R&D department where they would be fixed within normal work hours.

This idea of 100% 24/7 on-call to fight fires in an industry where the vast majority of engineers are working for insurance companies, social media, e-commerce, etc. This ain't life and death people, let's get some perspective.

[zvr]

> produced consumer level software on an annual cycle

This can also be generalized "produced software on a release schedule".

I would assume that the vast majority of software engineers are not working on supporting the operation of online/SaaS services, but rather develop products.

[lotsoweiners]

> On call pretty much just comes with the job, and always has.

Maybe for you but not for everyone and I bet outside Silicon Valley startup land and certain industries it is probably less common than you think. I work in government which is basically 8-5 local business hours. Production issues can take days, weeks, months to fix and deploy depending on priorities. Most of my dev friends have never had on call roles either. Plenty of companies have enough staff to have around the clock coverage. Just trying to add an additional perspective.

[drewcoo]

> On call pretty much just comes with the job, and always has.

If you don't remember the invention of "devops" that's especially true . . .

[mangamadaiyan]

Those who do not know history are doomed to repeat it, or words suchlike (from Santayana, I guess?).

I don't know if I'll ever see things like devops and agile die the horrible deaths that they deserve - but I do wish engineers would at least learn to think for themselves and not drink so freely of the kool-aid that CEOs peddle.

[ok_dad]

Sad part is that devops was never meant to be a title, just a way to work together effectively as a team that included developers, qa, ops, pm, etc. Devops was much like agile, they were great ideas and ways to work, but then got cargo culted to death and today managers have taken them as buzzwords and thrown away all the stuff you actually needed to do to get good results.

Management always takes good ideas and extracts the absolute worst stuff from them, if they don’t just make up shit on the fly that wasn’t even a part of the original good ideas.

[mangamadaiyan]

Yes indeed. Management almost always bastardizes good ideas and makes them terrible; and then they take it a notch further by finding and nurturing kool-aid connoisseurs in the levels below.

(Edit: grammar)