I feel a bit of a rant coming on. This is about software developer mindsets, but it's also about "processes", which can be a bit of a scary term to many developers.
I got quite lucky in my career, in two particular ways.
First, in my first job I struck up a pretty good relationship with our CTO. He and I had quite a few conversations about the why and wherefore of what we were doing, from a business rather than a development perspective. That has left me with an interest in the big picture.
Second, I got sucked pretty much from the get-go into ops. We called it system administration then.
For $reasons, I used to be one of the few developers who got root access to production machines in a bunch of companies.
This has helped me get a fairly good understanding of what operations require from developers. It's quite different from what developers require from each other.
In some ways, it's the exact opposite.
The way these two things fit together is through the nebulous concept of "processes", which most people seem to immediately associate with some ISO standard and certifications, which is followed by endless amount of documentation, which must lead to the conclusion that processes must stand in the way of developers doing what they should be doing, which is programming.
I used to be like that.
So what does operations require from developers?
Developers often think of that in terms of "make things easy for ops", such as giving them a single binary to run instead of having them wade through configuration files. And to a degree, that's a fair enough goal to have for devs.
But the truth is, that ops tend to have some coding ability, and there are a ton of configuration management tools out there and in active use.
Complex setups that can be scripted aren't all that complex.
To support this server and the OMN project https://opencollective.com/open-media-network