by [anonymous]
5 min read14th Jul 20183 comments

15

[A distinction to be aware of is when a task requires you to Recognize (i.e. verify, note, observe, etc.) something versus Generate (i.e. brainstorm, create, compose, etc.) something. These tasks can seem quite similar, but I claim that Recognizing is both easier and less valuable. Three examples are provided, followed by an extended example on giving advice.]

Here’s a useful dichotomy that I think is applicable to a variety of cognitive tasks. It’s the distinction between Recognizing and Generating. The words by themselves don’t explain too much, so here are some examples:

Say you’re writing an essay. You start off with a bullet point outline where you jot down some of your half-formed ideas. Then, you use the outline to write your actual essay, expanding upon the bullet points titled things like “Intro Stuff”, “Ending Hook”, and “Insert stuff about their connection” into actual sentences and paragraphs.

Now, you hand the outline and the essay to your friend. “Can you identify which parts of this outline map onto the essay itself?” you ask them.

It’s not too difficult of a task. With the outline in hand, your friend can probably break up the essay into rough chunks where you expanded upon the bullet points.

But, now, say that you only hand the essay to your friend “Can you use this essay to regenerate the outline that I originally used for this essay?” you ask them.

Now, it’s a lot harder. It’s not just working backward or doing things in a clear cut manner. Your friend could come up with lots of plausible outlines, but there's only one of them that is the one you used.

In the first scenario, your friend merely needs to recognize which parts of the essay map onto the outline. In the second scenario, your friend has to generate the entire outline.

This, in a nutshell, is the core distinction in the Recognize vs Generate dichotomy.

Another, perhaps simpler example, is checking vs coming up with math proofs. It’s a lot easier to verify that a proof is correct than to have the ingenuity to come up with the proof in the first place.

I also think this is why math ends up being a difficult subject for lots of people. It’s all too easy to fool yourself that you understand a certain subject when you’re just following along with the textbook. Cover up the steps, though, and try to solve the problem yourself, and things get a lot harder.

Lastly, a more general example of this Recognize vs Generate distinction has to do with coming up with ideas. If you’ve ever been in a group discussion, you’ve probably never had a shortage of people willing to critique ideas that are proposed. But having a steady stream of ideas proves to be harder.

Once again, I think the distinction is at work here. It’s far more easier to point out why an idea is bad (after all, basically every plan will have drawbacks!) than to come up with ideas in the first place. This isn’t to say that criticism isn’t important, but I do think it’s important to acknowledge this asymmetry in effort that’s being put in by both sides.

I think that one of the most useful ways to use this distinction is when people give advice:

Pretty much all advice people give falls into the Recognizable category, when they should really be thinking in a more Generating style.

Here’s what I think roughly goes into people’s heads when they try to give advice into another human:

1. Think of several experiences where things turned out well for them.

EX: “That time I won the free laptop, that time I scored the awesome job, and that time that I asked Andy to the dance.”

2. Try to find some common threads between all of the experiences.

EX: “Well, I did always start with a good impression, I always introduced myself well in all of those times…”

3. Distill it into something general. Give it out as advice.

EX: “Remember to always start with a strong handshake!”

So your experienced friend, hoping to impart some worldly advice, tells you to always start with a strong handshake. And that advice promptly gets filed under your “Boring Advice” drawer in your head, never to be seen again.

I think that the core problem here is that your friend hasn’t done a good job of accurately conveying the reasons for the advice given.

From inside their heads, they have access to all of their experiences, so once they’ve got the generalized piece of advice—”Remember to always start with a strong handshake!”—which they can check against their memories to verify if it’s a good match.

They’re able to quickly Recognize that the advice checks out.

But, for you, the advice-getter, you don’t have access to any of those experiences.

So the best you, the advice-getter, can do is imagine a few situations where the advice kinda works out, and it’s not at all as convincing and obviously “good” as the advice-giver thinks it is.

I think that advice becomes far better when you start taking a Generative approach towards things.

Now, instead of looking for common threads, you ask yourself, “What information would I have needed in those situations in order to have come up with those positive actions in the first place?”

Rather than checking to see if your outcomes match the advice you give, you’re now actually checking to see if the advice you give even leads to those outcomes in the first place.

Which is great because it better aligns your thinking with that of the advice-getter’s. It means you’re thinking about what they do and don’t know. Which means you’re less likely to fall prey to the illusion of transparency, the cognitive bias where we assume that everything we know is also known by the other party.

There’s a certain sense here where you’re modeling humans as complicated input-output machines, and you’re trying to see what sort of input would generate the best outputs. The Recognizing vs Generating distinction applies this as an abstract model overlaid many things in life.

If we turn this back to the handshake example, an attempt to be more Generative might look like this:

Your helpful friend tells you, “Hey, so whenever you meet someone, you should definitely check out the hills and valleys of their hand. It’s totally groovy!”

Now, your curiosity is piqued. What do they mean, the "hills and valleys"? The next time you meet another human, you squeeze their hand, trying to figure out where those fingered landmarks are. To your surprise, they respond to your tight grip with praise, (“Hey, nice handshake!”) and the rest of the meeting goes swimmingly well.

As a result, you think to yourself, “Gee, it turns out that handshakes are pretty great when they’re firm!”

This is undoubtedly a silly toy example, but I hope it illustrates how a large part of advice is letting the other person figure out the actual advice for themselves. I think this type of Generative attitude forms one of the pillars of good pedagogy. It's why it can be good to encourage students who have part of the correct idea, if it seems likely they'll self-correct onto the right path themselves. If they arrive at the insight themselves, they'll likely value it more as well.

There are, of course, other ways of giving good advice, from going meta (EX: acknowledging that the advice sounds boring and/or obvious but it's still useful), finding ways to quickly shift intuitions (EX: telling a memorable anecdote), to bridging the differences in experience (EX: give more background information / an improved model).

In general, taking note of this dichotomy means we want to avoid the surface-level similarities of what, at their very core, are quite different activities. Generating is often a lot more effortful, but it is also often a lot more valuable.

New to LessWrong?

New Comment
3 comments, sorted by Click to highlight new comments since: Today at 12:35 PM

This is pretty much the P vs NP problem. Finding an input that makes some program return true is, most likely, exponentially harder than checking that the program returns true on some given input. The exponent is the running time of the program. To take a strawman example, if you have a recognizer that takes 10 seconds to tell you if an input is suitable, you might be able to generate a suitable input in an hour. Then you add some complexity to the recognizer so it takes 11 seconds instead of 10, and find that the generator now takes 2 hours. Adding another second to the recognizer will lead to 4 hours in the generator, and so on. The work required from the generator grows as an exponential of the work done by the recognizer, unless the recognizer is of a special kind which allows fast generators.

It's especially noticeable when you try to write fiction, compose music or make a video game because you feel like you're so good at appreciating them. You quickly realize that, even though your recognizer works well, using a trial-and-error generator is futile. The only solution is to hope that your recognizer is of a special kind, and you can build a fast generator for it. That's known as creativity. And then it leads to changes in your recognizer, a.k.a. your taste improves, and you start all over again.

[-][anonymous]6y20

Oh, right, yup. The P vs NP analog is a very good parallel.

Great mental model to have :) I wonder if this is parallel to the "Diverge" / "Converge" mode of design thinking or something in another dimension. For now, I think it is in another dimension, where one can be in Flare/Diverge mode of design thinking but be generating/recognizing and similarly, even within Focus/Converge mode, one can be generating or recognizing.