Recognizing vs Generating
Last Updated: 2019-08-29 20:55

In computer science, one of the biggest open questions concerns P vs NP. This question asks whether or not problems that are quickly verifiable are also quickly solvable. For example, checking to see whether 7 and 17 are prime factors of 119 versus actually factoring 119. This dichotomy isn't just academic in nature; it also provides a good starting point for what I regard as the human analogue of this dichotomy--Recognizing vs Generating.

In short, Recognizing tasks rely on your brain's ability to quickly recognize patterns. Generating tasks rely on your brain's ability to put pieces together.

Here is an example of what I want to point to: Say you have an outline, and an essay that was written using the outline as a guide.

You give both items to your friend. "Can you match up the outline to the essay?" you ask. Here, their goal is to see which bullet points on the outline were expanded into different sentences and paragraphs. It's not too difficult of a task.

This is a Recognizing task.

Now, say you give only the the outline to your friend. "Can you use this outline to write an essay?" you ask. Note the difficulty jump. Here, their goal is to actually expand on the bullet points into full sentences and paragraphs, whereas you previously only had to cross-reference.

This is a Generating task.

The difference between these two is like matching up vocabulary words to their definitions versus filling in the definitions yourself. The Recognizing task gives you something to work with, whereas the Generating task requires you to start from scratch. Both are related, but in the above example, it's easy to see that the two aren't the same thing.

The difference isn't always so clear-cut. Here's another example:

A student is reading their textbook, studying for their math exam. They go over the proof in their book. "Does this step make sense?" they ask themselves. They make sure they can follow what's going on before moving to the next step.

This is a Recognizing task.

Now, consider a second student who has the same exam. After reading the textbook, the student closes the textbook and thinks back to the proof. "How did that proof go, again?" they ask themselves. Starting with a blank page, they derive each step. At each step, rather than just following along, they're asking themselves what they need to show next to get to the end of the proof.

This is a Generating task.

When people think about "studying for math", I think both the Recognizing and the Generating task can jump to mind as correct things to do. Indeed, for most conventional uses of the word "lazy", you wouldn't fault the first student as being lazy. Yet, there is a specific type of effort lacking from the first student's approach. However, only the second student's approach is going to help when the test asks for proofs from scratch.

Here, as in many other Recognizing vs Generating dichotomies, it can be easy to trick ourselves into thinking we're putting in more effort than we really are. "After all," the tempting thought goes, "both reading the textbook and writing proofs feel like they fit the definition 'studying', so why can't the easier one work?" The issue is that we're conflating the two definitions.

Overall, this substitution is a clear-cut example of mixing up concept space and action space. We think that just because the tasks are conceptually similar, they must also have similar effects. Or, maybe we do know the difference but some part of us believes that we can do the easier Recognizing task, yet still reap the greater benefits of the Generating task. Either way, this intuitive notion of porting over similarities in other categorical domains is a flawed one.

This is why math can end up being a difficult subject for many people. It’s all too easy to fool yourself that you understand what's going on 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.

In a similar vein, when you’re reading a book and the author says, “Now, obviously, we can conclude X,” this is a sign to pause. You should take a step back and examine what you actually think. If the author hadn’t presented you with the conclusion, could you have generated it with the pieces you already had?

This distinction also occurs in group dynamics. For example, in a group discussion, you’ve probably never had a shortage of people willing to critique ideas that get proposed, but it's less often that you have many people willing to share lots of ideas. From an effort perspective, that makes sense: it’s far 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.

And, of course, it occurs in the realm of self-help: For self-help specifically, I think that there is a tendency for advice to get cached as declarative knowledge, rather than procedural knowledge, in a way which parallels the Recognizing vs Generating dichotomy. Briefly, declarative knowledge refers to things you know how to relate, like Paris being the capital of France. Procedural knowledge refers to things you know how to do, like tying a knot. The issue is that most models in self-help appear to be declarative, but their efficacy lies in their being procedural.

