Back to the OP, I raise a glass to your sabbatical. Most SREs end up needing a healing period from repetitive stress injury (AKA burnout).
If I may offer some completely unsolicited advice, don't put too much pressure on yourself in the next few months. People who gravitate towards SRE work tend to thrive under short-term ambiguity and emergency/urgency. However, long/medium term ambiguity without a clear productive goal can quickly feel like a crisis. OP mentions this in closing, so I'm rooting for them to rest and "sit still" for a bit.
I think in general that type of experience would help Developers be more empathetic to the operations side of things. Those fires often come from trade-offs made in development.
I think it made me a better developer because I've seen a lot of what can go wrong. Probably reduces my productivity but ultimate my stuff is more likely to work.
Yeah, that's the essential mechanic of it. When "stuff is more likely to work" then everyone can build upon it.
Though at some point(s) that stable foundation needs updating too, so new stuff can be built upon it. That's where the choosing the right balance for the right pieces needs figuring out.
I miss working in software that also utilizes my skills in infrastructure, but I do not miss the constant escalations, terrible on-call schedules, and only about 20% of my time being spent on the rewarding parts of the job.
The root cause of this disaster is that, when writing software, interruptions are the death of productivity. Having a software engineer wear too many different hats at one time, especially when some of those hats are largely real-time interrupt driven, can absolutely kill productivity.
To emphasize, I'm not at all in favor of "throwing things over the wall". Software engineers are responsible, for example, for making software that is easy to test and has good observability in place for when production problems show up. But just because you listed a bunch of things that are "critical for software development" doesn't mean that one person or role should be responsible for all of these things.
At the very least, e.g. for smaller teams I recommend that there is a rotating role so devs working on feature development aren't constantly interrupted by production issues, and instead each dev just gets a week-long stint where all they're expected to do is work on support issues and production tooling improvements.
However, I argue that if the engineers are interrupted by QA issues, they will be motivated to find ways to not have those QA issues. In absence of that, we end up with the familiar “feature complete, let QA find bugs” situation.
There are institutional limitations that engineers cannot overcome, no matter how zealous or motivated. Moreover, companies also ought to remember that one of the engineers can "find ways to not have those QA issues" is seeking employment elsewhere!
I cannot disagree more: our team is healthy, oncall is quite a fine activity to do (and compensated, of course), we have plenty of engineering work to do.
I've had five promotions (and tripled salary) and done so working on plenty rewarding activities over time. I've done from deployment automation, to capacity planning, distributed system design, large data migrations, designing ietf standards for auth protocols, wrote client sdks, now we even do AI for different things (including model development).
I'd recommend to not generalize from "I didn't like it / the experience wasn't a match for me" to "the role is shitty".
> oncall is quite a fine activity to do (and compensated, of course),
Overnight on call is never compensated. I know some tech companies pay but I've never seen it.
> deployment automation, to capacity planning, distributed system design, large data migrations, designing ietf standards for auth protocols, wrote client sdks, now we even do AI for different things (including model development).
To me that is mostly SWE work (capacity planning and migrations perhaps is SRE). in regulated environments SREs are explicitly forbidden from making changes to the code base.
> I'd recommend to not generalize from "I didn't like it / the experience wasn't a match for me" to "the role is shitty".
Agreed.
It was a real mistake, SRE is hugely stressful and really unrewarding compared to SWE. Yes you learn some skills and get some occasional glory, but year after year of fighting fires really didn't build any long lasting career.
After switching back to SWE I've finally got promotions and pay rises again, as well as good night sleep and much less stress.