Hacker News Reader

Comment by rednafi | Hacker News Reader

Most of the DevOps folks I’ve encountered, unfortunately, couldn’t code much. So it was mostly ops work with a fancy new title.

The idea of a single entity being responsible for development, operations, observability, and support is flawed from the start. That’s not a one-person job, and the expectation simply doesn’t scale. So DevOps often ends up being either ops folks or dev folks, and rarely a true blend of the two.

What we need are feature-focused developers, ops-savvy devs who can deploy their own work, and a strong team dedicated to observability and applying modern SRE practices.

So I think curious developers who aren’t afraid of infra, along with a solid platform engineering team, are a real improvement over the status quo.

View on HN

> Most of the DevOps folks I’ve encountered, unfortunately, couldn’t code much. So it was mostly ops work with a fancy new title.

The expectations were (and are) irrealistic.

Looking for somebody that has both the software engineering skills of a software engineer and the skills of a sysadmin, willing to do two jobs for the salary of one: yeah sure, keep looking for it.

That being said, i'm one of those that jumped on the bandwagon because in practice it meant fancier job title, higher pay and getting to use newer (often better) tooling.

Ten years ago being a devops engineer rather than a sysadmin usually meant getting to work with EC2 and cloud stuff rather than administering remote physical servers and fighting with NetApp SANs.

Devops was meant to be really a methodology change, not really a job title.

In my experience whether DevOps works or not really depends on the management. I can setup all the automation you want, but management must back me when I tell you're supposed to use the automations rather than involve me into doing your work.

I can surely take feedback and improve whatever you need to be improved, but you *must* be using the automation.

Otherwise we go back and Development and Operations.

> The idea of a single entity being responsible for development, operations, observability, and support is flawed from the start.

Why? I have seen this done successfully at my work time and again. I've just switched to a company that has this separated out and the chaos is unimaginable. what's even worse is that everything is a finger-pointing exercise. devs can't ship their features because they have to fight (or wait) for DevOps to set up things. SRE is trying to add observability and is swamped with 18 teams having services in different tech stacks. Service health is basically non-existent. If someone tries to set a standardized process, then 'how dare you suggest anything outside of your domain?'. Everyone seems to focus on what they think is right and are rarely convinced by others. Worst, not even a tiny bit taking seniority into consideration. not saying seniors know it all better, but the one or two things they have seen are fully disregarded.

At FAANG at least, each team has full ownership AND responsibility across all dimensions. But the good thing was that the people knew that and if anything went wrong, then business was asking hard questions and service teams (product, ux, engineer, sometimes science) had to explain and potentially pivot their processes. which was easy, because everyone was pulling on one string together.

> That’s not a one-person job Correct, that's why you are working as a team on all these things together.

Reply on news.ycombinator.com