[alexjplant]

> explosion of DevOps bullshit

The fact that somebody can "be DevOps" or work as a "DevOps Engineer" is exemplary of the fact that DevOps as conceived and DevOps as practiced are two very different things. The former would be engineers taking ownership of deployment, collaborating horizontally, and practicing tight feedback loops. DevOps as practiced is the time-honored tradition of a dev team and a cloud team playing tennis with a grenade that is a questionably-stable SaaS that people volley back and forth with rackets like "let's roll the pods" or "it worked on my machine".

> people with no understanding of Linux got jobs

This happens in every industry with every job title. I've worked with Senior+ developers that mutated React props, didn't know how to use Git, couldn't read Java stack traces, etc. I myself have been paid money to do a myriad of things that I have no business doing (like singing or playing guitar or mixing cocktails). It's the way of the world.

[sgarland]

The platonic ideal of DevOps is fine, yes. The problem I’ve consistently run into is there is a vanishingly small percentage of devs who want to do Ops, or even consider that a server with real constraints is running their code. Performance takes a backseat to DX, which AFAICT is code for “I don’t want to do anything but write code and push.”

I should note that I think this is fine, if and only if you have specialist teams who respect each others’ abilities and recommendations. A dev team shouldn’t have to worry about standing up infrastructure, but similarly, when the infra team tells them that their app is consuming far more compute than it should be, the dev team should profile and improve their code instead of asking for more compute.

[alexjplant]

> there is a vanishingly small percentage of devs who want to do Ops, or even consider that a server with real constraints is running their code. Performance takes a backseat to DX, which AFAICT is code for “I don’t want to do anything but write code and push.”

This is because many tech orgs judge performance by "business impact" and dev and infra teams have different value propositions.

A dev writing and shipping features conspicuously demonstrates value because they write things that users pay for. Product features are novel and specific to a business; a developer can write "Built an automatic cardinal grammeter synchronizer that generates $100M in ARR" on their resume. There is essentially no upper bound on the dollar value of their impact.

Infra teams, on the other hand, have no direct way of quantifying their work. Even though their job is very necessary it's difficult to move the needle as far as cashflow is concerned. People tend to consider infrastructure a commodity so it ends up being one of those things that's only noticed if it breaks. A good day on an ops team means no trouble, not more money. The cherry on top of the sundae is that more users is more money which means more prestige for developers whereas more users means more load which means more problems for the infra and ops teams to contend with.

This incentive structure is why many devs would rather spend all of their time slinging code than worrying about k8s cluster nodes or IAM roles.

As a jack-of-all-trades I don't think this a healthy dynamic. I've led infra teams and dev teams both and know what it looks like on each side of the fence - a little consideration goes a long way and it's one of many reasons why I think that it's healthy for everybody to do a bit of everything in a tech org. People are much less likely to "play defense" if they understand a team's motivations and don't anticipate a negative interaction.