This article is really light on concrete examples and any kind of point outside of the title, which is a shame, because I think this is an extremely relevant discussion to most tech-y people's work and day-to-day, so I'll try to elaborate on why I agree and disagree with some of these points that have been repeated 50,000 times over the last ~10-15 years. disclaimer: spent most of my career in what probably would be described as "DevOps" at most places, and have led multiple devops teams.

For my tone, I apologize, but there is just so much wrong in this post that I don't want to go through it all, but here's one example of why I think this person, with all due respect, has very little idea of what they are talking about. It's irritating because it seems to devolve into some weird rant about "locked doors" which are 100% and absolutely necessary in any operation of size and scale:

> Originally, DevOps was about trusting developers with production. But modern DevOps teams operate on the belief that developers can’t be trusted with production.

I don't even know where to begin with this one. Who hurt this guy?

> And because DevOps owns the compliance checklists, they bake that mistrust into the rules.

That isn't remotely how compliance works and suggests a child-like understanding about any of this. At most they are responsible for implementing the checklists, which comes from a security team, compliance team, or some external entity, and even those checklists are not really generated or controlled by these entities, they are following established guidelines already in place that most people need to adhere to. So, red flag number one this person doesn't know what they're really talking about, but I'll digress to my main point because I think the spirit of the post is correct even though most everything in it is silly.

I have the opinion that the industry fundamentally misunderstood what DevOps was supposed to be and do. Of course this is rarely challenged, but where these arguments fall short are what are we supposed to do instead? The author comes close to recommending a solution - have them work closer to the devs and thus the product teams. Boom. Simple. That's it, and in fact, tons of places not stuck in the practices of 20 years ago have done this, and successfully! They're just not typically called "devops." Like, at meta for instance, the closest thing to that (and forgive me if I'm misremembering or this has changed, this is from a round of interviews some years ag) is a role called "systems engineer" and they work on and with the dev teams.

The existence of a team called "DevOps" to me is a massive red flag anymore that a company isn't getting it, but I have still seen this "chuck it over the wall at each other and pray" approach work fine enough. It's also created a job title that can mean practically anything and predicts very little about a person's skill set - you have "senior" devops guys and leads that basically got promoted from a Sys admin or IT support role, which for some reason companies thought was a perfectly natural progression, and then devs who did actual development for a while and now write fully functional platforms and automation for the dev teams they support. These people are not the same, which makes the hiring/interviewing process a nightmare. To make it worse, even tech people can barely understand the difference sometimes. So you'll run the gamut of having teams full of "devops" guys that can barely string together 6 functional lines of code, to full stack guys that could probably work with any of the dev teams they support as a dev.

I don't pretend to know the fix but I've increasingly gone out of my way over the last several years to avoid "devops" titles because it just seems to be a dead giveaway that the team is clueless or at best apathetic about how to do this.