Yes, it is. Mostly because "real engineering" isn't the high bar it's made out to be. From that blog:

Nobody I read in these arguments, not one single person, ever worked as a “real” engineer. At best they had some classical training in the classroom, but we all know that looks nothing like reality. Nobody in this debate had anything more than stereotypes to work with. The difference between the engineering in our heads and in reality has been noticed by others before, most visibly by Glenn Vanderburg. He read books on engineering to figure out the difference. But I wanted to go further.

Software has developed in an area where the cost of failure is relatively low. We might make million dollar mistakes, but it's not likely anybody dies from it. In areas where somebody could die from bad software, techniques like formal verification come into play. Those tend to make everything take 10 times longer, and there's no compelling reason for the industry at large to do that.

If anything, we should lean into this as an advantage. How fast can we make the cycle of change to deployment?

In many cases this is accurate. Programming alone doesn't amount to engineering. Lotta low quality lines of code being churned out these days because standards have dropped.

By how some teams operate, and some developers think, there is certainly cases where the "engineering" aspect is hard to find.