"devops" really terrifies me. I think the idea is that you have less friction if you have an operations person that also understands development, or vice versa. But! You're still asking one person to do two jobs. And they really are two very distinct jobs. Are they being paid double? To me, it just seems like cheaping out on having a proper operations person, which really is a full time job. It's understandable if you're a cash strapped startup.. but lets not pretend it isn't what it is.
Admittedly, I develop desktop software, so my experience with 'devops' has been in managing build infrastructure, but I found that the tools and overall philosophy of the movement has empowered my team to control our own infrastructure and actually get things done.
Security was also improved when I started documenting how our VMs were created (and automated it via packer). In the process, I switched them from unlicensed, never-been-updated RHEL boxes to CentOS.
It's unfortunate but predictable that a movement that started off as an attempt to find a way out of the swamp has been coopted into the service of the standard ideology of extracting as much work from labor as possible.
Fixing the issues with both development and operations that result in bad, insecure software and poor user experience all the way around is a worthwhile goal.
Putting the team focus on delivering complete software systems that support traceability, manageability and testability is the whole point of "devops" if the term means anything at all.
It's not about running Ruby scripts as root, or containerising every last script in your environment. It's about building better systems in a manner that's more humane to all concerned.
Except now recruiters and hiring managers don not see it this way, they see it as Devlopers can do Operations tasks. Which is what I was saying, and what the parent was mentioning.
DevOps by itself is a noble cause, putting developers with operations in order to smooth a pipeline, but invariably it just means 1 person with both skills/disciplines.
And like they say, a jack of all trades is a master of none.
It starts with very smart people taking a look at the processes and outcomes they are using and deciding they are broken.
They come up with some solutions and some tools to support their new processes and start sharing them with their peers.
The new techniques have some notable successes and several members of the original group find themselves drawn into teaching/evangelizing the new methods. To make communication easier catchphrases and buzzwords intended to be a shorthand for a suite of methods become popular.
Buzzword compliance becomes a checkbox feature for groups, companies and individuals each of whom have varying levels of skill and understanding and the buzzwords become diluted and more closely associated with specific tooling.
At this point the original group is crowded out by people who are serial evangelists, and enterprise sales become more important than sharing knowledge with peers. Job descriptions start to lose contact with reality.
The movement becomes mainstream as a grotesque caricature of itself driven mostly by the greed-fueled hype train.
At which point someone looks around and declares that the processes are broken... and the whole cycle repeats.
See: object-orientation, agile, scrum, devops, etc.
