As a S/W dev who started 30 years ago and finished his MSCS 27 years ago, I totally agree - S/W engineering (SWE) today is NOTHING like it was in the 1980s. SWE then was seen as mainstream CS and often a required part of a CS degree. Today, CS profs working in SWE are rara aves.
SWE's desiderata then was to become an engineering process, where components were marshalled into a formal blueprint, and only THEN did implementation begin. And when implementatione ended, only THEN did testing begin. And only pro TESTERs do the testing. And only pro librarians did the project configuring and building and SCCS control and S/W maintenance and releasing.
Much of today's SWE is subsumed by the choice of programming tools, esp the language: its innate constraints its object model, its hierarchical library interdependence, and the sundry constraints & guidelines these impose.
In 1985 there was a LOT of discussion of how to introduce more proscriptive programming models as ways to shape how programmers think and design and implement. Today most of that discussion is moot, since most prog. languages implicitly enforce most of that (implementation) proscription. And where voids exist (as in design), language convention and idiom (and community bias) tend to step in to constrain choice to shape thought and close the loop.
No, I think SWE has changed enormously since the antedeluvian world views that wrought the invention of Ada or Beck's first writing on Agility. Perhaps for S/W devs under age ~50, who grew up in the mature world of OOPLs, unit testing, and 'Agile uber alles', that form of SWE seems to be inviolate and have existed since time began, perhaps discovered on clay tablets in an ancient Ark. But no...