There’s a programming technique where you keep a rubber duck on your desk, and when you run into a confusing bug, you try to explain it to the duck. This turns out to be surprisingly useful for resolving bugs.

In research conversations, it is often very useful to have someone serve as an upgraded rubber duck. This is a support role: the rubber duck’s job is not to solve the problem, but to help their partner sort out their own thoughts. Playing this support role well is a skill, and if you’re good at it, you can add value to other researchers in a very wide range of contexts; you can be a general-purpose force multiplier. This post contains a handful of tips for how to add value this way, beyond what a literal rubber duck has to offer.

Figure Out The Picture

My partner is drawing a picture in their head. I want to accurately copy that picture into my head. This is the core of the technique: in order to build an accurate copy in my head, my partner will need to flesh out the picture in their own head.

For sake of discussion, let’s say the conversation is part of a conjecture workshop. The goal is to take some fuzzy intuition and turn it into a mathematical conjecture. When playing the support role, I’m trying to build a mathematical conjecture in my head which matches the picture in my partner’s head. By asking questions to fill out my picture of the conjecture, I push my partner to translate their fuzzy intuitions into math.

(We’ll use conjecture workshop examples throughout this post, but the ideas generalize beyond just math.)

Some useful lines:

• Can you give an example?
• Can you give 2-3 examples which are as different as possible?
• Can you give an anti-example, i.e. a case where this would not apply?
• Here’s the picture in my head so far. <explain> Does that match what’s in your head? Am I missing anything important?
• Let me repeat back what I understood from what you just said. <explain> Did I miss anything?
• We’ve been using the analogy of X. How does Y translate into that analogy?
• It seems like you’re trying to point to X. Is that right?
• Here’s a few different things which I think you might be trying to point to. <explain> Is one of these what you’re saying? Do none of them match what you’re trying to say?
• Am I understanding your framing correctly?

Side note: since this all relies on building out a picture in my head, it might be useful to write down some parts of that picture, in case my own working memory fills up.

Don’t Draw The Picture

I don’t want to accidentally draw anything in my copy which isn’t in my partner’s picture. And I extra-especially don’t want to overwrite their picture.

For instance:

Partner: I want to say something like [...]

Me: Ah, this is just like Person’s Theorem! We formulate it as [...]

The problem with this is that we’re now talking about what Person’s Theorem says, which may or may not actually match the fuzzy thing in my partner’s head. And it’s a lot easier to latch onto a theorem which has already been figured out, than to figure out the right way to formulate fuzzy ideas. While having this kind of conversation, the goal is to fill out the picture in my partner’s head, not to replace it with some other picture.

But do make a note to talk about Person’s Theorem later! It may still be useful to just use the Person’s Theorem picture later on, even if bringing it in right now would undermine the conversation.

(Why is it so important to flesh out the original picture, rather than adopt a different one? Well, my partner expects their intuitive picture to apply/generalize in some useful ways; that’s why it’s interesting in the first place. If we replace it with a new picture which may-or-may-not match, then the intuitive reasons to expect it to apply/generalize usefully may-or-may-not carry over, especially if they're not very legible. It’s the same reason why we want to avoid ad-hoc mathematical definitions.)

Depending on how firm a grasp your partner has on their own idea, you may need to exert more or less effort to avoid accidentally overwriting their picture. Anchoring can be an issue - if you say “I’m imagining this as a set of vectors and a distance metric…”, then it may be hard to think up a new frame later. On the other hand, if your partner already has a firm enough grasp to say “no, that’s not quite right”, then figuring out exactly how set-of-vectors-and-distance-metric isn’t right can be a very useful step. So there’s a balance to be struck between making suggestions which fail-to-match your partner’s picture in instructive ways, vs not accidentally overwriting the picture.

Some sometimes-useful lines:

• I’m imagining this as X. In what ways does this not match your picture?
• I’m currently thinking of this as X, but I’m not sure that’s exactly what you’re pointing to. Can we come up with an example which does not look like X?
• This makes me think of the setting for Person’s Theorem, where we assume X, Y, Z. How well does that match what you’re imagining? How does your thing differ?

As always, remember that your partner may just want to frame things differently, but may not know to call their vague feelings of unease a “framing problem”. And make sure to give your partner space to explain their picture in their own words starting from their own reference points - “how does this differ from X?” is sometimes useful, but it’s not something you should be asking constantly.

The above lines are also useful for “offering help” - i.e. if you think you know the next thing your partner “should” add to their mental picture. You can say something like “It sounds like you’re trying to say X; how well does that match what’s in your head? Where does it differ?”. If your partner gets stuck, this is a good way to help while still being careful not to overwrite the picture. Again, though, try not to do this too often.

Don’t Solve The Problem

Finally, the “hold off on proposing solutions” rule is in force for the entire conversation.

These sorts of conversations usually revolve around how to frame some problem, theory, conjecture, hypothesis, etc. Trying to solve the problem, prove the conjecture, test the hypothesis, etc, will most likely lock in whatever picture you and your partner currently have, and prematurely end the drawing process. At that point, you have moved to an entirely different conversation.

That said, it may still be useful to talk about certain “solution” techniques in order to clarify the problem. Some sometimes-useful lines:

• It sounds like the sort of problem which could potentially be solved by X. Does that match your intuition?
• If I’m understanding this correctly, then if we did X we’d expect to see Y. Is that right?
• It sounds like this idea would be implied by X?

When using these, be careful to emphasize that the point of bringing it up is to better understand the picture, not to solve the problem or test the theory. If your partner starts to dive into the details of the “solution”/"test”, gently remind them that you haven’t yet built a complete picture of the problem/theory in your head.

Summary

My partner is drawing a picture in their head. I want to accurately copy that picture into my head. The process of copying the picture into my head will hopefully push my partner to fill out the details of the picture, in much the same way that explaining a programming problem to a rubber duck helps flesh out one’s own picture of the problem. And unlike a rubber duck, a human can add a lot more value - I can notice places where the picture seems incomplete, places where I don’t understand what’s going on and therefore places my partner might not yet have fleshed out the idea.

Playing this support role is a skill, and someone who is good at this skill can act as a general-purpose force multiplier, adding value in a wide variety of contexts, especially in research.