How to help learners develop the subconscious knowledge that is the substance of our understanding

This post is a preliminary attempt to express some ideas about how to teach knowledge.

I imagine these ideas wouldn't always be applicable. To apply them you'd probably need to have a very good grasp on the material you want to teach, and you don't always have that (especially for difficult topics). It also seems like it'd be much more difficult to apply for more abstract knowledge.

Even though this post is itself an attempt to convey some knowledge, it doesn't follow its own dictates, for the two reasons given above.

We can distinguish between subconscious and conscious parts of our knowledge. The conscious parts of our knowledge are the parts you can consciously access. You can interrogate them with introspection, and they're what you can verbalise. There's also the subconscious knowledge that underlies those consciously-accessible details.

Think about what that knowledge enables a person to do. It may let them think about certain topics, draw certain conclusions, solve certain problems and so on. What we can verbally articulate of that knowledge is likely to be a pale shadow what is actually there in our brains that enable us to do all those things. There's a lot of subconscious knowledge that we can't consciously interrogate or articulate.

This subconscious knowledge is a big part of why AI and robotics is so difficult. Sophisticated AI or robotic systems would need to embody such knowledge, but we don't have a good enough grasp on such knowledge to be able to embody it (or much of it) in such systems.

The conscious knowledge, which we can verbalise, seems to "sit on top of" the subconscious knowledge, which is the foundation and main substance of our knowledge.

The subconscious knowledge seems to be what we primarily use when we actually apply the knowledge. When we're applying knowledge we're usually not explicitly thinking it through in verbal terms, and we couldn't verbalise those details if we wanted to.

Our understanding of the conscious knowledge (the knowledge we can verbalise) is grounded in the subconscious knowledge. We can create verbal definitions of concepts that are in our conscious knowledge, but our understanding of those concepts is primarily a matter of our subconscious knowledge. It is notoriously difficult to articulate your understanding of the meaning of concepts.

Despite this, it's easy to think that our knowledge equates to our conscious knowledge. For that's the knowledge that we can access. When we consider our conscious knowledge (for something we understand well), there's no obvious deficits to it. We can define the concepts that form it in terms of other concepts, and these in terms of other concepts, and so on. In this way, we can break down verbal descriptions of the knowledge into simpler and simpler elements. Once we've described the simplest concepts related to the top-level concepts for this bit of knowledge, we seem to have completed the task. Those simplest concepts seem to ground that task of describing the concepts.

But actually, as described above, there is subconscious knowledge underlying our understanding of all of those concepts in that hierarchy. It is because we have that subconscious knowledge that we can look at that description of the hierarchy of concepts in conscious knowledge and understand them. It's because of that subconscious knowledge that there doesn't appear to be anything missing when we describe the conscious knowledge.

Typically, when knowledge is presented in material like lectures, lecture notes, and textbooks, the focus is on communicating the conscious (verbalisable) knowledge. The overarching structure is to define the concepts. Within this structure there may be illustrations (examples) and exercises.

This is a problem because the subconscious knowledge is the substance of understanding. That's what we really want people to learn. Teaching them in a way that's focused around defining concepts is not a good way to get them to develop that subconscious knowledge.

While the person doing the teaching will already have the subconscious knowledge to understand those definitions, the learners will not. That makes it difficult for the learners to learn the conscious knowledge. And it's not what they should be learning in the first place -- the learning should be focused on them developing the subconscious knowledge.

This limitation of the teaching material won't be apparent to the teacher, because they already have the subconscious knowledge that makes the definitions understandable to them. (The distinction between conscious and subconscious knowledge, by the way, explains a lot of "the curse of knowledge", in which someone who understands some material is poor at communicating it because they can't see what it's like for someone who doesn't already understand the material).

But there's an obvious question here. What other option do we have but to try to communicate our conscious knowledge as best we can? By definition, we can't access our subconscious knowledge.

