The Problem Creates the Appetite

Most learning paths are designed from the teacher’s point of view.

If you already know the subject, the sequence feels obvious. First variables. Then loops. Then functions. Then data structures. Then APIs. Then databases. Each concept builds on the last. It is clean, efficient, and defensible.

But that is not always how the learner experiences it.

To the learner, the early stages can feel like being handed parts for a machine they have never seen. They are told each part matters. They are told it will all come together later. Sometimes that works. Sometimes they just memorize pieces without understanding why they should care.

There is another way to learn: start with the thing you want to make.

Build the bad version first. Hard-code the cards. Put the data in the wrong place. Feel the pain of your own shortcut. Then, when someone introduces JSON, local storage, APIs, or databases, those concepts are no longer abstractions. They are relief.

The problem creates the appetite for the concept.

---

Push and pull

The useful distinction is not bottom-up versus top-down. It is sequence of knowledge versus sequence of need.

Push learning is sequence-of-knowledge learning. It starts with the map. Here are the concepts. Here is the order. Trust the path.

Pull learning is sequence-of-need learning. It starts with an objective. I want to build this. I want to understand this. I want to solve this. The next lesson appears because the problem demands it.

Push learning says: here is the map, now walk.

Pull learning says: start walking, then the map becomes meaningful.

Neither mode is inherently better. The timing matters.

Fundamentals are not bad. Fundamentals are powerful. But they land hardest when they answer a question the learner already has. If they arrive too early, they can feel like trivia. If they arrive too late, the learner thrashes. The art is matching the concept to the moment of need.

This is why the same lesson can feel dead in a course and obvious in a project.

You can explain databases to someone for an hour and watch their eyes glaze over. Or you can let them build a tiny app, lose all their data on refresh, try local storage, realize it only works on one machine, and then ask: “How do I make this real?”

Now the database has a job.

The kanban board problem

Programming makes this easy to see.

The traditional sequence goes something like this:

1. Learn variables.
2. Learn loops.
3. Learn functions.
4. Learn data structures.
5. Learn APIs.
6. Learn databases.
7. Build something.

That order is logical if you already understand the destination.

But a learner might experience a better first loop like this:

1. I want to build a little kanban board.
2. I hard-code three cards in HTML.
3. This is annoying. I need the cards represented as data.
4. I move them into an array.
5. This resets every refresh. I need persistence.
6. I use local storage.
7. This only works on one machine. I need a server or database.
8. Now databases are not abstract. They answer a pain I have actually felt.

The first path is efficient for instruction. The second path is legible to the learner.

That does not mean the learner should be left alone to discover everything from scratch. Pure discovery can be wasteful, especially for beginners. Kirschner, Sweller, and Clark make this point in their critique of minimally guided instruction: novices often need structure, examples, and direct teaching.

I agree with that.

Pull learning is not the same as abandoning guidance. The strongest version is guided pull learning: start with a real problem, let the learner feel the gap, then provide timely instruction.

The point is not “figure it out yourself.”

The point is “now you know why this matters.”

Push expands the aperture

The problem with pull learning is that it depends on the problems you encounter.

That is fine if you are constantly pushing yourself into harder territory. Ambition creates the curriculum. A bigger goal exposes bigger gaps. If you are trying to build something you do not yet know how to build, the next lesson keeps appearing.

But if your environment is static, pull learning slows down. You only learn what your current problems demand. You become better at the work already in front of you, but you may not discover the work that could be in front of you.

This is where push learning matters.

Sometimes you need to be shown what is possible before you know to want it. You need to see the demo, read the essay, watch someone work, take the course, or hear the story. That kind of learning expands your aperture. It gives you new ambitions, and those ambitions create new problems.

This has happened to me repeatedly with software, writing, and company building.

I have had ideas I did not know how to express until I read someone else’s sharper version of the pattern. I have watched a product demo and immediately seen a new workflow I wanted to try. I have listened to someone describe how they operate and realized my own standard was too low.

That is push learning at its best. It is not passive consumption. It is exposure that changes what you can imagine doing.

The danger is that it can become performance.

You can spend years consuming knowledge without converting it into capability. You can become fluent in the language of a domain without being able to do anything meaningful inside it. You can feel busy, informed, and intellectually alive while avoiding the one thing that makes learning real: application.

If learning never moves into action, it becomes inventory.

And a lot of people are not learners as much as digital course collectors.

They are not lazy. They are often deeply curious. But curiosity without application has a ceiling. It can make you feel informed without making you more capable. It can make you busy without making you more valuable. It can make you feel like you are growing while your ability to create impact stays mostly unchanged.

Pull creates the appetite

Pull learning has the opposite strength.

