Start With the Problem, Not the Language#

I’m not a programmer. I’ve never taken a computer science course. I can’t explain the difference between a stack and a heap. But two years ago, I needed a website — a simple portfolio site to display my photography — and I didn’t want to pay someone $2,000 to build it.

So I built it myself. It took about eighteen hours spread over two weeks. It’s not beautiful. The code, if a professional saw it, would probably make them wince. But it works. It loads fast. It shows my photos. People can contact me through it. It does what I needed it to do.

I didn’t learn to code. I learned to solve a specific problem that happened to require code. That distinction — problem-first versus skill-first — changes everything about how fast you can cross the threshold.

Two Ways to Learn: Systematic vs. Demand-Driven#

Most formal learning is systematic. You start at the beginning, move through the middle, and arrive at the end. Chapter 1 before Chapter 2. Fundamentals before applications. Theory before practice.

Systematic learning has real strengths. It’s thorough. It builds a solid foundation. It ensures you don’t miss important concepts. If you’re training to be a professional — a surgeon, a structural engineer, a commercial pilot — systematic learning is essential. Lives depend on comprehensive knowledge.

But you’re not training to be a professional. You’re trying to cross the competence threshold in twenty hours. And for that goal, systematic learning is often the slowest possible route.

The alternative is demand-driven learning. Instead of asking “What should I learn first?”, you ask “What do I need to accomplish?” Then you work backward from the answer. You learn only what the accomplishment requires. Everything else waits.

Demand-driven learning is not a shortcut. It’s a different direction. Systematic learning walks the entire map. Demand-driven learning draws a straight line from where you are to where you need to be.

Define the Problem Before You Learn Anything#

The demand-driven approach starts with a single, non-negotiable step: define your problem. Clearly. Specifically. In writing.

Not “I want to learn photography.” That’s a domain, not a problem.

Not “I want to take better photos.” That’s a vague aspiration, not a problem.

Try: “I want to take well-lit, properly exposed photos of my products for my online store, using my phone camera and natural light from my apartment window.”

That’s a problem. It has boundaries. It specifies the tool (phone camera), the subject (products), the lighting condition (natural light, apartment window), and the quality standard (well-lit, properly exposed). Those boundaries tell you exactly what to learn and — critically — what to ignore.

With that problem defined, you can immediately eliminate entire branches of photography knowledge: you don’t need to learn about studio strobes, landscape composition, portrait posing, night photography, film processing, or lens selection. All of that is interesting. None of it is relevant. Not right now.

The Problem Definition Template#

For any skill you’re approaching, fill in this template:

What specific outcome do I need? (Be concrete. “A working website” is better than “learn web development.”)
What tools or constraints do I have? (Budget, equipment, time, existing knowledge.)
What does “done” look like? (How will I know the problem is solved?)
What is explicitly out of scope? (What am I deliberately not trying to do?)

That fourth question is the most important. Scope is the enemy of the twenty-hour learner. Every topic you add to your learning list dilutes your focus, extends your timeline, and increases the chance you’ll stall before crossing the threshold.

Define the edges of what you’re not doing. That’s where your speed comes from.

The Story of Tomás and the Spreadsheet#

Tomás ran a small landscaping business. He tracked his clients, invoices, and schedules in a paper notebook. It worked, but it was slow. He’d lose track of who owed what. He’d double-book Saturday mornings. He wanted a better system.

A friend suggested he learn to use spreadsheets. Tomás looked at an Excel course online. It had 47 lessons covering pivot tables, VLOOKUP, conditional formatting, macros, charts, data validation, and keyboard shortcuts. The course was 12 hours long.

Tomás didn’t have 12 hours to spare. He had a business to run. And he didn’t need pivot tables. He needed three things:

A client list with names, addresses, and phone numbers.
An invoice tracker showing who paid and who didn’t.
A weekly schedule showing which jobs were booked on which days.

So instead of taking the course, he opened a blank spreadsheet and typed his first client’s name into cell A1. Then he typed the address in B1 and the phone number in C1. He added headers. He added more clients. Within twenty minutes, he had a client list.

For the invoice tracker, he needed to know one thing: how to add a column that automatically sums numbers. He searched “how to sum a column in Excel,” watched a 90-second video, and applied it. Done.

For the schedule, he needed to know how to color-code cells. He searched “how to color cells in Excel,” found the answer in 30 seconds, and applied it.

Total learning time: about two hours, spread over three days. Tomás never learned pivot tables. He never learned VLOOKUP. He never learned macros. He learned exactly what his problem required and nothing more.

Six months later, his spreadsheet system was still running. He’d added a few columns. He’d figured out how to sort by date. He’d learned to freeze the header row so it stayed visible when scrolling. Each of these additions came from a specific need — “I want to see which invoices are overdue” — not from a curriculum.

Tomás didn’t learn Excel. He learned enough Excel to solve his problem. The problem drove the learning. The learning stopped when the problem was solved. And the result was a functional system that served his business every single day.

The Minimum Knowledge Path#

Once your problem is defined, the next step is identifying the minimum knowledge path — the shortest line of learning between where you are and where your problem gets solved.

This is not a comprehensive curriculum. It’s a targeted sequence.

Step 1: List the Sub-Problems#

Break your main problem into smaller pieces. For the website example:

Get a domain name
Choose a platform to build on
Create a basic page layout
Add photos to the page
Add a contact form
Make it look decent on mobile
Publish it so others can see it

