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).
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.