It also feels like something of a straw man -- in reality, you have junior programmers/coders and senior programmers/coders and they get better over time.
In real life, they aren't two distinct activities. People write code to get things done, and as they get better they are able to write code that is faster, more elegant, or more scalable. But premature optimization is also the root of all evil, as one saying goes -- plenty of code doesn't need to be faster, more elegant, or more scalable. It just has to work and meet a deadline. And there's nothing wrong with that.
You speak of programmers getting better over time. The point is to break that improvement down into distinct categories.
Of course they're idiosyncratic definitions. He's attempting to make a distinction which he feels is useful. He needs words to communicate that distinction.
Generally people invent new terms by combining words, or call them programmers of "type 1" and "type 2" or something.
Using existing term that are synonyms, and inventing a distinction between them, is unusual, unhelpful, and confusing.
It's like me saying that sofas are always better than couches because sofas are designed with comfort in mind while couches are intended to maximize manufacturer profit. Huh?
I guess the alternative would be terminology such as "writing code" versus "designing software"?
But nobody misunderstood a message, which was clearly communicated in the talk. The response was to a talk title, and titles often just try to be catchy.
> In real life, they aren't two distinct activities. People write code to get things done, and as they get better they are able to write code that is faster, more elegant, or more scalable. But premature optimization is also the root of all evil
It's nothing to do with optimisation or elegance but about the process of writing software that does what it's intended to do, and a way that "gets things done" more easily in some situations. It's fine if you don't want to watch this interesting talk by one of the world's preeminent computer scientists, a Turing-award-winning expert in software correctness, but this discussion about the talk's three-word title is pointless.
For every person who spends an hour listening to the full talk, hundreds or thousands will see the talk title, and decide whether to watch based on the title.
It's even more important to be clear rather than confusing in your title. Not less. Titles matter hugely. They determine, to great extent, whether someone will even listen in the first place.
English has a lot of words from different origins that are more or less synonyms and one of the most common time wasting behaviours i’ve seen is people endlessly trying to categorize those words in endless debate.
The web is full of endless slideshows with titles such as ‘the difference between management and leadership’ or some such. One’s a latin word and the others german for basically the same concept and since english has both (it steals from every other language without care) you’ll find a million slideshows people have created on the differences between the words. This whole thread is yet another example of this behaviour and if you’re aware of it you’ll very quickly tire of every fucking ‘the difference between [english loanword from latin] and [english loanword from german]’ thread you’ll see.
― James D. Nicoll
English doesn’t have a lot of duplicate words because of some aggressive vocabulary-stealing nature. It has a lot of duplicate words for the same reason modern Nahuatl has a lot of loanwords from Spanish: England was colonized and ruled for centuries by non-English-speaking people.
It's meant to differentiate human "programmers" from AI "coders". Ever since LLM showed up there has been a noticeable urge to redefine the value proposition of software work to be less about what LLMs can do (write code) and more about what humans can do (write programs).
We’ve been having this debate for my entire career (since at least 2010). The suits have always misunderstood what programmers/engineers do and we’ve always pushed back explaining that it really is closer to city planning than to brick laying.
The agile manifesto (2001) was in large part a response to these pressures to think of programmers as the people who “just implement” what the smart suits have already figured all out.
They are different and they absolutely do matter.
DateTime.Now() is a perfectly valid thing to write while coding. Unless you are in a distributed system, where 'now' doesn't exist, so all source code using 'DateTime.Now()' is automatically suspect. How do you know if you're in a distributed system? That's a programming question, not a coding question. And from a lot of the microservice push-back you get here on HN ("just use a single DB instance - then your data is always consistent",) a lot of devs don't realise they're in a distributed system.
"Backtracking", "idempotent", "invariant", "transaction", "ACID", "CAP", "secure", "race condition", "CRDT", are all terms that exist at a programming level, but they don't show up in the source code. A single effectful statement in the source code can be enough to break any of these quoted programming terms.
Except we're talking about a talk title. Lamport explains what he means in the talk. What I responded to was a comment on the content based entirely on the title.
> It's trivial and it doesn't matter, and specifically using language to highlight that difference is pointless.
Sure, and that is precisely Lamport's point. You really need to watch the talk. He shows how abstract algorithms cannot be fully described in any language that is intended to be executed by a computer.
> Similarly, it's annoying and pointless to pedantically argue that "well actually that's not programming, that's coding".
And Lamport is not doing that. You're arguing over a pithy title to a rather deep talk.