The point about "you build it, you run it" not being sustainable really hits home for me. On a large project, there's a fairly natural specialization along many

The point about "you build it, you run it" not being sustainable really hits home for me. On a large project, there's a fairly natural specialization along many axes, with "deep in the guts" development vs. "close to the users" ops as one of the more natural ones. It's definitely important for developers to get some direct experience with operating what they produce. That's why I took my current job instead of letting myself become one of those awful "senior architect" types divorced from reality. Still, being on call is stressful. That stress is even greater when it's into areas others know 10x better, or when it interrupts progress toward the longer-term outcomes on which developers are measured even in a "devops" culture. Changing teams to get a break from being on call starts to seem less disruptive than staying, and I'm sure plenty of other people where I work hit that realization long before me. I think more of a "pair programming" approach would often produce superior results. Two close associates don't need to know every command-line flag and semicolon of each others' work to understand and appreciate each other's contributions to the challenges they share.