Mmm nice. I went through a similar progression in some ways and I feel like I'm tasting a step further which is something like "the issue people have is they try to use self-modification techniques they don't have full buy-in for, and so resisting parts stop them from using those."
And then the resolution goes something like, instead of intending to do "IDC" or whatever else, orienting to a stance of intending to do more like "whatever it takes to have an internal dialogue here that integrates all objections thoroughly and doesn't dismiss or discount any"
Worth noting: my articulation above is coming out backwards from how I experienced it.
For me it was more like... I tasted something that felt like this thing, and then had immediate buy-in from all of my parts to iterate on the thing until it became capable of integrating all of them in their own terms. And the act of trying and iterating, in such a way, is kind of the thing.
This post is a response to the request for a post with a "thorough description of how to do pair debugging"; I'm also having this post double as a retrospective on my attitude towards pair debugging in general.
At CFAR, one of the exercises is 'pair debugging'; one person is the protagonist exploring one of their problems, and the other person is the helper, helping them understand and solve the problem. (Like many things at CFAR, this is a deliberate and distilled version of something that already happens frequently in normal life.)
Starting from late 2014 (when I visited my first CFAR workshop), I ran an in-person rationality/self-development group which was inspired by CFAR's practices but also went in its own directions. One of the activities we had were regular debugging circles: people would split into small groups and then take turns where one person at a time would explain a problem that they were having and others would then attempt to help them out with it.
As I've understood CFAR's debugging circles, they are relatively free-form by design; the main focus is on exploring the problem together, and also notice opportunities where various rationality techniques could be applied. As such, they avoid having too much explicit structure in order to allow many different approaches. Yet as there still seems to be something like "the skill of doing good debugging", in 2015 I wrote the following guidelines for us that seemed to distill some best practices.
Only bring up something if you actually want a solution for it. Everyone has times when they just need to vent and want sympathy rather than solutions, but debugging circles aren't the place for that. This doesn't mean that you would need to accept any suggestion that the others bring up, but it does mean that that you should be open to others offering suggestions in general. Once the session ends, you're free to just ignore and forget anything that didn't seem to make sense to you.
Be courteous of others and their time. Do your best to make sure that everyone, both you and the others, get a roughly equal share of the group's attention. If you have lots of problems in your life, don't dump all of them on the group at once, but rather focus on one or a small set of related ones. If it starts looking like the discussion has gotten stuck on one person's issues for an extended time and the others might not have a chance to have their issues discussed, gently but firmly suggest moving on to the next person. Try to be considerate enough to pass on your own turn early enough that someone else doesn't need to prompt you to do so.
If someone is undergoing a particularly difficult time or has a particularly important issue going on, it's alright to sometimes spend a disproportionate time on them: but you should try to avoid being that person each time.
But have a fair respect of your own time, as well. The opposite also applies: if you genuinely feel that there's nothing in your life that needs discussing, you're free to cut your own turn short, but if you do it many occasions in a row, you're probably not taking full advantage of the group. If nothing else, you can always use the group to get an opinion on any assumptions behind your current plans. You have a right to get help from the group in return for helping others: stick to that right.
Don't proselytize your view. Maybe you're completely certain that the cause of the other person's problems is that they don't have cat ears as a part of their attire, which would totally fix everything if they just changed that. You're free to think that, but if they disagree with your suggestion, don't get stuck arguing but let it go.
Start by trying to understand what problem the person is trying to solve. "I've been trying to sign up for dance lessons but can never seem to get around it." One possible approach would be to immediately start offering ways for the person to sign up for dance lessons. Often a more fruitful one would be to first ask - why do you want to attend dance lessons? Maybe it turns out that the person doesn't actually care about learning to dance, but is feeling bad because their friend, a great dancer, always gets all the attention at parties. Then the actual problem is not "how to learn to dance" but "how to get other people to notice me". It's quite possible that not knowing to dance isn't actually the biggest issue there.
Test your understanding of the problem. When you're formulating an understanding of the problem, it can be useful to frequently verbalize it to the other person to make sure that you've understood correctly. "So you seem to be feeling bad because your partner just became the President of your country while you mostly spend time playing video games, is that right?"
A rule of thumb that I sometimes use is "do I feel like I understand this problem and its causes well enough that I could explain to a third person why this person wants to solve it and why they haven't been able to solve it yet?" If the answer is no, hold off proposing solutions and try asking more questions first.
Even "obvious" problems may benefit from questions. Someone once mentioned that they tend to often jump to being critical of others, which tends to be harmful. Here the causal mechanism seemed to be pretty obvious, but asking "how does it tend to be harmful" was still useful in bringing out details of the exact nature of the typical criticism and how people tended to react to that.
Look for trigger-action patterns. "I always end up being on the computer and wasting time and then feeling bad." What specific things on the computer act as time-wasters, and how exactly does the person end up doing those things? Maybe they often feel bored or anxious, which causes them to open Facebook, which causes them to get lost in a maze of discussions and links. Would there be a way to either remove the anxiety, or find a new action to carry out when anxious? Which one would be easier?
Look for positive and negative reinforcers in the environment. "I often post a link to Facebook, and then I keep returning to Facebook throughout the day because I want to see whether it's accumulated new likes and comments." Here, logging on to Facebook after posting a link keeps getting reinforced by the accumulation of comments and likes, which provide a reward each time that the page is opened and there's a new one. Could something be done to eliminate those reinforcers? ("If anyone sees me responding to a comment or posting a link, don't like it but do remind me that I was supposed to be working.") Or maybe provide reinforcers for something else? ("For each ten minutes that passes without me logging onto Facebook, could you please come give me a hug?")
Be specific about the causes of emotional reactions. "My boss is so full of himself, it drives me nuts." Exactly how does the full-of-himself-ness manifest? If the exact behavior is "he often interrupts", maybe something could be done about that thing in particular. Best case: the boss comes from a conversational culture where interrupting is normal, and hasn't even realized that someone would consider it rude - but this would have been impossible for the others to suggest if the problem description would only have been on the level of "he's so full of himself".
This is also a useful technique for reducing your own annoyance at others, even if it was just something you did in your head. "I'm getting frustrated now because that person is talking really loudly and I would like to read." Breaking down an atomic "AAAAAGH I'M SO FRUSTRATED" into a "I'm feeling [specific emotion] because [specific cause] and [that violates my desire/need to something]" is not only useful for debugging, it can also relieve the frustration by itself.
Assume that problems won't fix themselves. In one session, someone says they intend to implement some change for next week's meeting. In the next session, they say, "yeah, that plan didn't really work out, but I was kinda busy and distracted this week. I'm going to try harder."
Chances are, if they were busy and distracted this week, they're likely to be busy and distracted the next week, too. "I'm going to try harder" often translates either as "I don't actually care about solving this problem but want to give the impression that I do", or alternatively, "I don't actually know how to fix this but I'm going to try again the same way, in the hopes of magically getting a different result now". Assuming that the person really does want to solve their problem, try to figure out exactly what went wrong and how it could be avoided in the future.
Ask, "is there a more general problem here?" Someone wants to cut down on the amount of money that they spend on fast food. One day when they're coming home from work they walk past a hamburger place, are tempted by the advertisements, and go there to eat. This happens several times.
The specific problem in this case would be "I always end up eating at the Burger King on the 27th street on my way home". The more general form of the problem might be something like "each time I walk past a fast food place when I'm hungry, I end up eating there". General solutions might be "pick a route that allows you to avoid seeing fast food places when you're hungry" and "make sure to carry something with you that allows you stave off the worst of the hunger until you're home".
Focusing. Someone is having difficulties deciding whether to try to solve a problem or whether to accept its consequences and let it be. One approach would be to have them verbalize all the reasons why the unsolved issue bothers them, and then say out loud, "having considered all of these consequences of the problem, I find that they're acceptable and it's better to just let this be". Does saying that feel right to them, or does something about it feel wrong? What if they were to say, "having considered all of these consequences of the problem, I find that they're unacceptable and I want to solve the problem", instead? Would that feel right or wrong?
Quick Murphyjitsu. After you've come up with a plan, it may be useful to have the other person do a quick Murphyjitsu on it. How surprised would they be if this plan failed? If not particularly, is there any obvious failure mode that comes to mind and which could be fixed?
Check that the person remembers something actionable. Sometimes discussion may suggest some actionable things, then drift to e.g. more general discussion of the problem which doesn't provide as many concrete suggestions. If this happens, make sure that the person whose problems are being debugged still remembers the actionable suggestions they got earlier on.
A limitation with this approach was that even with these guidelines, newcomers in particular expressed uncertainty of what to actually do while debugging others. I also had the experience that while this kind of a freeform process was occasionally helpful, it didn't seem to help much with some of my own biggest issues - and that some others would likewise repeatedly participate in these sessions, but not seem to make much progress.
A one-sentence description of debugging might be "helping a person make progress on problems they haven't been able to solve yet"; the already-existing fields dedicated to this same issue are therapy and coaching. As it seemed pointless to re-invent the wheel, we adapted the GROW model of coaching as a structured guideline for people to use, and also shifted our language to talk about "coaching" to avoid needless insider jargon. At this point, we also shifted from being mainly in a circle, to mainly being one-on-one.
The following is one of the handouts describing the process that we ended up using, from 2016.
---
(Goal, Reality, Options / Obstacles, Way Forward)
What follows is a recommended baseline model for a coaching session. Its purpose is to support the coaching process, and you should feel free to deviate from it should you feel that it’s necessary. Often this happens naturally: the coachee may find the way forward in the reality phase, or thinking about the current situation may lead you to change and redefine the goal. It’s perfectly fine for you to go back and forth in the steps, turning GROW into something more like GRGROGROOGROWOGORW.
The coachee defines one objective that they want to reach. A good objective is valuable, specific, measurable, achievable, realistic and time-bound. In case the coachee isn’t clear on what they might want, you may discuss their life in general until you come up with something. In general, goals may be related to:
You can also try the following questions:
When you’ve agreed on the goal, write it down here:
What’s the current situation relative to the goal?
At this point, the coach shouldn’t make any suggestions! Rather, the coach should try to understand the coachee’s situation as well as possible. A useful technique is to regularly summarize and rephrase what the coachee has said so far, letting the coachee correct or elaborate as needed.
If there any suggestions that come to mind for the coach, they should write them down for later or try to present questions that test any assumptions that underlie the suggestions.
For example, “this person is unable to concentrate, he should try meditation” assumes that being unable to concentrate in some particular situation is a problem, and that the cause isn’t in the environment. A way to test those assumptions would be to ask what the coachee thinks is behind concentration being difficult, and whether he feels it would be useful to try to do something about it.
When you’re in agreement about the current situation, write down a brief summary that both of you can agree on:
Support the coachee in finding ways to achieve the goal. One good way to do this is to present solution-focused questions. For example:
At this point the coach may possibly offer suggestions, if the coachee seems to want them and be receptive to them.
Write down a few sentences worth of summary of the options and obstacles you’ve found, that both can agree on:
From the different options that you’ve identified, choose one in particular. Decide together the concrete next steps that the coachee will make, and encourage them to define in as much detail as possible where, when, and how they will take those steps. Write this down below.
Before settling on the final results, the coach should ask the coachee, “if an infallible crystal ball told you that your plan is going to fail, what would be the most likely reason?”. See if the coachee would like to modify their plan based on the answer.
This felt somewhat useful, and people did seem to get some benefits, but personally I noticed myself again losing motivation with this kind of an approach. An issue that I frequently had was that I would discuss some issue that I had in a coaching session, think of some possible new approach... and then end up with a pretty high certainty that this too would fail to address the actual problem, even though I couldn't figure out why it would.
Then in the summer of 2017 I ended up stumbling on a memory reconsolidation technique that fixed a large chunk of my problems, while before/afterwards also generally starting to dig more into approaches such as Focusing, Core Transformation, Internal Family Systems, Coherence Therapy, etc., which seemed to be much more effective at digging into the roots of the actual problems.
My general current feeling is that approaches such as debugging and coaching are doubtlessly useful in some specific situations, such as when your problem is mostly just a lack of ideas or knowledge, or not having articulated your goals clearly enough. But my experience is that many (if not most) of the internal problems that a person has are the consequence of specific emotional learnings which the person's mind feels necessary to actively maintain. As such, I find that the most effective approaches for improving people's ability to better their own lives are not generalized approaches such as debugging, but rather specialized protocols aimed at uncovering and changing these emotional learnings: ones found in places such as Coherence Therapy, Focusing, and Internal Family Systems therapy. And since other people have already developed good protocols for those, it seems unnecessary for me to try to re-invent the wheel by developing my own guidelines.
At the same time, as these kinds of approaches may involve going deep into one's emotions and past sources of trauma, I have felt uncomfortable with the thought of running them in public groups with random volunteers, so have shifted to mainly doing one-on-one IFS sessions with friends who express interest in them.