argument patterns
i notice that there are basically three types of things that get said during arguments (or, really, any kind of discussion about resolving a problem).
love's executioner mentions at one point a big mistake in giving therapy: the therapist jumps in with a certain interpretation of the patient's feelings, and the patient closes off and rejects it. the patient must be allowed to arrive at the conclusion themself, to be sure that they understand the analysis leading up to it. even if they did accept the conclusion blindly, they would not have learned, and can't be counted on to improve. (incidentally, the same holds true for TAing students.)
in my time partnering with ntan1 on os and compilers projects, there have been a few times where one of us tries to explain an approach or algorithm that we've come up with, only to the great befuddlement of the other. we both can think very fast about certain things, but in very different ways, so without care, one of us will get left in the dust. imagine how difficult it was to explain why i wanted to send inlined functions back in time to an earlier stage in the compilation pipeline, without a mutual understanding of the requirements and relative placements of the optimisation phases!
i was talking with knightofstarz a bit ago about how while we each love to talk in the very abstract, there are some times when we get confused with each other, and waffle around for a while before realising we have to be clearer about what we're talking about. i pointed out that this fits here: abstraction is analysis, the examples that inspire the abstraction are raw data, and applying the abstraction to interpret a new situation (on the rare occasion that it proves useful) is proposing a solution.
- raw data. what is actually wrong? saying something of this class is generally irrefutable. "i feel neglected when you don't read me a bedtime story." starting a statement with something like "it seems to me", "i feel", or "i don't know about" is a good way to denote it as being of this class.
- analysis. why is it the problem? this is when you have to start collaborating, because sometimes you can get off track: "you don't read me bedtime stories because you don't love me." if your conversation partner thinks your analysis is bad, you both have to step back and collect more data.
- conclusion. based on the analysis, what's the right thing to do about it? "i will run away from home and find a new family." it is most dangerous to say something that falls under this category before all of the contributing analysis be common ground, because then the other person is likely to take the argument south with "how could you possibly say such a thing?". both parties must be willing to backtrack if something said here proves to be off-course.
love's executioner mentions at one point a big mistake in giving therapy: the therapist jumps in with a certain interpretation of the patient's feelings, and the patient closes off and rejects it. the patient must be allowed to arrive at the conclusion themself, to be sure that they understand the analysis leading up to it. even if they did accept the conclusion blindly, they would not have learned, and can't be counted on to improve. (incidentally, the same holds true for TAing students.)
in my time partnering with ntan1 on os and compilers projects, there have been a few times where one of us tries to explain an approach or algorithm that we've come up with, only to the great befuddlement of the other. we both can think very fast about certain things, but in very different ways, so without care, one of us will get left in the dust. imagine how difficult it was to explain why i wanted to send inlined functions back in time to an earlier stage in the compilation pipeline, without a mutual understanding of the requirements and relative placements of the optimisation phases!
i was talking with knightofstarz a bit ago about how while we each love to talk in the very abstract, there are some times when we get confused with each other, and waffle around for a while before realising we have to be clearer about what we're talking about. i pointed out that this fits here: abstraction is analysis, the examples that inspire the abstraction are raw data, and applying the abstraction to interpret a new situation (on the rare occasion that it proves useful) is proposing a solution.