I think there's still an attitude among developers that anything that looks like system administration is beneath them.

My theory, which might annoy some people, is that it probably has to do with operating systems collecting so much legacy cruft that a lot of coding to interact with the underlying system is just extremely gross. Like, shell scripts and command line apps have not gotten that much more elegant since the 1980s, but programming languages definitely have. The funny thing is that things like Kubernetes and containers and a lot of these devops technologies are actually really interesting and exciting, but at the end of the day the lingua franca is still bash. And if you're writing code in modern python or typescript or whatnot and all the sudden you have to regularly use a language that lacks robust support for things like arrays you're not going to be a happy camper.

> I expected devops conference to have devs ONLY.

In the past five years I've been doing this, I can emphatically say that the number of software engineers/developer types that I've met at DevOps events are so few that I can more or less count them with both of my hands.

In many ways, I consider DevOps an evolution of what systems administrators do. These days, there's so much demand on infrastructure teams to do more with less. Automation systems have massively improved our productivity that the business types are happy to do so much more that it leads to a vicious cycle of compression and stress.

Don't get me wrong, I love automation and such. But it's terrifying that we're asked to put together systems that we can't comprehend.

I'd consider myself an oddball in the "DevOps scene". I was a bona-fide polyglot software engineer before I pivoted. I did embedded systems in C and C++, full stack Java work, Nodejs stuff, etc. I later did QA automation work in Python, and pivoted from that into DevOps. It wasn't that far of a jump.

But most people I know in the "DevOps scene" are nothing like that. They don't have years of experience in OSS allowing them to see the real gold in the pile of fool's gold. They don't have professional experience doing software development. Many of them only barely understand software architectures. Life cycles? Beyond systems maintenance, there's not much for them to learn about.

I would argue that proper DevOps teams wouldn't have things like on-call rotations that give periodic or constant on-job demands, as that's usually an SRE-type responsibility. But DevOps is just a fancy way to reduce your Ops teams for most places.

I also moved from development to ops and am now at a company with a large engineering organization.

Most developers don't care about ops. They expect everything to "just work" and they don't expect to have to help that process along with the way their code is written. It doesn't matter how junior or senior they are either.

I'd say more than 50% do things that are extremely irresponsible wrt resource utilization. Especially if it's I/O.

>> But most people I know in the "DevOps scene" are nothing like that.

This feels almost universally like the case (unless you "started out" in devops, I guess). It's a catch-all for everything infra. A "good devops" (IMO) will know the ins/outs of all components of the product/business and (more importantly) how it runs and reacts in the real world (and not in the ivory tower/developers' laptop).

There are really 2 types of companies when it comes to DevOps: those companies that and gender a culture of DevOps with their Dev and Ops teams, and those companies which hire a dedicated DevOps team. In my experience people who go to these conferences are almost always from companies of the latter type. It is often argued that the only true DevOps way is that of the former type, but in my experience the company's that talk about DevOps are more often of the 2nd type as that setup in a company is much more common.

It is like REST API's. Most folks that write REST API's are really writing HTTP RPC API's, only a few are doing true REST, but nobody cares; it does the job.

On point, I will just add one thing, the split is not really binary. There is a continuum depending on leadership and teams.

Most companies start as latter either because of historical reasons. i.e they already had a dedicated systems/ops team or because a significant majority of engineers are not interested in doing cross functional/vertical product engineering.

I have experienced two such efforts. One where the transition had varying degrees of buy in from whole eng org and happened slowly but successfully, another org where developers kept (indirectly) refusing to own up their systems past build phase and engaged in unproductive turf wars.

As a development engineer nothing is sadder than seeing a fellow dev engineer not giving a damn about either larger picture (why our product exists/why our users's lives are going to be better because of the product) or about how's the system behaving outside of their little bubble of local machine and jenkins.

PS: I do acknowledge that different people have different motivations depending on what's going on in their personal live.

Devs just don’t care about infrastructure in my experience.