Software Engineers do not write code. Implementors (coders) write code. Engineers think (deeply) about what code needs to be written, and, what trade-offs need to be made to simply make the system work. Production Engineers think about making trade-offs so that the system is “efficient” along one or more dimensions (speed, space, cost, etc.), but, only after the initial system is working and shown to satisfy end-users’ needs. Current popular programming languages, like Rust, Haskell, Python, etc., conflate all of these issues together, thus, making the code more difficult to design. Conflating issues together like this has a name: “cottage industry”. Then, there’s Software Architecture, Maintenance, Testing, Q/A, Security, etc., etc. The above pattern is visible in other, older professions, such as building construction. Software might re-use these ideas and re-purpose them for creating electronic machines. Note, too, that more-established professions use diagrams to augment the use of written words when communicating designs (blueprints, schematics, molecular diagrams, etc.). Note, too, that more-established professions use elements that are completely isolated and decoupled from one another. This assumption (of inherent non-coupling) is violated by most popular programming languages.

The above pattern is visible in other, older professions, such as building construction. Software might re-use these ideas and re-purpose them for creating electronic machines.

Note, too, that more-established professions use diagrams to augment the use of written words when communicating designs (blueprints, schematics, molecular diagrams, etc.).

do you think that software development has any actual similarities to construction in the arc of it's actual praxis when removed from business contexts? By this question I mean: it seems that a lot of folks readily reach for architectural/engineering analogs when talking about software dev., but, when I think it through I struggle to see the actual similarities outside of how projects are run...and how projects are run, to my mind, has little to nothing to do with producing good outcomes and everything to do with leaning on known business processes. What if a software team was run more like a kitchen, or software dev was thought of as being more akin to weaving at a loom?

Yes, I believe that software development should be like The Film Industry (or Construction, or ...) But, I believe that software development - in its current form - cannot be easily stratified into layers. The wrong questions are being asked, emphasis is not being placed on layered processes and technologies. Engineering processes were not created by business. Engineering processes were created by Engineering. Business capitalized on this structure, later. ” ... Those different roles tend to rely on elements that are wholly (or at least mostly) isolated and decoupled from one another. ...” Software libraries, though, are not wholly isolated. This limits growth and prevents a Moore’s Law for Software from existing and prevents Christopher Alexander-like Patterns from being applied (easily).

I think the follow-up question is how to create these layers or different roles, rather than just that they should exist. Because your posts are more a question than an answer. My first concern is that people will blur the boundaries between roles. For example, my day job is in deep learning and we have this somewhat defined separation that engineers build deep learning frameworks in C++ and then research scientists use them from Python. But too many people cross the boundaries where scientists need to change libraries that I'm not sure this separation was good for the field. As another example, front end engineers might contribute to designs and back end engineers might contribute to the architecture. So while these separations should probably exist, I would rather them be a soft separation rather than a hard one. One part of my own work that might be relevant is this piece I call choice. The goal was to separate correctness from optimization and it can be used to separate say implementers and engineers from production engineering. But it also makes it easier to build layers that combine with greater possibilities. Do you see something like this as helping in creating some level of separation of layers or roles?

You've likely read this already, but Hillel Wayne wrote a good series titled Are We Really Engineers? interviewing many engineers-who-became-programmers comparing the fields — though, upon glancing at it again, I thought he had discussed the layers that other professions have (i.e. architect, engineer, construction, etc.) and I don't see it. Still a good read.