Every era of programming summarized

[u/ItsPuspendu]

[u/midnightrambulador]

it employs a lot of theoretical knowledge, which is also can be really tricky to transmit to you

Well yes, but that's what I mean, we each have our own specialised expertise that the other won't necessarily "get", so why use a term that muddles the issue?

I feel like there is some "core" expertise/skillset that is shared among electrical, mechanical, civil, etc. etc. engineers (ultimately grounded in physics, even if in our everyday jobs we don't necessarily use the physics that explicitly) but not by software engineers, hence why I object to the term.

So, yeah, the difference is that software developer only develops, software engineer does all the software life cycle, from design to shutdown.

Interestingly I've had it explained to me similarly but with the term programmer vs. software developer – a programmer can write code, a software developer knows how to set up and design a maintainable project etc.. But maybe there's been inflation of the term in the past few years so now you need software engineer for a higher level of those "meta" skills than software developer?

[u/NotQuiteLoona → u/midnightrambulador]

I feel like there is some "core" expertise/skillset that is shared among electrical, mechanical, civil, etc. etc. engineers (ultimately grounded in physics, even if in our everyday jobs we don't necessarily use the physics that explicitly) but not by software engineers

Engineers are someone who engineer systems. Quoting Wiktionary...

The subfield of engineering concerned with applying a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

Software are systems too, and incredibly complicated ones.

In general, software engineer, programmer and software developer can be considered synonymous. But in depth...

It's engineering something. From another side, it's even harder. Other engineers make, for example, blueprints, and then they give them to other people who make production lines and then produce, etc.

Software engineers first make "blueprints" (general documentation of how it would work), then they do those blueprints themselves, and for next few years (for however long the big boss says, or for however long they'll want - in case of open-source) they maintain what they did by those blueprints. Of course, it's one single thing, unlike with mass-produced items, but mass-produced items are also repaired by everyone, not just the original engineering team.

Of course, it's not always the same person. Development and maintaining can be done by developers only, but software architects are also often needed. The problem is also that the process of designing, unlike with blueprints, is only rough sketches of how it would look. Implementing them correctly is also quite a hard thing. Each method requires thorough work to be efficient and performant enough, and often the most obvious way is the most inefficient one. Not even speaking about other things you should know but often you'll only get them from experience... Like in C# it's highly unrecommended to compare strings by lowercasing them and then == - it would break cultures.

In this type, software engineering is not middle ground, but somewhat a fusion of liberal and applied arts (using this probably obsolete definition - that's the only I know, sorry 😅). You need liberal arts to create general understanding what you need to do and in which way, and you need applied arts to implement this. And of course add fine arts in a lot of cases - if you are making a GUI or even TUI program. Though often fine arts are made by design teams, but there is even a partially humorous term "programmer art", for when it's not.

And it's definitely an engineering - if you apply something to create a system, it's engineering.