3 ms·
I'm a SRE and I disagree too, though, I think you're giving SREs too much credit in the category of our hegemony for an "us vs them" debate. Maybe at Google SWE
by oooyay 2y ago
I'm a SRE and I disagree too, though, I think you're giving SREs too much credit in the category of our hegemony for an "us vs them" debate. Maybe at Google SWEs having relationships with their code based is a well studied thing. It could also just be someone's opinion that managed it's way unchallenged into the book. That's to say, Google SRE wasn't the best or last iteration of SRE.
I personally think systems evolve the way you describe because of a system of incentives. There are more incentives for features than there exist for refactor and non top priority defect fixes. This comes from the people who hold power to shape incentives and they often do so with conflicting priorities and superficial understandings of the existing incentive structure.
I'd also like to say that it's my own personal theory that systemic issues can only be caused by systemic forces. Individual mindsets cannot be to blame then; if a mindset has become systemic (example: SWEs overly attached to code and features) then your next question should be "why?". There's a system that enforces that, and if you don't look beyond personal obsession then you'll never find it.
- burakemir 2y agoI like this way of saying it. I don't think anything here is well studied at all. It is not like we are all fishing in the dark but the organizational structures that determine the conditions in which software development and operations happen are not well understood. I found Herb Simon's writings and his concept of bounded rationality very lucid. When we shift from "reliability" to "safety" we also need to shift from the individual to the system.