I'm curious, what about that semantic differentiation is confusing for you?
At least in my experience, "Software Engineer" is a standard title for the kind of work the author is describing in the article and is often used interchangeably with "Developer".
Maybe in your experience that conflation makes sense, but a developer is not necessarily a software engineer.
There are distinct educational programs that differ between "computer science" and "software engineering", and a number of professional organizations are lobbying for software engineering licensure, similar to other engineering professions.
Even Dijkstra knew of the differentation:
'"A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot."'
I'm glad you brought up Dijkstra. He's famous (amongst many other things) for coining the phrase/concept "separation of concerns". He considered this to be a fundamental principle in software engineering, giving the field of programming more structure as you allude to in your comment.
But that SoC concept is fairly endemic in a field of folks who self-identify as "developers". The MVC/MVVM craze of the late 2000s and early 2010s had this plastered on every blog. You can call the self-identification mismatch a taxonomy issue, but my original comment is trying to deduce why that distinction matters at all in practice if developers are embracing concepts that we would consider "proper" software engineering.
I suspect the distinction is just noise at this point.
I think they mean generally. And I tend to agree. I had suspicions while reading it but wasn't completely sure till I checked the Author's bio on the right. Some, if not a lot, of it doesn't apply well if at all the the "classic" fields of engineering, where engineers tend to be much more focused and trained in their skills.
This seems, at best, an anecdotal and/or an arbitrary distinction about what qualifies as "Engineering". Software engineering, as an applied discipline both in name and in practice, has existed since at least the mid-to-late 1960's. And many of the orgs in those days which adopted that title normatively, employed many folks who were "focused and trained in their skills" (e.g. NASA) and worked alongside of those in the more classical engineering domains.
Speaking in my own experience, working closely with hardware/mechanical/electrical folks on a novel product line, they are exposed to a lot of the same subject matter covered in the article. Many of the tradeoffs explored there are absolutely relevant to the older engineering disciplines.
there's no classical software development engineering so depending where you were trained (web startup vs. software company vs. deep in the bowls of a huge corporation etc.) you could have very different ideas of normal - see eg: https://www.stilldrinking.org/programming-sucks
