Lessons from 100 learners

Most coding courses — online or offline — are built for completion, not comprehension. 

The goal is to “cover everything,” not to make anything stick. 

Learners are rushed through loops, conditionals, and functions before they’ve even had time to feel curious about code. 

Each lesson adds more tools — 

but no one explains how to think like a builder. 

The result? Students feel like they’re always behind. 

Always trying to catch up to an invisible benchmark. 

Always one error away from giving up. 

And it’s not just a problem in online courses — 

it’s a reflection of how we’ve always taught code. 

🏫 Think about most university classrooms: 

A projector. A monotone voice explaining recursion. 

60 students, 2 confused questions, zero real engagement. 

Teaching is often optimized for delivery, not for cognitive change. 

We dump content, tick boxes, and call it teaching — 

while the learner quietly drifts away. 

There's little room for the individual: 

• The student who processes slower 

• The learner who's scared to ask 

• The career switcher juggling a job and kids 

• The neurodivergent thinker who learns better visually 

Too often, we wait to react after the student loses motivation. 

We don't notice when confusion creeps in — 

or worse, we assume it's their fault. 

Even with ChatGPT in the picture, the problem remains: 

• You can generate answers instantly, but not understanding. 

• You can debug the code, but not the thinking habits behind it. 

So we have to ask: 

Are we teaching people how to code — or just how to finish tutorials?

Imagine the same learner starting two different journeys: one with Python, one with Rust.

In Python, they’re welcomed by simplicity — print("Hello, world!") just works. 

It feels like a conversation with the computer. Encouraging. 

They make small mistakes, but the system nudges them forward. 

Confidence grows quickly. 

Now imagine Rust. The very first line of code looks strange — 

lifetimes, strict types, error handling everywhere. 

The compiler is like a strict teacher: helpful, but relentless. 

Mistakes here aren’t just typos — they feel like judgment. 

The student starts wondering: “Am I not smart enough for this?” 

But here’s the twist: it’s not about the language. 

It’s about how each system supports the learner. 

Python’s environment often feels like a sandbox — experiment freely, fail gently. 

Rust’s environment feels more like a laboratory 

— precise, powerful, but intimidating without a guide. 

Learning feels different not just because of what you're learning — 

but because of how the system reacts to your confusion, 

how the course frames your mistakes, and how much the teaching acknowledges the emotional side of learning. 

So when we say “Python is easy” or “Rust is hard,” what we really mean is: 

“One made me feel safe. The other made me feel challenged.”

The way a language is taught can shape not just how a student learns — 

but how they see themselves as a learner. 

It reminds us that technical content is never neutral: 

Every tool, error message, and course structure sends a message to the student — 

either “You belong here” or “This isn’t for you.” 

So it’s not enough to ask “Is Python easy?” or “Is Rust hard?” 

We should be asking: 

👉 “Does the learning experience invite persistence or trigger self-doubt?” 

👉 “Does the system teach the code — or also teach the courage to keep going?”

Because learning to code isn’t just about writing functions — 

It’s about building identity - who you are.

So if Day 10 is where motivation fades... 

If syntax is taught without purpose... 

If Rust and Python can make the same student feel empowered or defeated... 

Then the real challenge isn’t choosing the right language — 

It’s designing the right learning experience.

Not designing courses around topics — 

rather designing them around who the student becomes. 

Instead of starting with “data types” or “for loops,” we begin with a problem that is real. Learners don’t just complete tasks — 

they build tools with purpose. 

Every concept appears when it’s truly needed, not just because it's chapter two. 

When students learn Python with us, they don’t start with print("Hello, world!"). 

They start with something like: “Let’s track oxygen levels on Mars to keep a crew alive.” Suddenly, variables aren’t abstract. 

Conditionals aren’t mechanical. 

They’re solving something that matters — and learning starts to stick.

Rust, on the other hand, is about: discipline, structure, and safety. 

Yes, it’s strict. Yes, it’s overwhelming at first. 

But that’s the point — because growth often starts where comfort ends. 

Instead of protecting students from Rust’s challenges, we guide them through it with care: 

• We use visual metaphors to explain lifetimes and ownership 

• We build small systems where every error message becomes a clue, not a punishment 

• We slow down, not because students are slow — but because precision matters 

Over time, learners stop fearing the compiler and start trusting it. 

They begin to realize: Rust isn’t just hard — it’s just different. 

It forces them to think clearly, structure thoughtfully, and code with intent. 

But students don’t all arrive with the same mindset. 

Some want fast results. Some come from looser scripting languages. 

Some are rebuilding confidence after years of thinking they’re "not technical." 

That’s why we treat systems as mirrors, not molds. 

We show how different learners can build similar systems — 

but in ways that reflect their strengths: 

One student might approach a problem with data modeling 

Another with algorithmic precision 

A third through system-level thinking or even visual mapping 

There’s no one “right” way — just clear principles, tight feedback, and room to own their work.

Coding isn’t just technical — it’s emotional. 

I've seen students freeze not because of complexity, but because of fear. 

Not because they couldn’t understand Rust’s borrow checker, but because they were afraid to try and be wrong. 

Not because Python loops were hard — 

but because they didn’t know if they belonged in this world at all. 

And that’s when it hit me:  We don’t just teach syntax. We teach identity. 

Every lesson is a message: 

👉 “You’re safe to explore.” 

👉 “You’re allowed to go slow.” 

👉 “You’re capable of thinking like a builder — not just a button-clicker.” 

How a student feels while learning matters more than the order of topics. 

A well-timed explanation can land only if the learner still trusts the process. 

A great project only works if they believe they’re allowed to build it their own way. 

That’s why system design is core pillar. Because it mirrors how the world actually works. 

No one tells you what to type — 

they expect you to make decisions, weigh trade-offs, and take ownership. 

Syntax comes and goes. Tools change. 

But mindset — especially the mindset of I can figure this out — that sticks. 

So if there’s one thing I’ve truly learned from these 100 learners, its: 

You don’t just need to teach code. 

You need to help people become the kind of person who keeps going — 

even when the code doesn’t run.