If you google around you get pages like this:
https://www.electronicproducts.com/Education/Career/Software...
> Computer programmers receive specifications from software engineers and turn the program design into written instruction codes that the computers will follow.
In 2020, this is a load of baloney.
It sounds like it was like a term to distinguish senior and junior developers.
A modern developer is concerned with the whole process start to finish, and owns the maintenance and design of the software. A senior developer will know more about how to architect a complex application but otherwise the role is the same.
I wouldn’t worry about it. I’ve worked at companies that have called me a DevOps Engineer, SRE, Linux Systems Engineer, and these were all identical roles. Titles are just about ignorable, it’s more important to look at what skills are needed, what the day to day job looks like, and of course, compensation.
From my perspective a programmer is just able to write code, i.e. turn the business requirements into instructions.
A software engineer is rather able to design/architect a system, let it be a single web page or a container cluster.
Then the question is how people learn "how to architect a complex application"?
Once you can write code you can architect a system. There’s nothing stopping you. The information is out there.
Perhaps the real question is whether your company trusts you enough to make something from scratch. Or whether your solution is good enough to handle large amounts of customers, traffic, or usage.
People learn to do so with a combination of experience and just general learning (documentation, tutorials, references, talks, conferences, etc) over time.
I think a modern company would simply call both roles “software developer” and apply different levels of seniority (e.g. junior, senior, staff, or they could use numerical levels).
I am working in the area where software quality is important, so we do have a very clear distinction between the roles (and also between maturity levels). We have (among others) people who do a formal description of the customer's problem (requirements engineers), others who convert it to a product specification (architects), third who manage the implementation (project managers) and the implementers (programmers).
Every level has its own requirements and skill sets. For example, only the programmers are working with code, so their job is to be experts in the language, frameworks, hardware interfaces and the like (we also have hardware engineers to design the hardware). Architects are working with models - their job is to derive the proper constraints and project structure from the requirements, to ensure its correctness and to provide a way to prove it. Managers and requirements engineers are working with people. Of course, there are architects or managers who have been programmer before, but in general it's not really necessary and sometimes even benefitial to not have a programming background.
If you heard about "separation of concerns" or "single responsibility principle" in software, well we're using it also in our development process.
But I'm quite sure it's not "modern".
I basically just run with it at this point. It's hard to explain to my parents that I can train a CNN to identify them from a video camera and at the same time I might have to spend an hour to get the right look and feel for a button on a web page.
On the flip side, I really do wish we had some sort of title/ merit system that made sense to the rest of the world (aside from working for FAANG cos). The technical sophistication of individuals in our industry blows away the capabilities of other industries...