upvote
> DevOps should be a guiding principle for the organization, not a dedicated role

The way I've always phrased it is that if a company has "DevOps" teams or titles, they're not doing DevOps by definition

reply
Was that not the OPs point too about it being a sad story and many Devs not being capable of learning to run software outside of an IDE?
reply
So jack of all trades master of none?

We’re seeing the same thing with QA. I guess developers can QA their own deliverables.

Leaving out the key fact that the vast majority of developers have no interest in testing stuff. And thus you end up “testing in prod” like with Microsoft projects.

It’s not a coincidence Microsoft’s software quality has collapsed since they’ve eliminated dedicated QA/SDET roles.

reply
> So jack of all trades master of none?

Why does the ability to interact with users, being able to test code, profile/debug code, and actually manage your deployed software imply you're a master of none? Too many developers act like it's a good state of affairs that they just get locked in the basement to grind the code. And now that we have tools that can grind code for you, they're finding out why that wasn't a good state of affairs for them.

The answer is master all of them, not none of them.

reply

    A programmer has to be able to demonstrate that his program has the required properties. If this comes as an afterthought, it is all but certain that he won't be able to meet this obligation: only if he allows this obligation to influence his design, there is hope he can meet it. Pure a posteriori verification denies you that wholesome influence and is therefore putting the cart before the horse, but that is exactly what happens in the software houses where "programming" and "quality assurance" are done by different groups. [Needless to say, those houses deliver without warranty.]
(c) Dijkstra

https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD130...

reply
While I agree with this, in a lot of software there's more to verify than just being correct. Unless there's a separate and rigid UI/UX spec then there's also matter of things being intuitive to use etc. which may vary from person to person and the one making the thing might not have the same sensibilities as the users.
reply