The point isn't better or faster, at least in and of itself. It's the higher level approach to system design. The balancing of competing goals, including things like less error prone or less effort to maintain.

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.

> Of course they're idiosyncratic definitions... 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 could agree with that in the general case. However in this specific case the words themselves seem (to me at least) to naturally lend themselves to the distinction. Coding itself morphed into a verb at some point (code and coding were both already nouns). If you consider what it derives from the distinction he's drawing makes linguistic sense.

I guess the alternative would be terminology such as "writing code" versus "designing software"?

> If people misunderstand your message because you chose your words poorly, that's your fault.

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.

> The response was to a talk title, and titles often just try to be catchy.

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.