I agree strongly with your second two paragraphs, but I'm going to push back on the oft-repeated meme that software engineering is not real engineering because it doesn't have the same disciplined approach as physical engineering practices.
Personally I think software engineering is absolutely engineering, it just has mostly different constraints from physical engineering. Most of this has to do with the dealing with the costs and consequences of building things in the physical world. Without those disciplines, a huge capital cost goes into building a bridge that fails, or an expensive machine that can't do its job. We also have to account for the limitations of physical materials and a harsh environment, which are in some ways harder to account for, but also more stable as a well-understood substrate than pure software (ie. all animals have some intuition about physical things, physics doesn't change, materials capabilities change slowly, etc).
When folks lament the lack of "discipline" in software engineering I think it's a misplaced, grass-is-greener sentiment that hasn't really been thought through. The reality is software has different constraints, not harder or easier, just completely different apples to oranges differences. For instance, durability and maintenance in physical objects is about material properties and physical wear and degradation from the operating environment, whereas software bits are infinitely durable and replicable, but they get broken by the environment itself since they have to interact with thousands or millions of other software artifacts created over many decades. With physical engineering it's mostly about discrete objects with natural and intuitive encapsulation that are in a sense "immutable". Some software is like this (like pre-internet console video games shipped on cartridges), but typical cloud-based software is nothing like this, it's a constantly evolving tangle of interconnected logic and ever-growing data used for widely heterogenous purposes, often never fully understood by any one person or entity.
This messiness is one of the frustrating things about software, but it's also its strength. Anyone that tries to declare rigid civil-engineering-style discipline to software will not survive in the marketplace because most software is not life-or-death. The discipline put into the Mars Rover or the Therac 25 successor would simply be overkill for average software. That said, of course there are cases where the importance and impact of software correctness is unknown, like if the government were to start using social media sentiment to impose real-world consequences on its citizens, but these types of considerations are much more fluid and harder to nail down than physical properties like "will this bridge stand up for 50 years". Software engineering in my view, is about leveraging the malleability of software to solve problems in a constantly evolving landscape. We're not just standing on the shoulders of giants, we are directly calling their APIs to solve new problems they couldn't even have conceived of. One could argue this is too broad to really be "engineering", but I can't think of a better word to describe the highly technical process of understanding and solving problems with software.
Could it be that not all software development is equal? Some of it leans more towards engineering and the academic (e.g. compilers, operating systems, tpc/ip stacks, etc) vs software that leans more towards the creative (e.g. web and mobile apps, games, api's, etc). I.e. to me software development seems more of a spectrum.
Personally I think software engineering is absolutely engineering, it just has mostly different constraints from physical engineering. Most of this has to do with the dealing with the costs and consequences of building things in the physical world. Without those disciplines, a huge capital cost goes into building a bridge that fails, or an expensive machine that can't do its job. We also have to account for the limitations of physical materials and a harsh environment, which are in some ways harder to account for, but also more stable as a well-understood substrate than pure software (ie. all animals have some intuition about physical things, physics doesn't change, materials capabilities change slowly, etc).
When folks lament the lack of "discipline" in software engineering I think it's a misplaced, grass-is-greener sentiment that hasn't really been thought through. The reality is software has different constraints, not harder or easier, just completely different apples to oranges differences. For instance, durability and maintenance in physical objects is about material properties and physical wear and degradation from the operating environment, whereas software bits are infinitely durable and replicable, but they get broken by the environment itself since they have to interact with thousands or millions of other software artifacts created over many decades. With physical engineering it's mostly about discrete objects with natural and intuitive encapsulation that are in a sense "immutable". Some software is like this (like pre-internet console video games shipped on cartridges), but typical cloud-based software is nothing like this, it's a constantly evolving tangle of interconnected logic and ever-growing data used for widely heterogenous purposes, often never fully understood by any one person or entity.
This messiness is one of the frustrating things about software, but it's also its strength. Anyone that tries to declare rigid civil-engineering-style discipline to software will not survive in the marketplace because most software is not life-or-death. The discipline put into the Mars Rover or the Therac 25 successor would simply be overkill for average software. That said, of course there are cases where the importance and impact of software correctness is unknown, like if the government were to start using social media sentiment to impose real-world consequences on its citizens, but these types of considerations are much more fluid and harder to nail down than physical properties like "will this bridge stand up for 50 years". Software engineering in my view, is about leveraging the malleability of software to solve problems in a constantly evolving landscape. We're not just standing on the shoulders of giants, we are directly calling their APIs to solve new problems they couldn't even have conceived of. One could argue this is too broad to really be "engineering", but I can't think of a better word to describe the highly technical process of understanding and solving problems with software.