Prescriptions

If you think you have more procedural knowledge than declarative:
- use the Feynman technique (ideally once per day for a few days) and
- read other people’s exposition when you get stuck.
If you think you have more declarative knowledge than procedural:
- work problems (ideally with clear solutions) and
- generate concrete examples for yourself.

Rationale

In whales’ excellent Book Review: How Learning Works, each one of the 7 Principles gets expanded upon with a “Research consensus”. In the first principle, discussing how prior knowledge affects a students’ learning, they write:

Declarative knowledge (object-level concepts) and procedural knowledge (how and when to apply those concepts) do not always go hand in hand. One without the other is a knowledge gap that can be tricky to spot, especially in self-assessment.

(Emphasis whales’, not mine.)

I’ve noticed this to be an especially useful asymmetry to keep in mind myself, since a lot of what I do is filling one, then using that to bootstrap the other. So I thought I would share my two “prescriptions” for it.

They’re nothing groundbreaking, but they might help someone who’s stuck in a state of analysis paralysis decide what to do next.

EDIT: The Feynman technique and a variant

My apologies, I thought this was a little better known than it was. To summarize very quickly, the Feynman technique is where you

Sit down with a piece of paper (or whatever “thought->thing” tool you prefer);
Write down the concept you want to build declarative knowledge on first;
Start to write out an explanation of the concept, as if you were explaining it to a generally intelligent layman, who doesn’t know most of your fancy words;
and any time you have difficulty explaining in plain English what you’re talking about, you pinpoint that as a gap you need to build declarative knowledge on further.

That was all taken from this helpful link from commentator habryka below. (Thanks!) Let me add a bit of my own value, by suggesting a variant for people with a lot of “know-how”.

Pick a problem and write that at the top of the page.
Start to work through the problem, but at each stage, pause and write a plain-English explanation of what you’re doing here.
- It’s a little more forgiveable to use jargon here, but you should try to explain whatever jargon you use in plain English as well for the first time you use it in solving the problem, and then relate it back to why that particular concept is importnat here.
Again, any place you have difficulty, that’s a gap you need to hit the books on specifically.

This might be a little easier if you’re really in the weeds, so to speak. It can be difficult to just pick “a concept” and run with it without motivating examples; here, you invert the process, and use an example to find concepts to explain.

Personal examples

(You can probably safely skip this, if you have more important stuff to do.)

Matrix multiplication (declarative > procedural)

I used to have trouble remembering how to do matrix multiplication by hand. (I think this is very relatable!) I have a lot of declarative knowledge about what matrices “really” are, linear transformations and all that, but I lacked the practice to effectively turn that into procedural knowledge.

To fix this, I generated concrete examples to practice. Specifically, I wanted examples I could do in just a few seconds of mental calculation, and that I could throw into Mnemosyne, using its LaTeX formatting; so I wrote a Python script to generate a bunch of very easy, random matrices and ask me for the value of their multiplication at a specific row.

That allowed me to make a Tab-Separated Value text file of 50 such cards I could import in to Mnemosyne, which would give me more than enough practice and retention to never have to worry about the skill again.

Circuit analysis (procedural > declarative)

In the days leading up to my final exam last quarter, I realized that while I had a pretty good sense of what to do by hand when analyzing an electronic circuit with an AC power source, I had very little ability to explain why that was the way it was. I had procedural knowledge, but I was lacking in declarative knowledge.

I sat down about a week before the exam, and used the Feynman technique—I tried to explain back to myself (for example) why and how we did things using complex numbers instead of the “raw” real functions. When I couldn’t generate the explanation myself, I went back to my textbook and read through theirs.

The next day, I got a new sheet of paper, and tried again. This time it went much smoother. I began to push my reasoning abilities, with questions like:

Why is Δ an important assumption for technique α?
How does α break if Δ can’t be assumed?
How would we deal with case χ, where α starts to become more complicated?
- Is there a better technique β I could use instead?

Where I wasn’t sure, I tried α or β and if I got the right answer I’d mentally class it as “leaning towards correct”. But the final litmus test was always to take a technique that spat out the correct answer and explain why it had to be so. (Come to think of it, it’s a similar epistemic style to proof writing, which as we all know is a skill in itself!)

I did this each day leading up to the exam. And by the time the exam came around, I felt like not only did I know how to do the problems I saw, but I also understood deeply why we solved them these ways. That turned out to be useful, because the exam threw much harder problems at us than I expected. Being able to verbalize the logic behind the operations made it much easier for me to spot bottlenecks where I could solve simpler problems that would compose upwards into a full solution, so I was still able to breathe somewhat easy.

Two prescriptions for fixing a procedural/​declarative knowledge mismatch.