I think context clues do usually make the difference between signal as in cell signal vs. kodo clear. I’m less confident that context will usually make the difference between signal as in signal and the noise vs. kodo clear. Most conversations I have with other people where I’d want to use it, I expect they won’t have this concept and it’s not worth pausing whatever conversation we were having to explain kodo.
(Like, prior to me writing this up I think there were maybe a hundred people in the world who’d heard these terms used this way, because there were maybe a hundred people who’d heard the lecture.)
A concept can still be useful in my own head even if the people I talk to don’t have that concept. Affordance, update, modularity (especially in code), these are all ideas I don’t talk about directly except with specialists but I have in my thoughts when it’s relevant. And one way to get other people to have a concept is to give a talk on it, or to write an essay about it on LessWrong.
Take modularity in particular: at some point in a good Intro To Programming class someone should explain the idea of modular code and why you should try to make your functions neat and compartmentalized, once in a while when talking to another programmer one of you might say ‘oh, I want to refactor this to be more modular’, but when you’re talking to your non-technical boss or client you probably don’t want to use that word. Is modularity a basic idea? Maaaybe? Depends on your frame of reference I guess. Does it serve a purpose other than in-group signaling? Yes! A programmer who doesn’t have the concept will write “worse”[1] code.
That doesn’t make a convincing argument that this idea in particular is worth a jargon slot, but taking ideas and assigning specific words to them is useful.
I think context clues do usually make the difference between signal as in cell signal vs. kodo clear. I’m less confident that context will usually make the difference between signal as in signal and the noise vs. kodo clear. Most conversations I have with other people where I’d want to use it, I expect they won’t have this concept and it’s not worth pausing whatever conversation we were having to explain kodo.
(Like, prior to me writing this up I think there were maybe a hundred people in the world who’d heard these terms used this way, because there were maybe a hundred people who’d heard the lecture.)
A concept can still be useful in my own head even if the people I talk to don’t have that concept. Affordance, update, modularity (especially in code), these are all ideas I don’t talk about directly except with specialists but I have in my thoughts when it’s relevant. And one way to get other people to have a concept is to give a talk on it, or to write an essay about it on LessWrong.
Take modularity in particular: at some point in a good Intro To Programming class someone should explain the idea of modular code and why you should try to make your functions neat and compartmentalized, once in a while when talking to another programmer one of you might say ‘oh, I want to refactor this to be more modular’, but when you’re talking to your non-technical boss or client you probably don’t want to use that word. Is modularity a basic idea? Maaaybe? Depends on your frame of reference I guess. Does it serve a purpose other than in-group signaling? Yes! A programmer who doesn’t have the concept will write “worse”[1] code.
That doesn’t make a convincing argument that this idea in particular is worth a jargon slot, but taking ideas and assigning specific words to them is useful.
Yes I’m asserting a broad and fuzzy quality of better or worse to code, I’m confident a jury of a dozen software engineers would back me up here.