Hacker News new | past | comments | ask | show | jobs | submit login

People are complaining about the idea that the developer is ultimately the owner of any service they wrote.

I don’t see how this is even controversial. Consider the case where a SRE is responsible for 5 or 10 such systems. They could never be expected to know as much about those systems as the people that wrote them.

Now if there is a one to one relationship between SREs and systems then it might make sense to expect that level of understanding from the SRE.

In my experience it would be a great privilege to have a dedicated SRE to your application.




You say that’s not controversial but irl I’ve worked with more than a handful of non-jr engineers and even managers who think developer job ends at seeing green build in ci (btw a ci which some other team is supposed to manage). Sometimes even green build locally


"Owner or not" is a false dichotomy. I get it that the author and many SREs are probably jaded from developers not taking ownership at all.

The right attitude is to figure out processes that let people draw a line when to go to DevOps, and when to escalate to developers. Developers need to understand the costs they impose on devops and organizations need to make sure developers are empowered to fix their own issues, rather than to be constantly chased around to business requirements.

Developers ultimately answer to business priorities, and they don't necessarily own the business processes that demand their support. If developers are given ample resources to keep bugs out of systems, document operational expectstions and respond to incidents, then the developers can "own" the processes better. If not, it's a management problem that is just of the same nature as the usual SRE complaint that developers don't want to own anything at all.


For me SRE/DevOps is just support for developers. It's possible that such person has more knowledge/experience in development and operations, but in general their focus is on infrastructure, automation and general troubleshooting.

They might know how to build/test/deliver/monitor some solution, they might know to some degree how to configure solution (but developers should support them with it and describe it well), how to script some operations, however they definitely won't write bugfix themselves.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: