I frequently see a problem when people (especially techies) try to teach programming to someone (especially non-techies). Many programming tutorials begin with basic programming principles: variables, loops, data types. This is both an obvious way to teach programming and almost certainly a wrong way to teach programming. It’s wrong because nobody wants to learn how to program.

If you are teaching a class of adults who are paying with their own money for an education, then this is an appropriate and direct way to teach programming. It’s their money. They expect that they’ll have to focus and slug through concepts to come out the other end with programming knowledge. The start-with-variables-loops-data-types approach is fine for this. But most likely they still don’t want to learn how to program.

But for the casually interested or schoolchildren with several activities competing for their attention, programming concepts like variables and loops and data types aren’t interesting in themselves. They don’t want to learn how to program just for the sake of programming. They don’t want to learn about algorithm complexity or implicit casting. They want to make Super Mario or Twitter or Angry Birds. This idea is best summed up in one of Ryan North’s Dinosaur comics (click to enlarge):

Here are my five pieces of advice to people who want to teach programming or create programming tutorials:



1. Kits Are Not Programming

If you make the realization that nobody wants to learn how to program and jump past that trap, there’s a second brick wall on the other extreme you might hit: software creation kits. This is especially notorious with drag-and-drop game creation kits. In trying to make it programming easy to do and abstract away details, these kits end up getting rid of, well, programming. (Although there’s no end to products that claim to let you create applications without any programming at all.)

But people can feel the limitations that these programs have. Many of these kits are good for creating a certain class of applications or certain genre of games, but have a restricted reach because they aren’t flexible enough. We need legos, not playsets.

(I enthusiastically endorse Scratch for use by the pre-teen crowd, especially since typing can be a large barrier to programming for that age group. Scratch rides the kit/programming line very well. GameMaker, RPGMaker, and other kits, not so much.)

2. Toy Examples Are Fine, As Long As They Are Braggable

Almost every programming book and tutorial has examples, but these are usually code snippets to demonstrate a single function or concept. Breaking down learning material to single concepts and providing a simple example. This is an obvious way to teach programming, but nobody wants to learn programming.

The main examples in my book, “Invent Your Own Computer Games with Python” (free to read under Creative Commons at http://inventwithpython.com) present the complete source code to simple games like “Guess the Number” and “Tic Tac Toe”, and then explain how these programs work. A small amount of programming concepts had to be taught at the start and some single-concept examples are given, but the chapter always centers around a complete game.

The first few game programs are all under 50 lines long, but this is fine because they are still complete programs. This isn’t something they can make money off of in an appstore, but the standards for something neat enough to show someone else are much lower. By leading with complete programs and then explaining the programming concepts that go into them, you give the learner a reason to continue learning.

As a result of what code goes into each game program, programming concepts in “Invent with Python” are given in an unorthodox order sometimes. That’s fine. Beginning programmers don’t realize they’re learning concepts in a weird order and don’t care as long as the learning material makes sense. If you are creating tutorials for self-directed learners, they’re going to learn in a non-linear manner anyway.

3. Beginner Programmers Are Plagiarists (So Give Them A Lot To Plagiarize)

I began learning BASIC in the third grade. This might sound impressive to people who think that only the highly intelligent can learn to program computers. The thing is, all of my programs for the next several years were just slightly-modified copies of the same two or three types of programs I had already seen. They were mostly print and if statements with a few random numbers thrown in.

Newbies’ programs bear a lot of resemblance to the programs they’ve already seen because they don’t have enough experience to know how to take an original idea and deconstruct the code needed to make it. So help them along by giving them several different examples. (“Invent with Python” has simple “coin toss” guessing games, games that manipulate strings such as Hangman and Bagels, games that use 2D Cartesian coordinates, and a small encryption program).

It’s okay if they don’t completely understand how a program works after they’ve played with it a little. Very few ideas are completely original. The more material you give your students to plagiarize, the wider the range of derivative works they’ll make from them.

4. My Programs, Let Me Show You Them

One thing that MIT’s Scratch programming environment gets right is that they have a way to share programs that students create built into the software directly. Nobody wants to learn programming, they want to make cool programs. Being able to easily share their programs with a community not only provides an incentive to learn and create, but it also provides a library of examples for other people to look at to inspire their own programs. The Pygame.org website has a sidebar that is constantly updated with people’s submitted games (source included), which supplies that community with hundreds of examples to learn from. I’d say this is a major factor for Pygame’s popularity over Pyglet and other Python game frameworks.

5. Don’t Distract New Programmers with OOP

Enough said. Things you can also toss out for the new programmer syllabus: recursion, regular expressions, MVC, networking, and file I/O. These things can come much, much later after they’ve made a few programs on their own.

If you are teaching programming, remember that nobody gets excited over remembering to put semicolons at the end of a line. Nobody wants to learn programming, they want to learn how to make programs.

UPDATE:

Zed Shaw (author of the great book "Learn Python the Hard Way") left this comment on Hacker News:

"And no, I'm saying it's a huge myth that nobody wants to learn the "hard stuff". They do, you just have to teach it right. After that you just have people who aren't interested in programming at all and no amount of graphics, games, or cute cartoons is going to make them want to. You can't force or trick enlightenment on people.

But more importantly, I have evidence to back my beliefs. This article has absolutely no evidence."

He brings up a good point. Here's my response:

"Hi Zed, I'm Al, the author of article. I'll admit the title is hyperbole. There are people who want to learn programming for the sake of programming, just like there are people who like learning math even though they don't see immediate practical applications.

I teach programming to a tiny class of 10-12 year olds on Saturday mornings, and have taught a couple one-off classes at Stanford's Splash program to a classes of a dozen students. I've found that having an end-goal in mind of what they will create is a much better hook than just explaining what for loops are (or the idiosyncrasies of the languages are, which Python & Ruby are good about keeping to a minimum.)

I don't think graphics and cute cartoons are needed to make programming engaging either. My book "Invent with Python" has games that use ascii text up until the last few chapters. There's a pretty low standard for games/programs that are cool enough to show off to other people, but nobody ever shows off code snippets.

I think the best thing about "Learn Python the Hard Way" over a book like O'Reilly's "Learning Python" is that your book cuts it down to the bare concepts: "Type this. This should appear. This is what is happening." That's great compared to most computer books where there are paragraphs upon paragraphs that could be whittled down to a single sentence or cut out entirely. "Learn Python the Hard Way" is barely over 200 pages. That's much more digestible than some 600 page tome.

I just think that many classes where the students aren't CS majors or necessarily dedicated to learning programming forget that it's not just the concepts that people want to learn but what they can make using those concepts. Small games and web apps are great for that. Like in Exercise 22 of your book says, "It’s important when you are doing a boring mindless memorization exercise like this to know why. It helps you focus on a goal and know the purpose of all your efforts.""