To be fair, many of them do seem to operate on the "op sees, op does" level.

Just last week, we had some mails escalating, client had "issues" with their on-prem install of our software, which ran on a dedicated VM.

I read the mail thread and turned out the database service "used a lot of memory", and they'd tried rebooting the server several times but it just kept using a lot of memory. So now they had escalated because they couldn't figure out how to "fix" this issue.

Of course, this was not an issue. The database is designed to use all available memory by default, and this was a dedicated VM so it didn't affect other services.

I've seen many such and other instances over the years. While there are certainly awesome ops people out there, which is always a pleasure to interact with, a significant amount are at a much more basic level.

As a developer, I've had to tell "ops" how syslog() works. Also, as a developer, I've had "ops" bitch because we had different config files for the service. Yes, because the service is geographically redundant, and each site had different IP address! And I, the developer, have maintained, and continue to maintain, the configuration file! Checked into your ops repo. You (ops) have never had to maintain it at all!

I've also been on the other side of the wall, as ops, having to tell the developers why the keep seeing zombie processes on the server. Because the developers had no experience with Unix signals and having to wait on child processes. And again, about how syslog() works.

It goes both ways.