Step 2: For Each Sub-Problem, Identify the Minimum Knowledge Required#

Not everything you could learn. Just the minimum. For “create a basic page layout”:

How to add a heading
How to add a section
How to arrange elements side by side
How to add a background color

That’s it. Not CSS grid theory. Not responsive design principles. Not accessibility standards. Those matter — but not in hour three of your first project.

Step 3: Learn Each Piece Just-in-Time#

Don’t learn all the sub-problems in advance. Learn each one when you reach it. When you’re ready to add photos, search “how to add images to [your platform].” When you’re ready to add a contact form, search “simple contact form [your platform].”

Just-in-time learning is the demand-driven learner’s primary mode. You don’t stockpile knowledge for future use. You acquire knowledge at the moment of need. This approach is efficient because it eliminates the gap between learning and application. You learn it, you use it, it sticks.

The Minimum Knowledge Path Map#

Draw this out. Literally. On paper or in a document:

PROBLEM: [Your specific problem]
    │
    ├── Sub-problem 1: [description]
    │   └── Learn: [specific thing to search/read]
    │
    ├── Sub-problem 2: [description]
    │   └── Learn: [specific thing to search/read]
    │
    ├── Sub-problem 3: [description]
    │   └── Learn: [specific thing to search/read]
    │
    └── Sub-problem N: [description]
        └── Learn: [specific thing to search/read]

This map is your learning plan. It’s not organized by topic — it’s organized by need. You work through it sequentially, and each step brings you measurably closer to a solved problem.

Learning Scope Control: The Discipline of Not Learning More#

The hardest part of demand-driven learning is not the learning itself. It’s resisting the pull to learn more than you need.

You’ll be working on your project, and you’ll stumble across something interesting. A feature you didn’t know existed. A technique that seems powerful. A rabbit hole that promises deeper understanding. The temptation is strong: “This could be useful. Let me explore it.”

Don’t. Not yet.

At the beginning, every tangent is a threat to completion. Every detour extends your timeline. Every “just a quick look” becomes thirty minutes of browsing that moves you no closer to your goal.

This isn’t anti-intellectual. It’s strategic. There will be time for exploration later — after you’ve crossed the threshold, after your project is complete, after you have a working result. Exploration from a position of competence is productive. Exploration from a position of zero is distraction.

At the start, more knowledge equals more distraction. The learner who knows exactly what they need and ignores everything else will finish their project in days. The learner who follows every interesting thread will still be “learning” months later, with nothing to show for it.

Three Rules for Scope Control#

The relevance test: Before learning anything, ask: “Does this directly help me solve my defined problem?” If no, bookmark it and move on.
The timer rule: If you find yourself researching something for more than 15 minutes without applying it, stop. You’ve left the demand-driven path.
The “later” list: Keep a running list of interesting things you want to explore — after the project is done. This list gives your curiosity a place to go without derailing your progress.

The Project as Learning Container#

There’s a reason the demand-driven approach works so well: it wraps learning inside a project.

A project has a start and an end. It has a defined outcome. It creates deadlines — real or self-imposed — that keep you moving. And it gives you something tangible at the finish line: not just knowledge, but a result.

The result matters more than you think. Knowledge without application is fragile. You learn it, you feel good about it, and then you forget it because you never used it. A project forces application. Every piece of knowledge you acquire goes immediately into practice. And applied knowledge sticks.

The project also provides motivation. “I’m learning to code” is abstract and endless. “I’m building a portfolio website” is concrete and finite. You can see progress. You can measure it. You can show it to someone.

Choosing Your Project#

If you’re using the demand-driven approach, you probably already have a project — it’s the problem that started this whole process. But if you’re adapting this approach to a skill that doesn’t have an obvious problem attached, here’s how to create one:

Make it small. Something you can finish in 10-20 hours of work.
Make it specific. “Build a birdhouse” is better than “learn woodworking.”
Make it personally meaningful. You’ll push through frustration more easily if the result matters to you.
Make it demonstrable. Something you can show to someone else — a website, a meal, a song, a photo, a piece of furniture.

The project is your container. Everything you learn goes into it. When the project is done, you’ve crossed the threshold — not because you’ve mastered the skill, but because you’ve used the skill to produce something real.

The Demand-Driven Learning Loop#

Here’s the complete cycle:

Define the problem. Be specific. Set boundaries. Write it down.
Break it into sub-problems. Small, sequential, concrete.
For each sub-problem, learn the minimum. Search, read, watch — just enough to attempt the step.
Attempt the step. Don’t wait until you understand perfectly. Start with imperfect understanding.
When you get stuck, search for the specific error or gap. Not “how does CSS work?” but “why is my image not centered?”
Move to the next sub-problem. Repeat.
When all sub-problems are solved, your project is done. You’ve crossed the threshold.

This loop is fast because every minute of learning is connected to a minute of doing. There’s no gap between theory and application. There’s no stockpiling of knowledge for hypothetical future use. There’s just: problem, learn, do, next problem.

You don’t need to understand the whole language to say what you need to say. Start with the sentence. Learn the grammar it requires. Speak it. Move on to the next sentence.

I’m not a programmer. But I needed a website. That was enough to start. That was enough to finish. And that — a specific problem, a defined scope, a minimum path — is enough for you too.

Define your problem tonight. Write it down. List the sub-problems. Start the first one tomorrow. The skill you need is hiding inside the problem you already have.