(We can't access it via introspection, nor do have knowledge of it from fields like neuroscience. We don't understand enough about how our brains work. If we were to eventually obtain such knowledge in an area like neuroscience, that might help in developing learning strategies, but it's not like if we could give someone a description of the subconscious knowledge they could learn it by reading that description.)

What I'm suggesting is not that we could or should try to directly communicate the subconscious knowledge. It is that the aim of the teaching should be, first and foremost, to present material to the learners that will best help them develop the subconscious knowledge. And this is not to present them the verbalisable conscious knowledge (definitions of concepts).

Here's how I think we can help people develop the subconscious knowledge.

The key is to recognise that knowledge is a problem-solving tool.

I mean "problem" and "problem solving" in very broad terms. I don't mean just things we'd usually label as problems or problem-solving. I mean that knowledge is there to help us do things. To figure things out, to achieve goals, to understand some issue, to draw conclusions, and so on.

Under the view that knowledge is a problem-solving tool, the bulk of our knowledge, which is the subconscious knowledge, is there for solving problems.

That means, to help learners develop the subconscious knowledge, we need to convey to them what the problems being solved are, and how the knowledge solves those problems.

The problem provides the motivation for the particular bit of knowledge. It lets the learner understand what that knowledge is there to enable. And we can show them how that knowledge solves the problem.

So we should always start with a motivating problem, and then present the relevant concept(s) for solving that problem. We should never introduce a concept without having first presented a motivating problem.

We should start with the most core of the problems and concepts. To do this, we can examine dependencies between the problems (and thus between their corresponding concepts). Those that don't depend on others are core ones. Ones that depend on others are not core ones. There may be multiple levels of non-core concepts.

And, we want to start with the simplest version of each problem/concept, and then progressively add wrinkles (special cases, or exception to the general rules) to those.

We should convey those details through concrete example scenarios that demonstrate the relevant issues we want to communicate (the problem and the means to solve it). And we should use a use a variety of situations to flesh out the learner's picture of them.

After we've demonstrated the problem and solution to the learner, such they have a concrete understanding, we can provide the names for the relevant concepts in that understanding. We should not provide their names until this point. 

It's less of a mental burden on the learner to do it this way. If you present the concept names up-front, the learners need to remember a name for something they don't yet understand.

The goal is to help the learner develop an understanding of the material. Teaching that's focused on concept definitions isn't communicating the bulk of an understanding (the subconscious knowledge). That sort of teaching puts more of a burden on the students' memories. The 'learning' becomes more of a matter of memorising and regurgitating information. The more extreme version of this is the "information dump". And not only is this the way students are taught material, but this broken picture of learning is built-into how students tend to be assessed, as well. So much assessment is oriented around recall of the conscious (verbal) knowledge. Like being able to remember facts and definitions.

If you can teach in a way that focuses on developing the student's understanding, it should put much less of a burden on their memory. Understanding will fix the relevant subconscious details in their heads.

The approach just outlined may seem inferior to the usual approach of describing the verbalisable knowledge (defining concepts).

Compared to presenting concrete problem scenarios first, as motivations for concepts, the usual approach of defining concepts may feel far more orderly, pure, objective and precise. Our approach may seem messier, less objective, and getting less at the heart of the knowledge.

I believe this is an illusion, that primarily comes from equating knowledge with the consciously-accessible, verbalisable knowledge. If you think knowledge equates to defining concepts, then defining concepts will appear to be how we should teach knowledge. But if you think that knowledge is primarily the subconscious knowledge, then we see the task differently.

Here's a brief example outlining how these ideas could be applied. It's not an example of the actual teaching material we'd present, but a high-level description of what such teaching material would contain.

This example concerns teaching people about relational databases. Unfortunately, if you're not familiar with relational databases, the following might not make a lot of sense. I chose them as a topic because they're something I have a bit of familiarity with, with respect to teaching about them.

The first thing we'd do is determine how 'core' each of the problems (and associated concepts) are. We'll use this information to determine what order to introduce them to the learners. We want to start first with the most core of the problems.

The most core problem that databases address is storing information. There's retrieving information, but first of all you need to store the information. And the most core problem to do with storing information that relational databases are designed to address is to do with unambiguous identification of information and the associated issue of redundancy of information. 

So we would start with some example scenarios that concretely demonstrate these problems. I'll go into some details of this in a moment.

After those problems associated with storing information, the next most core problem is that of retrieving information. Like of wanting to get different sorts of 'answers' about what is there in the stored information.

Retrieving information is less core than the first problem of dealing with redundancy, as the first problem has to do with storing the information, which needs to be done before we can retrieve information.

Perhaps the next most central problem is the need to be able to design a database to fit some situation. The sorts of situations we might face, and how we want to develop a design that avoids the redundancy potentially present in the information there.

Then there are many less core problems, associated with various more advanced or specific details that could be gone into after those.

(As an example of more specific details, in relation to database design there is the point that the abundance of Nulls in a table often indicates poor design. For the motivation for this we would provide an example demonstrating the issue. There's also issues like efficiency, accessing database information from within programs, security, and so on).

Now that we've determined how core each of the problems (and their associated concepts are), we know what order to present them to the learners, and we can figure out the details of how to present them. In the following, I'll go into more detail about how we could teach the knowledge associated with that first set of core problems, to do with storing the information. I won't go into similar detail for the other problems.

We could start by giving some example scenarios of information that may be stored. I.e. we would write down some of the information that might be stored. One of these might be information that a shop keeps about customers' purchase histories.

Then we would introduce the relevant concept names, like 'entity', 'field', 'table', and 'columns'.

We could give a couple more illustrations to help reinforce the concept names.

Then we could give some example scenarios that demonstrate the problem of being able to determine which real-world entity some information is about.

There could be an example of where there's customer information and where there's issues of determining which actual person the customer information is about.

For example, there are entries about customers and their purchases, which have the following customer names:

- Edward Henderson

- Ed Henderson

- E Henderson

it could be that the one employee added all of these bits of information, and they remember who these entries refer to (perhaps they all refer to the same person). But maybe they will forget these details in a few months. Or maybe a different employee is looking at the data and trying to figure out who each of those entries refers to. Is it the same person, or different people?

Being able to determine which person the information is about is important for being able to find all the information about a particular person. That may be just to see that information, or it may be for if we need to change that information (e.g. if that person decides to change their name, and we want to change all occurrences of their name that we've stored) or something associated with it.

Then we can give example scenarios demonstrating that, by ensuring that all entities have a unique identity, these problems are avoided. We can illustrate some of the different ways entities can have unique identity (e.g. a combination of existing fields they might have, or giving them a new field like an identification number).

Then we can illustrate why it is that information about the same entity may occur multiple times in the information we've stored.

In our example we can see it's because the one customer may make multiple purchases (on different days). So we record information about that customer for each of those purchases.

We can give other examples to show that each time an entity occurs multiple times, it's because it is related in some way to multiple instances of some other kind of entity (e.g. if a library tracks all the book borrowings of a person, that person will occur once for each borrowing).

After having illustrated this concept, we can introduce the name 'one-to-many relationship' for it.

We can present scenarios that demonstrate that where there's one-to-many relationships and there's duplication of data (like if for each purchase we stored the customers first and last names and postcode) we run into problems similar to the ones we mentioned at the start where the person's name was entered multiple times and potentially spelled in multiple different ways. Difficulties in finding all the cases you want, and in updating them, and where errors can be introduced.

Then we can show examples illustrating how this problem can be addressed by having a separate table for the 'one' entities (like customer), where all the information about the 'one' entities is stored. We've established that each entity should have unique identifier (say that each customer is given a 5 digit identifier). Thus we can just include this identifier in the 'many' table (purchases) and not have to include any other information about the customer in the purchases table.

So the only customer information that gets duplicated is its identity. The identity is something that shouldn't change, so we don't have the issues of needing to make changes to all occurrences of that same information (but even still, since it is unique, we can have the software easily find all instances of it and thus change them if we needed to).

Once we have a table that's just for the 'one' entities (in one-to-many relationships), the computer software can do things automatically for us

• check that each entity has a unique identity (and not let us add one that doesn't have a unique identity)
• check that a reference to an identity (in a 'many' table) is to one that actually exists (actually, and also that it's of the right type of entity, as we'll get to).
• we can also set up the software to automatically create a unique identity (like an ID number) for new entities 

(Having a separate table for the 'one' entity in a 'one-to-many relationship' creates issue of having to cross reference the customer table if we're looking at a purchase and want to find out details about the customer (like their postcode), which adds some complexity, but later we'll see how the software can automate this).

After having illustrated these details about identities, and referencing identities where there's one-to-many relationships, we can introduce the following names for the concepts

- primary keys (what uniquely identities entities)

- foreign keys (the references to these entities)

To reinforce the understanding of these concepts we've just named, we would then further illustrate them with examples.

.

Related: Being able to explicitly reason about a concept is a skill. That post argues that learning how to reason about a concept is learning a skill, which means it requires practice. That relates to the present post in that when you provide the concrete scenarios presenting the problems and how the concepts can be used to solve them, you want to present multiple varied scenarios such that the learner can practice seeing things in these terms. And you'd want to give them exercises to do along the way, and feedback, as well.