Discussion about this post

User's avatar
Mattias Martens's avatar

For your example, I agree very much with the use of “server” and “cache”. These are nice terms because they have non-technical meanings and the meaning of the technical words comes directly from the functional purpose implied by the commonplace meaning. A “server” is something/someone that fulfils requests (in this case for answers about data), a “cache” is a place to keep a portion of something far away from its storage site so you have easy access to it (in this case: answers about data).

A friend’s computer crashed and gave her the message: “a thread is stuck”. Having no computer knowledge, she misinterpreted what that could mean. IMO “thread” is a bad term to show to an end-user because, in the context of a typical error message, the commonplace meaning does not hint at the technical meaning. But there are other technical terms, like “process” or “worker”, that would.

In general, a simplification should never cut all the threads that could lead back to the truth it’s simplifying. There should always be something, even if it’s embedded in a clause like “what experts call ’criticality event’”. I especially like it when there’s a chance to serve two audiences with strategic use of double meanings.

Ljubomir Josifovski's avatar

Very good - thanks for sharing this, like it.

This recalls to my mind "everyone should be treated the same, even if they are not the same." People are different - yet we should treat them all the same, as if they are the same.

Likewise in your case - we should explain to people as if they can understand, even if maybe they can't. I subscribe to this principle. For one thing, we may be surprised - one never knows. For another, how are we to learn new things, if we are only told as much as we already know, but not more.

Yes the teller runs the risk of being overly detailed and ultimately boring. For if the interlocutor doesn't understand, they may get bored and even frustrated. That's fine. My ego can take a hit, I'm fine risking it. When I notice I wrap quickly in a sentence and shut up. Not a biggie.

Amusingly, people find similar when teaching computers new things they have never seen before. (check Jeff Clune lectures, talks, podcasts interviews) Teaching them too easy things they already know how to solve - is a waste of time, they already know, so learn nothing new. Teaching them too hard things is a waste of time too, because they don't solve it fail to get to the solution. But we want them to learn to discover a solution on their own, independently. Not just memorise and in the future pattern match an answer they blurt out. The aim of their research is to teach the model how to learn on his own. Not just what's the right answer is, but to learn the process by which we humans find the answer.

There is a Goldilocks zone, where the system is at A, and we want it too get to B on its own. If B is about 20% away, 20% more difficult, but no more than that, then the model stands a non-trivial chance of discovering in its own, the stepping stones that allow it to get from A to B successfully. And discover that on its own. That part is crucial. They are training the model how to learn on its own. So them laying the stepping stones is no good, is counterproductive. The aim of the exercise is for the model to learn how to go on about discovering the stepping stones on its own.

14 more comments...

No posts

Ready for more?