To give a more concrete example: When you first learn about the planning fallacy, this involves concepts together. You learn that the planning fallacy is a cognitive bias, it revolves around underestimation, and that reference class forecasting is a way to help. You learn that reference class forecasting is a method of creating estimations, that it's been successful in public works projects, and that it requires choosing your reference class carefully.

And this is all well and good, if the purpose of learning about the planning fallacy was to do well on an undergraduate psychology exam. You'll be able to answer questions like:

  1. "Does the planning fallacy say we systematically overestimate or underestimate?"
  2. "What does reference class forecasting do?"
  3. "Which researcher discovered the premortem technique?"

In essence, you've built up detailed internal representation of the concept and its related nodes, and background information. But this usually isn't what you want! From a practical perspective, what you want is to be able to put all those concepts into practice, so they actually become useful. This requires finding examples of using the concept and thinking of ways to integrate the concept into your existing schedule. These are questions like:

  1. What is my average underestimation rate?
  2. How do I use past data can I draw from to inform future decisions?
  3. Am I surprised when I don't meet up expected deadlines?

Once again, the questions we care about are also the ones that are harder to answer.

And it's not just planning. This extends to other areas like motivation, habits, procrastination, or meditation; these are all categories where you care about what to do, rather than what it is.

If building a mental map is the Recognizing task, then finding ways to actually have the concepts cash out into actions is the Generating task. And once again, it's harder. In the same way that you get good at tying your shoes by doing it again and again (with feedback), you get better at reference class forecasting by doing it again and again.

This provides strong justification for a meta-self-help framework that often endorses just doing the thing, whatever that thing in question is.

Here is one last extended example:

Consider what happens internally when you give advice to a friend person. Here's what I think roughly happens:

  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!”

As a result, you advise your friend to start with strong handshakes.

But for the person receiving the advice, their immediate reaction is likely to be of a Recognizing sort. They'll ask themselves, "Have I heard advice like this before already?" rather than "How can I see myself using this advice in the future?"

As the person giving advice, just saying the actionable advice without any of the reasons is like jumping straight to the conclusion without any of the supporting evidence. Sure, from inside your head, you have access to all your experiences. So once you hear the generalized piece of advice—”Remember to always start with a strong handshake!”—you can easily verify that it's a good match for explaining your success.

But your friend has none of that. From a Generative perspective, it makes sense to tailor your words such that they cause your friend to also feel the same justification. You want to provide them with the same parts you used to come up with the advice, a way that would make sense for their own gut. You ask yourself, “What information would I have needed in those situations in order to have come up with said action (which I am now offering as advice) 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. 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.

For example, under this model, here are some things you might add/alter to your statement of advice:

  1. Provide additional context: "Now, I know this sounds obvious, and you've probably heard it before, but..."
  2. Explain your anecdata: "Look, here are the situations where it worked well for me..."
  3. Give a puzzle: "Next time you shake someone's hand, try feeling their tension and see what happens." (This might cause the person getting advice to discover that firm handshakes work all on their own.)

All of these strategies might differ in effectiveness, but the important bit is that they take into account how to give information that causes the other person's mind to change, rather than just stating what the change should be.

For humans, I hope I've made the case that Recognizing tasks (i.e. P) are easier than Generating tasks (i.e. NP). As such, if you think that humans are apt to bias towards less effortful options, you'd expect to see many more instances of Recognizing, even if Generating is what produces more useful work. And indeed, I think the several examples provided show that we often default towards Recognizing.

What, then, are the actionables of this dichotomy? Well, the snarky answer is that the Generating view suggests you are better off answering the question yourself, rather than just checking the list I've provided below to see if it's sensible. After all, would this have been the list you yourself would have come up with, had you started from scratch?

Still, if only for myself, I've taken the liberty of including three short actionables below. Here are the things that I think the Recognizing vs Generating dichotomy helps with:

  1. Identify when we're substituting something hard (and useful) with something easy (and less useful).
  2. Gives additional motivation for putting in effort in specific situations.
  3. Provides a theoretical framework for judging what will or won't be an effective way of reaching a goal.