3 ms·

Those are idiosyncratic definitions that are not even remotely common or shared. It people misunderstand your message because you chose your words poorly, that'

Those are idiosyncratic definitions that are not even remotely common or shared. It people misunderstand your message because you chose your words poorly, that's your fault. 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.

fc417fc802 2y ago
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.
- crazygringo 2y ago
  > 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?
  - fc417fc802 2y ago
    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"?
pron 2y ago
> 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.
- crazygringo 2y ago
  > 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.

fc417fc802 2y ago

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.

crazygringo 2y ago
> 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?
- fc417fc802 2y ago
  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"?

pron 2y ago

> 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.

crazygringo 2y ago
> 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.