How the course runs

Bag-a-goat
Photo: Holly Vickery

I'll help you learn programming (me, Kieran, not the goat). But doing programming and teaching programming are different skill sets. Someone can be good at something, and be a lousy teacher.

I'm a software guy. I've written hundreds of programs, in a dozen different languages. But I'm also a teacher, and I want to be worthy of students' trust.

So, for the last fifteen years or so, I've learned about learning. How brains work, how they learn, and how we can help them learn efficiently. Turns out, science knows a lot about that. Not everything, but enough to help us design, build, and run effective courses.

Let's talk about how this course runs, and why.

Exercises

This is a skills course, not a memorization course. Why? 'Cause it's skills that get you Benjamins.

Obviously, practice is important when learning skills. You can't learn programming from just lectures. So, this course gives priority to exercises.

Some exercise sequences are better than others. Say you have two exercises. The second one is more complex than the first.

​Two exercises

The difference in complexity is the learning gap.

​Learning gap

The gap in the drawing is big. Big gaps mean more people struggle, and get left behind. Let's not do that.

Suppose we did this instead:

​Small learning gaps

Better! The steps in complexity are small, easier to learn.

Right. There has to be less reading, and the exercises have to be kept smaller. It's a good tradeoff, though, because it means more people succeed.

Something important to see here: you get to the same complexity, either way.

Same complexity ​

But having more smaller exercises is more effective (and more pleasant) than having a few big ones.

If you're going to teach, you should study course design. It will make a big difference to your students.

Explanations

Exercises are great. But it's no good to just give you a task, and say "go." You'll waste time working out what to do. It's more efficient to start off with explanations of how to do a task, and then ask you to do a similar task.

It's also more pleasant for you.

The science tells us how to make good explanations. Things like:

• Use informal language, and short sentences. Like this one. Your brain should spend its time learning programming, not wrestling with language.

• Worked examples are effective. One good example is often worth pages of text.

• We know... well, a lot of other stuff about making good explanations.

So we have:

Explanations and exercises​

Formative feedback

You'll get more from exercises if you know how good your work was, and how you could do better. Not a grade, but a list of things you did right and wrong. That's called formative feedback.

Even better, your feedback should be personal. Not about what other people got right and wrong, but about your work.

Better still, you should be able to read the feedback, improve your work, and resubmit it. You can learn from your mistakes, and have a chance to show it.

The exercise sandwich

Exercises are where you learn the most. To make learning efficient, we wrap exercises in explanations and feedback.

​The exercise sandwich

Most of the lessons in this course implement the exercise sandwich.

Problem solving

Many courses have too much content. Maybe you've had a math course, with so many topics, you never had a chance to learn how to use the math. You were too busy learning this week's formulas.

That's not good enough. It's not how you become an effective problem solver, and get those Benjamins.

This course covers only a few programming statements. The most important 10% of the language you'll be using.

We'll spend more time on how to think about programs. Ever had that panicky feeling, when someone gives you a task, and you don't know how to get started? We've all been there, but it doesn't have to be that way.

Knowing how to get started designing a solution is worth more Benjamins, than knowing the deets of a programming language. You can google the deets, but you can't google problem solving. (Well, you can, but being able to do problem solving is different.)

There's an issue, though. I'll explain how to solve a problem. You'll watch Adela and her friends write programs for that problem.

Then you'll do an exercise about that topic. And another. Then you'll add a little to what you know, and do another exercise.

You'll say to yourself:

Self, I already know how to do this! Another fargin exercise?

If you get to that point, it means you've learned. Celebrate that something is easy for you! If you tried to do the tasks from the last part of the course right now, you'd get that panic-I-don't-know-how-to-start feeling. But by the time you get there, you'll know what to do.

Here's what I hope: when you get to the end of the course, you think, "Wow, that course was easy."

A guarantee

If you do the things I ask you to do, you will learn how to program. If you have problems, I'll work with you individually to bring you up to speed.

How can I make this promise? Because this course follows the science of learning. The course has been running for years as a smooth, predictable learning system. You can't help but learn. You'll see.