[throwaway892238]

It's probably useful to talk about what Operations Management is first. It's a business discipline that touches on many parts of a business. It is defined as "the management of an organization's productive resources or its production system, which converts inputs into the organization's products and services". You can get a PhD in Operations Management.

In tech, software and data is the "productive resources", and the "production system" is the actual system you build out of those resources: the website, API, etc. You don't have to write any software to build and manage that production system. Maybe that's unusual to people in tech today, but it's a fact that you don't have to write a single line of code to build and operate such a system. Heroku, PagerDuty, DataDog, Splunk, Octopus, AWS, etc, all are products built with the sole purpose of enabling operations without the need to write code. You can assemble logging, alerting, monitoring, web server, networking, database, deployment, etc, without ever writing a single line of code, and have it be highly available and highly reliable.

The title will vary (Systems Engineer, Operations Engineer, DevOps Engineer, Site Reliability Engineer, Systems Administrator) but the job is the same: to use Operations Management techniques to ensure the products and services are productive. You can use software development practices for all of this, sure! But they are absolutely not a requirement to accomplish the goal. And many other roles in the company are involved in Operations (QA, PM, DM, etc) and may or may not use code. The business doesn't care about code, it cares that its resources are being used properly and the production line is operating nominally.

In terms of the distinction between builders and operators: you could say that a construction worker and a custodial worker are part of the same occupation because a lot of their skills overlap. They both need to understand how the building works and may need to build/repair parts of it at times. But they're still two different disciplines that require different training, experience, and day to day responsibilities, and as such we don't lump them into the same category.

[joshuamorton]

THere's at least one big issue here, which is that you're pretending that a website is like a building or a dam. If that were the case, a company like Google would have a (relatively) small team of SWEs who "built" things, and a much larger team of SREs who maintained them over their operational lifecycle once the SWEs were done building the thing. But that isn't the case.

Software systems (at least in competitive consumer markets) are constantly changing and evolving. To use the dam analogy, there's constantly a team of people making the dam taller or wider or deeper, even while the dam is running and producing power.

All the SRE teams I've worked with have done a bunch of things that go beyond "operations". They are usually consulted at the design stage, to make sure that the thing is going to be built reliably. They're also responsible for ensuring ongoing reliability as all new features are added. That means that the features themselves don't impact reliability, and that the process of adding new features doesn't impact reliability. None of this work has a reasonable analogue in your dam analogy, except perhaps as some combination of consultant and regulatory body.

[tom-_-]

"You don't have to write any software to build and manage that production system."

It depends on the scale and complexity of your application. At some scale/complexity, it absolutely requires writing software because your IAAS provider doesn't provide you with automation that covers 100% of your operational needs and even they recommend using infrastructure as code tools to manage your infra.

If your production system is a CRUD service with 3 application nodes and a managed PostgreSQL instance then you do not need to write software to manage it. But if your application is that simple, then I'd suggest you probably don't need a software developer to build it (Wordpress, Wix).

Construction vs custodian is not a fair analogy because their training and evaluation doesn't really overlap. The training and eval for both "dev" vs "systems" engineers is very similar; most have CS degrees and have to do some leet coding to get the job. Devs generally need to be better at algos, systems engineers need better understanding of networking, os, system design.