> when someone says they're a programmer, all they mean is that they write code.

How is this an inaccurate or misleading statement? If they write code for a living, they're programmers.

> A little off topic

IMO that's an understatement.

There is a difference. The difference between someone who works as a programmer, who takes it just as a job but of course can be extremely good at it - just like anything else you practice a lot; and someone who is a programmer. They are lexically the same but they mean different things. The last one, beside working (or not) as a programmer, does it for the art of it. Who not necessarily learns or does something (ships) because it's needed or it provides anything else beside the joy and fulfilment of learning and understanding it. For example, at work, when you want to stop programming you open your own personal open source project and relax for an hour with it. Then you go home after 8 hours of programming and start up your IDE and carry on with your art that may or may not ever see the light of day and it makes no difference.

That's hazy territory. While I understand what you're trying to get across, there's really no point adding layers of hidden meaning and subjectivity to the term "programmer".

(non-software) engineers, lawyers, graphic designers, accountants, chemists, doctors define themselves by occupation and not some subjective non-metric of passion. Why exactly should programming be different?

I'm not arguing that programmers shouldn't be passionate about their work, or work on side projects. However, there's really no point in prevaricating over what a "Real Programmer"(tm) is, beyond the very simple working definition we have.

Because we're talking about programming here. If we were talking about music for example, the same will apply. There are singers and there are artists and there is a clear difference in a song well made and a commercial song. Even if the last one makes you more money. But for programmers there's just that one term to use. So the need to point the hidden meanings.

There are no "hidden meanings". You're making them up.

edit :

Words, like functions, work best when their meaning is simple and clear. Like functions, there's nothing wrong with combining them (e.g. "good programmer", "passionate programmer", "programming craftsman", "software composer"), but shoehorning multiple definitions into a single word will just inevitably lead to confusion.

There is a lot more to software engineering than writing code. As I see it, proficiency in software engineering includes topics such as:

1. cost efficacy

2. availability, reliability, and scalability

3. administration (system administration); operations and support; troubleshooting & crisis management (this and #2 are their own sub-field: site reliability engineering / devops)

4. security: risk analysis, threat modeling, cryptography, access control, vulnerability management, incident response (another sub-field)

5. computing science: algorithms, data structures

6. networks, distributed systems, load balancing

7. programming: languages, compilers, VMs, frameworks

8. quality assurance, testing

9. application architecture

10. data storage: databases, relational and non-relational, caching, transactions, replication, locality

11. facilities, data centers (power distribution, cooling - though that's getting more into system engineering)

12. product design, customer experience, accessibility, human factors

13. project management

I think of programming as the art of writing code. Engineering is the act of creating reliable, controllable systems -- systems that achieve their technical goals and business goals in a steady, reproducible way. Engineering is the act of balancing tradeoffs scientifically and ensuring that quality goals are effectively met.

You might call any autodidact coder a programmer. College students can be adept programmers. However, writing code is just one part of being a software engineer. I would expect senior and above level software engineers to have experience in most or all of the topics above, and I'm sure there are more that deserve to be on the list.

Engineering in the software field isn't /always/ about building super-reliable things. That is one factor that I think differentiates it from other engineering fields. Engineering in the real, physical space has safety implications that typically require a high level of rigor at minimum. If a bridge fails or a building collapses, that's catastrophic. Physical products are only useful if engineered to a high level of quality. However, software is useful across a wider spectrum of reliability: if a back-office web app used by the recruiting team has to come down for maintenance for 2 hours on Sunday, that may not be a showstopper.

Consequently, part of software engineering is understanding what level of robustness is needed to meet business goals, and building to it appropriately, with appropriate costs, and understanding the properties of the built system. Controlling the level of reliability is what makes it engineering.

To be fair, I cannot account for what someone else means when they say they're a software engineer. But this is what I mean, and I consider the field to cover a number of topics and subjects beyond programming.