I have to vehemently disagree with this statement. I had 10 years in IT before I did my bootcamp and quickly found myself in deployment engineer roles by accident. Most of my bootcamp cohort ended up at smaller companies wearing many hats and learning quickly where a good half of them are in deployment type roles by necessity.

After an additional 10 years in this industry, I'm finding invariably that it's the FAANGs and companies hiring fresh grads out of the best schools where engineers aren't learning anything about the underlying systems. It's the feature factories where people put their headphones on, the heads down and code like their life depends on it.

They do things like write microservices that implement basic functionality of opensource loadbalancers, because they've never heard of nginx or haproxy before, don't know how it solves their specific problem and wouldn't know how to configure it. When all you do is write code, every problem looks like it should be solved by writing code.

Before the overlap between development and operations there were multiple teams involved in every step, everything was slow and expensive and you'd be lucky to deploy once a week. After making sure that where overlap exists the people that have the skills to work in that area can do what they need to do (i.e. build, verify, release and instrument the systems they are responsible for) we get every team releasing every system multiple times per day in small increments. This is both faster, easier for everyone, and worth the ROI on people and tech far more than trying to invent borders and fiefdoms between hyper-specialised teams.