It gives knowledge a job.

You are not learning databases because a course told you databases are important. You are learning databases because your kanban board has outgrown hard-coded cards and local storage. The concept arrives with a purpose. That makes it easier to understand, easier to remember, and easier to value.

This is why problem-based learning, productive failure, experiential learning, and constructionism all rhyme with the same truth: experience changes the way instruction lands.

When learners wrestle with a meaningful problem first, the later explanation has somewhere to attach. Manu Kapur’s work on productive failure is useful here. The struggle is not the point by itself. The struggle prepares the learner to understand the formal lesson more deeply.

That maps to how a lot of real growth happens at work.

You do not fully understand strategy until you have watched a team execute without one.

You do not fully understand positioning until you have tried to sell something people misunderstand.

You do not fully understand process until the absence of process starts costing the team.

You do not fully understand leadership until the work depends on people who do not report to you.

The concept becomes real when it resolves a tension you have actually felt.

Learning style is not an excuse

People tend to have a default learning posture.

Some people are problem-led. They need a concrete goal before the learning feels alive. They can read about concepts forever and nothing sticks, then hit a real problem and learn three months of material in a weekend.

If this is you, your danger is stagnation in the absence of problems. You need to manufacture problems on purpose. Set ambitious objectives. Build things. Take on projects that force you into new territory. Your growth depends on creating enough meaningful friction.

Other people are content-led. They love ideas, frameworks, courses, books, lectures, and essays. They are good at absorbing the map.

If this is you, your danger is mistaking understanding for ability. You need a bias toward application. For every new idea, ask: where can I test this? What would I do differently this week if I believed this? What artifact, decision, conversation, workflow, or project should change?

Neither type is better. But each type has to borrow from the other.

Problem-led learners need push mechanisms to expand what they know to want.

Content-led learners need pull mechanisms to force knowledge into use.

The point of understanding your learning style is not to give yourself an excuse. It is to notice where your default mode makes you strong and where it lets you hide.

The danger is not having a default.

The danger is surrendering to it.

Capability is the output

Instead of asking “What should I learn?” ask:

What am I trying to become capable of doing?

That question changes the unit of learning from information to capability.

If the goal is “learn databases,” you can finish a course and still not know when or why to use one. If the goal is “build an app whose data persists across devices,” the database becomes part of a capability. It has a job.

This is especially important for career growth. Your market value does not rise because you consumed more information. It rises because you can do more valuable things. You can solve harder problems. You can see around corners. You can make better decisions. You can build, sell, lead, automate, design, communicate, or operate at a higher level.

Learning is not the output.

Changed capacity is the output.

The healthy loop looks like this:

1. Exposure expands what you believe is possible.
2. Ambition turns possibility into an objective.
3. Friction exposes a gap in your knowledge.
4. Instruction gives you the concept, teacher, tool, or pattern you need.
5. Application turns the lesson into capability.
6. Reflection helps you notice what new problems are now visible.

Push expands the aperture.

Pull creates the appetite.

Application turns both into capability.

Capability creates impact.

Three useful practices

First, keep two lists.

Most people keep a reading list. That is not enough. Keep a possibility list and an ambition list.

The possibility list is for things that expand your aperture: examples, demos, essays, tools, ideas, people, workflows, and projects that make you think, “I did not know that was possible.”

The ambition list is for things you might actually try to do: build a small app, write a memo, automate a workflow, pitch a new idea, improve a process, learn a tool well enough to ship with it.

The bridge between push and pull is moving items from possibility to ambition.

Second, convert every course into an artifact.

Before you start a course, decide what artifact will prove the learning happened. Not “finish the course.” Something real: a working prototype, a published essay, a new workflow, a decision memo, a better dashboard, a recorded demo, or a conversation you can now lead.

If there is no artifact, the course is probably entertainment or exploration. That is allowed. Just call it what it is.

Third, end every week with one question:

What can I do now that I could not do last week?

If the answer is nothing, you may have been busy, but you were not in a learning and impact loop.

Then ask:

Where did that new capability create value?

That second question matters. Capability is not just internal confidence. It should eventually show up in the world: a better decision, a faster workflow, a clearer argument, a stronger product, a more useful conversation, a shipped artifact.

The standard

The best learners are not purely curriculum-led or purely problem-led. They build a loop.

They expose themselves to new ideas, not to collect them, but to increase their ambition. They choose goals that create friction. They use that friction to pull in the right instruction at the right time. Then they apply what they learn in a way that changes their capacity.

That is the standard that matters.

Not “Did I finish the course?”

Not “Did I understand the concept?”

But:

Can I now do something I could not do before?

And, eventually:

Did that new capability create impact?