5 ms·

I think this "poor writing", as in hard to understand writing with long backreferences is due to the same reasons as why many academics are terrible at explaini

I think this "poor writing", as in hard to understand writing with long backreferences is due to the same reasons as why many academics are terrible at explaining things, as well as why source code is hard to read. I should know, others usually like pointing out how terrible I am at explaining things. And I think I know why. When I make a naive attempt at describing a complex, interconnected concept, such as a piece of math, or a program that does a thing I start with a mental picture - a graph of interconnected concepts. Then I try to describe the picture - the same way one would describe a painting. I describe each visible part separately, often in great detail, then I try to describe the links and interconnections between parts. This sort of 'accurate' descriptive style naturally leads to huge backreferences, and people usually have a ton of trouble following along. However I think there's a way of getting your point across - one basically needs to reproduce the thought process of how one would come up with the given model given the real world constraints, illustrating the issue and its proposed solution with examples. It is often said that people are much better at deriving the rules from a few examples than the other way around. However this sort of descriptive style takes both a lot of effort, and usually is less precise, which often is not acceptable, such as in the case of contracts or computer code.

ilaksh 4y ago
Good point at the beginning about how serialization of complex structures works, but false conclusion. Good writing, just like good code is well-factored and self-documenting. Easy to understand identifiers, short functions. What you suggesting is the equivalent of writing a module using a long string of function calls, some of which have very non-obvious meanings, and claiming that there isn't a way to factor it out.
thechao 4y ago
Build a simple model you can explain in a few sentences; perhaps accompanied by a simple picture. Elaborate details in each important direction, separately. Finally, describe unusual complications that arise when different elaborations are combined. Use a narrative voice when there's a process to explain (but, be sure to use numbered statements!). Use a well-known top-level article structure to help familiarize your reader — but be sure they know to expect that structure. Finally, always edit for clarity.
BurningFrog 4y ago
Explaining something to another human is hard for people "on the spectrum", in part because they don't have a strong "theory of mind". Instead of understanding and/or inquiring how the other person's mind state differs from yours, and what gradual steps might lead them to greater understanding, they tend to treat people like a file system with a missing file, and stream the relevant data into them, assuming it will all be recorded. This is not a simple problem to solve, but it can be done, and the first step is to realize the nature of the problem. One simple process is getting feedback along the way. Instead of the 5 minute lecture, go step by step, and check that your counterpart has picked up what you're putting down. https://en.wikipedia.org/wiki/Theory_of_mind https://en.wikipedia.org/wiki/Theory_of_mind
- moffkalast 4y ago
  > they tend to treat people like a file system with a missing file, and stream the relevant data into them Pshhhkkkkkkrrrrkakingkakingkakingtshchchchchchchchcchdingdingding Connection established
lo_zamoyski 4y ago
> one basically needs to reproduce the thought process of how one would come up with the given model [...] people are much better at deriving the rules from a few examples than the other way around. Indeed. I don't think this is as mystifying as some people seems to believe. There seem to be at least two errors poor communicators make. The first is that communication doesn't transfer any content from one person to the other. We use signs and symbols with conventional meanings both parties accept to express things which are then interpreted by the other party. If you're not both on the same page, you have to first establish that common ground. Much of education involves building up that common vocabulary and system of signs so that we can even have the conversation. To think of communication as if you were some act of piping the actually semantic content from your mind to another's is to completely misunderstand communication and a recipe for failure and frustration because you will be unable to understand why someone cannot just grasp the content you think you've just poured into their head. "It's right there! I just gave it to you!" This brings us to the second error. Knowing your audience means knowing what their current state of knowledge is. Part of that is knowing the vocabulary and system of signs your interlocutor knows. Explanation is therefore a matter of using what they already know to lead them to the conclusions you already have (introducing claims as necessary). Once the aim of explanation is stated that way, it starts to resemble something like a chain of reasoning...or an argument, which it basically is. I cannot derive certain theorems if I have not yet derived certain prior theorems, much less if I lack the axioms from which they are derived.

ilaksh 4y ago

Good point at the beginning about how serialization of complex structures works, but false conclusion. Good writing, just like good code is well-factored and self-documenting. Easy to understand identifiers, short functions. What you suggesting is the equivalent of writing a module using a long string of function calls, some of which have very non-obvious meanings, and claiming that there isn't a way to factor it out.

thechao 4y ago

Build a simple model you can explain in a few sentences; perhaps accompanied by a simple picture. Elaborate details in each important direction, separately. Finally, describe unusual complications that arise when different elaborations are combined. Use a narrative voice when there's a process to explain (but, be sure to use numbered statements!). Use a well-known top-level article structure to help familiarize your reader — but be sure they know to expect that structure. Finally, always edit for clarity.

BurningFrog 4y ago

Explaining something to another human is hard for people "on the spectrum", in part because they don't have a strong "theory of mind". Instead of understanding and/or inquiring how the other person's mind state differs from yours, and what gradual steps might lead them to greater understanding, they tend to treat people like a file system with a missing file, and stream the relevant data into them, assuming it will all be recorded. This is not a simple problem to solve, but it can be done, and the first step is to realize the nature of the problem. One simple process is getting feedback along the way. Instead of the 5 minute lecture, go step by step, and check that your counterpart has picked up what you're putting down. https://en.wikipedia.org/wiki/Theory_of_mind https://en.wikipedia.org/wiki/Theory_of_mind

moffkalast 4y ago
> they tend to treat people like a file system with a missing file, and stream the relevant data into them Pshhhkkkkkkrrrrkakingkakingkakingtshchchchchchchchcchdingdingding Connection established

lo_zamoyski 4y ago

> one basically needs to reproduce the thought process of how one would come up with the given model [...] people are much better at deriving the rules from a few examples than the other way around. Indeed. I don't think this is as mystifying as some people seems to believe. There seem to be at least two errors poor communicators make. The first is that communication doesn't transfer any content from one person to the other. We use signs and symbols with conventional meanings both parties accept to express things which are then interpreted by the other party. If you're not both on the same page, you have to first establish that common ground. Much of education involves building up that common vocabulary and system of signs so that we can even have the conversation. To think of communication as if you were some act of piping the actually semantic content from your mind to another's is to completely misunderstand communication and a recipe for failure and frustration because you will be unable to understand why someone cannot just grasp the content you think you've just poured into their head. "It's right there! I just gave it to you!" This brings us to the second error. Knowing your audience means knowing what their current state of knowledge is. Part of that is knowing the vocabulary and system of signs your interlocutor knows. Explanation is therefore a matter of using what they already know to lead them to the conclusions you already have (introducing claims as necessary). Once the aim of explanation is stated that way, it starts to resemble something like a chain of reasoning...or an argument, which it basically is. I cannot derive certain theorems if I have not yet derived certain prior theorems, much less if I lack the axioms from which they are derived.