I completely agree and went by the proverb "everything worth doing is worth doing poorly" about a year ago now, it took some time for it to sink in but now I'm actually productive. My main blocker was waiting for other's approval, now I feel a lot more free.
Most devs can't do SRE, in fact the best devs I've met know they can't do SRE (and vice versa). If I may get a bit philosophical, SRE must be conservative by nature and I feel that devs are often innovative by nature. Another argument is that they simply focus on different problems. One sets up an IDE and clicks play, has some ephemeral devcontainer environment that "just works", and the hard part is to craft the software. The other has the software ready and sometimes very few instructions on how to run it, + your typical production issues, security, scaling, etc. The brain of each gets wired differently over time to solve those very different issues effectively.
I don’t understand this take - if all engineers go on call, they learn real quick what happens when their coworkers are too innovative. It is a good feedback loop that teaches them not to make unreliable software.
SREs are great when the problem is “the network is down” or “kubernetes won’t run my pods”, but expecting a random engineer to know all the failure modes of software they didn’t build and don’t have context on never seems to work out well.
It's possible to do both, you just need to be cognizant of what you're doing in both positions.
A tricky part becomes when you don't have both roles for something, like SRE-developed tools that are maintained by the ones writing them, and you need to strike the balance yourselves until/unless you wind up with that split. If you're not aware of both hats and juggling wearing them intentionally, in that case, you can wind up with tools out of SRE that are worse than any SWE-only tool might ever be, because the SREs sometimes think they won't make the same mistakes, but all the same feature-focused things apply for SRE-written tools too...
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.
I've said it before too, it is exemplary in terms of what documentation should be ; just read through it with a VM on, type the things, and everything just works, no googling or LLMing around. I heard it is the same for other BSDs as well, will try those some day. Also a testimony of how coherent this system is.
As a seasonned SRE it is a breathe of fresh air in this world where everything else seems to change from one version to another and nothing seems to work at first try, ever.
There are a bunch of those for free no ? Rails blocks (paid, about the same price as this Rails UI), Ruby UI (MIT licensed), I think I saw a couple more here.
Yep LXQt is a beast, super snappy and complete. I use it on an old laptop (2012) and it still works great with a very low memory footprint (much lower than XFCE when I tested a bunch of them).
I just watched for 5 min and no they don't play very well. Deepseek squeezed with K4o against CO open and BTN call with full stacks. Grok 3b AI with 25bb in the button with Q4s. Those are very far from optimal play which is well known since solvers. I wonder how they've been trained.
Considering a squeeze puts deepseek ahead of most human players. Maybe not an optimal squeeze, but most human players flat if they're going to play.
Grok's play is obviously bad, no solver needed. I wonder what he said in the "log" where you can see their thoughts. I guess he can hopelessly be trying to rep AA--again, I've seen worse thought processes every time I've ever played in a casino.
I really think GPT, at least, would win at a live casino. Possibly the other bots as well. The humans are that bad. Poker is complex.
I remember airport hostesses when they used it to get your boarding pass from the mainframe, it took them 5 seconds and a few key-strokes like 3 letter of my name to get the job done. When they switched to web-uis some year, I vividly remember seeing them, 4 at a time on the same screen, trying to figure out what was going on. Took them 15 minutes and a phone call to get the boarding pass ready. I feel sad when I think about this.
reply