Yea, this is at the heart of what I also thought were the very point of it.

In my experience on the mentioned project, I felt one of the few ways to get there, unless you wrote the whole codebase, is to have enough time to build (or configure existing) some tools to be able to visually understand and/or navigate the system.

During one week of being on-call engineer, inspired by the ideas of pro-activity and monitoring in SRE, I stole myself some hours to put together a script that would parse our ArgoCD configs to create a map of our Kafka topics, into a GraphViz-based HTML file with links to to the relevant topics as well as microservices (pointing to some web based inspection tools for these).

This finally made me be able to figure out what was going on and be useful during incidents as a newcomer in the field, but no one in the team had thought of this idea of being a little pro-active, so most of the time when errors occurred, people would just scramble around all over the place, and only the really senior guys would be useful because of having the whole system in their head anyway.

To me, this idea of pro-activity is what SRE brings to the table.

Doesn't that mean it's essentially a senior developer in the dev team?

It does, but a senior developer in a pager rotation.

It makes sense. But I do feel seniors will be pigeon holed into taking an Ops responsibility.

Depends on the org. In an org where devs are protected, DevOps/infra team will do the pager duty suffering in an SRE capacity. In other orgs, seniors will be forced into it unless they have leverage to bounce otherwise, or they tolerate it because there are worse jobs out there. Culture and appetite on both sides is highly variable, won’t know until you’re on the inside.

It definitely can be, but depending on the application, it might make sense to demarcate 'scale/infra' related senior developer responsibilities from 'business logic' type responsibilities. An SRE would care about the former, much less the latter.

I'm a SWE SRE, and I don't particularly care to look at the code of individual features being added unless there's potential for a large blast radius, but I do care to make sure if something breaks, there isn't cascading failures. I want things to degrade in a predictable way, or to fail in an isolated fashion. The non SRE SWEs are free to break a single feature, and i'm happy to help them roll it back, but that's not what I'm primarily worried about.

Conversely, many of them aren't all that interested in thinking about how slowdowns or failures propagate upstream or downstream to other teams that may or may not understand how things are connected, whereas I do worry about that.