That is interesting, thanks. What I’ll agree to is that it is possible in principle to vary the extent to which you apply traditional engineering concepts to software development. But I believe that’s good ol’ cross-disciplinary insight (are genetic programmers biologists?) And maybe if you turn that knob all the way up, maybe you could be said to be doing engineering. But I’m not convinced of that last part yet, and I am really not convinced that it would be desirable industry-wide. I really, really like the way I work, and so do my superiors, and seemingly so do our customers; and I didn’t learn this by studying engineering or trying to think like an engineer.

But perhaps most importantly, I think we all know (right?) that the title Software Engineer is not, in practice, currently imparted consistently with how much “real” engineering is being applied.

My impression (which kind of matches the blog series) is that that "like an engineer" bit is a bit overhyped in these discussions. E.g. a good chunk of what I do is embedded software, so I sometimes work with EEs that have designed the hardware my software is supposed to run on - and the range of how systematically (or not) they approach things isn't any smaller than the one you find in software. (Now I wonder if they also have discussions of "if you are just combining parts on a board and not designing your own ICs, are you really an engineer?", but given what I've seen I doubt it - they seem to care mostly about who has the formal right to claim the title)

Yeah, that's my experience too. And I can report, from working with EEs and talking to EE family members, that they do sometimes engage in that sort of my-subdiscipline-is-realer-than-yours one-upmanship too, but more often it's about using "outdated" design practices vs. "immature" ones, or about the appropriate balance of planning vs. exploration for a given project. All very familiar territory for programmers, though there are some differences.