[Dioxide2119]

Ops is not peripheral to the job, ops is an essential part of the job.

The job is always to make that computer box there do X when I the paying customer click Y button. On the inside there is some algorithm design and logic that tells the computer how to do the job, and also there is some stage setting and lighting and camera setup to cue the computer on what, when, where, and why do the job (and write down who told it to do it).

In terms of classic 'developer writes features then leaves it to ops to actually make the code be useful to customers' (AKA specialization inside the software realm), the division of front-line soldiers vs logistics comes to mind here.

If you don't have a front line, the enemy takes the land and you lose. If you don't have logistics, you lose the front line to starvation / lack of ammo, and then you lose the front line, then you lose the war.

So if you are in strict operations, you may be the logistics side of that, and the front-liners may look down on you for not doing 'the thing', but if you weren't there to do your job, then they get to starve, run out of ammo, or do your job as well (aka becoming more generalist / end to end ownership / full stack SRE) as their previous job.

Reader: Ok smart guy, what's your solution?

I advocate to stop splitting the job of dev and ops into separate roles and doing the devops practices for everybody. We lose theorized competitive advantage but gain flexibility and more well-rounded skill sets so we really can call ourselves software engineers.

If you can code algorithms but not properly manage the lifecycle of your code after entering it into the source code file (testing, deployment, runtime, data migration, upgrades, decomissioning), you only have half the toolkit.

If you can do one or more of the other pieces but not do reasonable data structure and algorithm design relevant to the problem space, you only have half the toolkit.

We don't have residential plumbers arbitrarily split between vertical pipes and horizontal pipes...all the pipes are needed, so the plumber learns to handle both. Why did we let the 'expensive computer operators + cheap clerical roles' of the punch card era split up our profession today into 'devs' vs 'ops'?

[jdoss]

> Ops is not peripheral to the job, ops is an essential part of the job.

I am 100% with you on this point. Ops is treated as a cost center vs a core feature. This means it is often a chore to maintain and the first thing to get scrutinized when it comes to budget.

> I advocate to stop splitting the job of dev and ops into separate roles and doing the devops practices for everybody. We lose theorized competitive advantage but gain flexibility and more well-rounded skill sets so we really can call ourselves software engineers.

You lost me here however. Software engineers often do not want to think about the Ops problem their code will create over time. Either they do not have the skills to know what they don't know or they are being pushed by the business to work on "business value" over sharpening the Ops axe so their current code runs well for the best possible price.

Growing those skills are either not a priority for them personally (not a dig at all, I think it is totally fine for people to have personal limits on what they want to learn) or a priority for the business so they can't learn how to do things better. This is why you are seeing a boom of making PaaS the thing that is used to deploy software which is super expensive for what it is, limited in features, and limited in choice when you want to move to a new provider.

I am all for making Ops easier for everyone to consume, but in the end, if you don't understand the fundamentals of the underlying plumbing you are going to have sub-optimal results. To use your residential plumber analogy, of course you can fix your plumbing yourself, but having an expert plumber do the job not only saves time but often money in the long run. That's why you hire them. Expecting every home owner to have the time to grow the skills to be a functional plumber is unreasonable. Why do we as an Industry allow the C suite to expect developers to be functional operators? They took the "DevOps" movement and used it to shove all the responsibility onto developers to cut FTE count on the SysAdmin/Systems Eng side of the house.

The tech industry has devalued Systems Administration and Systems Engineering in a race to bottom in order to cut costs in the short term and that's why we pay out the nose for Cloud Services that are used by non experts to create over engineered setups.

[Kinrany]

> Software engineers often do not want to think about the Ops problem their code will create over time

That's an easy problem: pay them less and make it clear that this is why

[candiddevmike]

The stacks have become too complex to naively avoid specialization. And if you do try and avoid it, you'll end up with a spaghetti of managed services, PaaS/SaaS, and consultants, each owning an incohesive piece of your infrastructure.

[johngalt]

> stop splitting the job of dev and ops into separate roles

Specialization is the key to managing complex projects effectively. Effective teams will increase specialization where possible, and improve the feedback mechanisms between specialists.

Take a look at other complex industries like aircraft. We do not have simple "Airplane Professionals" who design/build/maintain/fly planes. But rather each of those categories are divided into subcategories with specialists.

[magicalhippo]

While I agree that specialization is good, I also think it's really good to care and know some minimum about the adjecant teams.

I'm not a super ops guy nor do I do support (unless it's really bad), but I care about those teams and I try to learn the basics so I have an idea how my the code I write will affect them.

[WJW]

Weird comparison, because builders absolutely do specialize. The whole word "plumber" has to do with someone who only does the piping and none of the other jobs in needed in constructing a building.