Hacker News Reader

Comment by dionian | Hacker News Reader

But there is bad code and good code and SREs cant tell you which is which, nor fix it.

My take (I'm an SRE) is that SRE should work pre-emptively to provide reproducible prod-like environments so that QA can test DEV code closer to real-life conditions. Most prod platforms I've seen are nowhere near that level of automation, which makes it really hard to detect or even reproduce production issues.

And no, as an SRE I won't read DEV code, but I can help my team test it.

> And no, as an SRE I won't read DEV code, but I can help my team test it.

I mean to each their own. Sometimes if I catch a page and the rabbit hole leads to the devs code, I look under the covers.

And sometimes it's a bug I can identify and fix pretty quickly. Sometimes faster than the dev team because I just saw another dev team make the same mistake a month prior.

You gotta know when to cut your losses and stop searching the rabbit hole though, that's true.

I agree with your nuance, but that's not my default mode, unless I know the language and the domain well I am not going to write an MR. I'm going to read the stack trace to see it it's a conf issue though.

>And no, as an SRE I won't read DEV code, but I can help my team test it.

that doesn't sound like my definition of an SRE. How is what you're doing different than Ops?

Why not? I'm a SWE SRE and I'm arguably better at telling good code from bad code than many of the pure devs I've worked with.

Edit: ^ At the cost of being much worse at being able to tell what features are useful or well implemented.

Reply on news.ycombinator.com