In my opinion, more than half the problem is the tooling, as indicated by the cartoon in the linked article. DevOps pipeline languages are generally either wea

In my opinion, more than half the problem is the tooling, as indicated by the cartoon in the linked article. DevOps pipeline languages are generally either weakly typed or stringly-typed. They generally expect users to do the control character escaping, in several different obscure formats. Did I say escaping? I meant three layers of nested escaping! Variable/macro substitution as a rule uses syntax that overlaps with either PowerShell, Bash, or both because otherwise it would be too easy. Another basic thing is the absence of a debugger — I have to run a complete pipeline with a change to dump out environment variables! Instructions contain the display names of paths, scripts use the variable names, but the output (and errors!) use the values with no clear mapping backwards. What the eff is C:\s\1\x? I dunno, but it caused an error! The worst sin is not having a local development experience where the entire pipeline can be run without having to commit code and push stuff almost all the way to production. Even if the pipeline agent is made available, it’s useless without the underlying VM image which is huge and not easily obtained. Not to mention KMS/KeyVault and other similar services on which pipelines can depend. Developers complain about having to do DevOps, but in my opinion the problem isn’t who is doing it, but how. The tooling is just so bad, so very very bad, that anyone would hate it if they were the ones forced to do it. I’m an ex-dev-now-SRE and I hate it.