It doesn’t deserve a top-level post, but I do have a method for locating conflicts that works for me—a written self-interview. I open an empty Word document, and imagine that I’m being interviewed by someone (or something?) smarter, more confident or higher-status than me.
I won’t quote my existing interview documents—they’re too context-dependent, and sometimes too personal—but here’s an example of how it usually looks like:
Alpha: You look depleted. What’s bothering you? Me: I feel that the work I’m doing isn’t leading me anywhere. Alpha: What do you mean by ‘anywhere’? Money? Fame? Personal satisfaction? Me: Money. Alpha: So, you think that the work you’re doing isn’t going to make you rich, right? Me: Right. Alpha: Then why are you doing it? ... …
The interview continues until I find the source of the conflict and decide how to resolve it. If I can’t locate it on the first session, I get back to the saved document later to continue the interview. I included the names ‘Alpha’ and ‘Me’ for readability—I don’t type any names when recording the interview.
I have at least three occasions when this technique helped me pinpoint conflicts that paralyzed me (one of them was a cause of a 6-month procrastination streak.)
Some programmers do something like this when they’re stuck on a problem—they call it Rubber Ducking. Googling it I just found 4 separate stories about students having to explain their programming problems out loud to teddy bears before they get to ask a teacher.
Interesting technique, I’ll need to remember that.
Reminds me of the several times I’ve thought I’ve disagreed with Eliezer on various issues here, spent a while understanding my objections so I could detail it in a reply, and ended up convincing myself of his orignal position by the time I finished writing.
Would be better if you didn’t say whom you ended up agreeing with. Most people here have either a halo or horns on Eliezer, and discounting that is distracting.
Yes, I confirm that this works—because I myself serve as a Rubber Duck / Teddy Bear. I lead a team of programmers, and they come to me to talk about their current problems. I always welcome this, and I often initiate these rubber-ducking sessions myself.
However, I didn’t realize that I’m essentially rubber-ducking myself (heh!) during my self-interviews. Interesting.
This is a definitely a tool that I use, and teach other people to use. Self-inquiry doesn’t have to be written, but it does have to be done, and it’s generally best to do it in a way that involves an external sense—hearing yourself say it, or seeing it written. I don’t know why exactly it’s helpful, but it definitely is.
The biggest challenges most people have to conducting self-inquiry, though, are that:
They don’t know how to separate the two “voices”, and stay stuck in only one side of the conversation,
They engage in self-defeating behaviors, like criticizing the other voice instead of being relatively helpful/inquisitive/nurturing as you are in the dialog example you gave, and
They have trouble staying focused and knowing how to take the inquiry somewhere without either letting their emotional side run on, or trying to overwhelm it with logic.
It has taken me a long time to learn how to teach around these points, some more so than others.
I don’t know why exactly it’s helpful, but it definitely is.
When you keep it in your head, you don’t have to form words; you can just think about what’s bothering you as a vague concept. When you verbalize it externally, it forces you to clarify those ideas and pinpoint exactly what you’re thinking; as far as I can tell, that’s where the utility of the technique comes from.
I recently rediscovered this as a means, not of solving technical problems, but of overcoming strong negative emotions. Even when I already understood the facts and causes, “talking it out” on the page helped me vent the stress and calm down.
Perhaps in situations where your emotions are inhibiting your thinking, writing the useful parts (what you think, want, and can do) but not the useless parts (“oh god oh god everything is terrible”) gives the former more weight.
It doesn’t deserve a top-level post, but I do have a method for locating conflicts that works for me—a written self-interview. I open an empty Word document, and imagine that I’m being interviewed by someone (or something?) smarter, more confident or higher-status than me.
I won’t quote my existing interview documents—they’re too context-dependent, and sometimes too personal—but here’s an example of how it usually looks like:
The interview continues until I find the source of the conflict and decide how to resolve it. If I can’t locate it on the first session, I get back to the saved document later to continue the interview. I included the names ‘Alpha’ and ‘Me’ for readability—I don’t type any names when recording the interview.
I have at least three occasions when this technique helped me pinpoint conflicts that paralyzed me (one of them was a cause of a 6-month procrastination streak.)
Some programmers do something like this when they’re stuck on a problem—they call it Rubber Ducking. Googling it I just found 4 separate stories about students having to explain their programming problems out loud to teddy bears before they get to ask a teacher.
I prefer the teddy bear, because then you can refer to it as the “bug bear”.
Interesting technique, I’ll need to remember that.
Reminds me of the several times I’ve thought I’ve disagreed with Eliezer on various issues here, spent a while understanding my objections so I could detail it in a reply, and ended up convincing myself of his orignal position by the time I finished writing.
Would be better if you didn’t say whom you ended up agreeing with. Most people here have either a halo or horns on Eliezer, and discounting that is distracting.
+1 mind change
Yes, I confirm that this works—because I myself serve as a Rubber Duck / Teddy Bear. I lead a team of programmers, and they come to me to talk about their current problems. I always welcome this, and I often initiate these rubber-ducking sessions myself.
However, I didn’t realize that I’m essentially rubber-ducking myself (heh!) during my self-interviews. Interesting.
This is a definitely a tool that I use, and teach other people to use. Self-inquiry doesn’t have to be written, but it does have to be done, and it’s generally best to do it in a way that involves an external sense—hearing yourself say it, or seeing it written. I don’t know why exactly it’s helpful, but it definitely is.
The biggest challenges most people have to conducting self-inquiry, though, are that:
They don’t know how to separate the two “voices”, and stay stuck in only one side of the conversation,
They engage in self-defeating behaviors, like criticizing the other voice instead of being relatively helpful/inquisitive/nurturing as you are in the dialog example you gave, and
They have trouble staying focused and knowing how to take the inquiry somewhere without either letting their emotional side run on, or trying to overwhelm it with logic.
It has taken me a long time to learn how to teach around these points, some more so than others.
When you keep it in your head, you don’t have to form words; you can just think about what’s bothering you as a vague concept. When you verbalize it externally, it forces you to clarify those ideas and pinpoint exactly what you’re thinking; as far as I can tell, that’s where the utility of the technique comes from.
I recently rediscovered this as a means, not of solving technical problems, but of overcoming strong negative emotions. Even when I already understood the facts and causes, “talking it out” on the page helped me vent the stress and calm down.
Perhaps in situations where your emotions are inhibiting your thinking, writing the useful parts (what you think, want, and can do) but not the useless parts (“oh god oh god everything is terrible”) gives the former more weight.