Hacker News Reader

Comment by zedshaw | Hacker News Reader

I have about 200k+ unique visitors a day reading my books, and over a million since I started tracking in May last year. I have comments on nearly every exercise on my books, which means people are actually going through them. I have 2200 people taking my udemy course which is the most popular paid class on the site (last time I checked). My books are used in workshops all over the world, have readers from all over the world, and have taught people from nearly every age group that can read English.

And my books do exactly what this article says you shouldn't do.

I'd say if nobody wants to learn basic programming concepts from you, then it's not the concepts, it's you.

View on HN

Zed, you're awesome. With that said -- it's who you're teaching that lets you say this.

Right now there are people who know they want to learn programming coming hell or high water, and you do a damn fine job teaching them.

There are also a whole lot of people who might want to write apps, but do not want to go through the pain of learning programming.

The audience of Scratch, from MIT, is the narrow end of this giant wedge of people. They have nowhere to go from there because nobody else does it that way.

I miss the Apple II. It actually had a few on-ramps for people like that. Those on-ramps are pretty much dead now, though I have no idea why.

The guy writing this article isn't aiming at your set of programmers. He's aiming at all the people who aren't programming but would love to be able to build apps of one kind or another. There are a lot of them, and even a lot who could, and who we do a terrible job of teaching.

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.

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."

I'm in the process of self teaching myself to program (I'm a civil engineering student). I discovered one of pg's articles somehow and gradually worked my way through them and began to think that I should probably learn to program myself. I have ideas for things that I presume could be solved though programming but without learning to program it is impossible to know what is possible, this is the hardest gap to cross.

I bought Zelle's Python book, started JavaScript with Code Academy, got Graham's ANSI Common Lisp out the library and tried Rails for Zombies but none really got me interested enough to stick at it.

Dan Nguyen's Bastards Book of Ruby however has been the most successful. It's pretty much straight in, actively encourages copying and pasting code early on, with the immediate prospect of making real programs which interact with the wider world (HTML scraping) instead of feeling isolated on your own computer. I could immediately how HTML scraping could be useful for someone and how the first short programs might be extended.

There are some excellent motivating articles as well which were really key in sucking me in. He also calls his type of programming 'data programming' which to me, a non-programmer who hasn't had the chance to be brainwashed by programming theories, is the most obvious name in the world - all these problems I think could be solved with programming are just manipulating data.

btw: I don't find the prospect learning to program games motivating at all; there seems to be so little you can learn from most of them and a dangerous waste of time.

Right, but I think you are confusing causation with correlation. You say, "Nobody wants to learn the boring stuff and they just want to make games." But, they will learn the boring stuff if you teach it right. The concepts aren't what's putting people off, they're just correlated with bad styles of teaching it.

For example, explaining programming to total beginners doesn't work. Like you say, paragraph on paragraph about boolean logic is pointless if they can't even type:

print "hello world"

A beginner can't understand this because they don't have the cognitive tools to comprehend your explanation. But, if you make them do it a bunch, in tiny bites, and build their understanding as you go, then it works. This doesn't work for experts, but it works great for people with no prior knowledge.

So, you are confusing the concept with the delivery. The concept does not cause boredom, it's the delivery that does. And, I also don't mean you have to deliver it wearing a clown costume, I mean breaking it down in a way that builds the concepts from nothing.

So, I'm walking this edge right now with a few middle schoolers.

At the beginning of the (school) year, we started doing a programming class using scratch. The operative theory was to be able to explore, get the cause/effect thing going, some debugging, and be able to build something that they could distribute and have other people play. It was a success for a while, within a class or two, pretty much everyone had something that was more than just basic behavior. There was some animation, some 'cat chases mouse', and other basic games. But they quickly hit the wall where scratch is just painful to program. There's no abstraction, and if you want to do space invaders, you wind up copy and pasting a hell of a lot of code blocks. And woe to you if you then need to change something. Dragging and dropping is attractive till you need to build equations of motion.

So, beginning this semester, we're working through LPTHW. The class is smaller, some were definitely scared away by the "hard way" and my warning that they'd have to work. But the ones that are there are soaking it up. I think we're at ~ 5 lessons a week, based on one class time when they can do stuff + homework.

They're getting it. They can find bugs. They have seen where we can go (because of scratch) but they've also seen that there's got to be a better way than drag and drop. My goal is LPTHW should take a quarter, then we'll pull in pygame and some networking stuff, and do a basic networked game. My goal is to be able to translate one of their scratch games roughly block to line, then kick it up a notch. Seeing what I have, I should have abandoned scratch after a quarter, rather than a semester. It would have still given them the view of where we can go, but had them miss the more frustrating parts of the scratch environment.

I've now got some home school experience teaching kids from pre-k to middle school. Heavily scripted stuff is awesome, _provided_ the kids see where it's all going at the end. Far better than random or directed exploration. (I've seen this in learning to read, elementary math, programming, and an art class).

I can see how the standard "first class is scheme second class is discrete math" scares some away. How big of a population actually gets lured unto programmingblater in life?

I'm glad to be a piece of your evidence.

I have college degrees in Entrepreneurship and Marketing and have been just a "non-tech" guy for too long. I got tired of not being able to build anything myself, so I'm working my way through your book right now.

Of course I have a specific application in mind that I'd like to build, and perhaps this is evidence of my naivete, but it seems like if I were to just learn how to do that, I would be limiting my creativity. The difference between learning how to program only a specific type of application and learning to program in general seems like the difference between learning how to paint a bowl a fruit and studying the art of painting. What happens when you want to paint a bowl of fruit with a landscape behind it?

Again, I may just be one fool, but it is not the allure of being able to program a specific application that I am after, it is the pain of being ignorant that I am trying to assuage.

You present a false dichotomy. You don't have to choose to just learn how to program one kind of program or how to program generally. You can do both. And in my experience, having an idea and executing on it is a great way to start. You get instant gratification in learning one small subset of programming and you move on from there.

Like the students the OP describes, I too started programming hoping to build a game with as little effort as possible. (I wanted to build a massively multiplayer first person game. I know, I know. Hey, it was high school.)

As soon as I hit topics like OpenGL and networking, I realized this was going to be harder than I thought. The only reason I stuck with it is because I found joy in each little success, like sending a single character over a TCP connection, or putting a border around a <div>. And these successes continue to make the struggle worthwhile.

So this is totally anecdotal, but my personal experience conforms more with what Zed's saying. I think you won't enjoy programming unless you genuinely like the minute, seemingly boring details. Because those become your day-to-day consciousness far more than glamorous stuff like imagining new game mechanics and plotting out a storyline. (And that's assuming you're doing game development at all.)

The article did make a very generalized statement that "nobody wants to learn programming, they want to learn how to make programs" when your curriculum is an exception. With your rhetoric, you were able to get people to learn by trotting on through concepts in their barest form.

Fundamentally, you're both teaching by example and the code is simple, so that the results have a clear correlation to it.

It seems to be an aesthetic choice as to whether you teach concepts outright and make it communicable with proper rhetoric or illustrate concepts by highlighting their use in a simple application. It's like two guitar instructors. One stresses etudes and practices alongside songs and another stresses songs alongside etudes and practices. I can't see either way hurting a student. Whatever the choice, you're packaging this information in a way that makes it digestible to those who want to learn how to program (either the way of rhetoric or application).

I would like to say this though, at least you guys are not teaching Java by programming within the Eclipse IDE, which isn't ment for beginners.

Hello Zed and all

A few of us have even bought one of your books :-)

My mature students taking basic maths courses in the UK will read the textbook and come back at me with questions that show they have confronted the material and put some time into it. The teenagers need a different approach, games, Web sites with interactive material, carefully chosen written material.

Have you any age data about your participants? Perhaps the video courses?

The age range for my courses is 11 to 65 so far, but I haven't been able to get statistics on the median. It's a touchy subject to ask folks their age, but my guess is the median is about 30, or that it's bimodal with 20 being one hump, and 30 being another.

Another thing to keep in mind is that a computer is already interactive. The idea that you need "graphics" to get students interested is completely unfounded, and the only data comes from experiments from companies trying to sell graphical programming systems for education sales. Even then these studies were done in the 70's and 80's when many people just didn't have computers.

In my experience I've found just making simple text adventure games is entertaining enough. Think about it: It's a game that is approachable by anyone, they are fun, they involve writing, their "graphics" are immediate, they don't require any geometry, and the output looks a lot like the program itself. That's why I teach them. They're easy but still fun.

My experience says you don't need crazy amounts of sensory input to keep people interested, and in fact is just distracts them and frustrates them. Keep it simple, but make sure it has depth that they can discover.

I would imagine the reason kids are likely to prefer graphics is because the games they play involve a lot of graphics so that's what they expect.

I remember in the early 90s plugging away writing various text games in QBASIC then excitedly showing them to school friends who's reaction was mostly "too much reading, not enough guns. Let's play Doom instead".

Of course this was somewhat disheartening and put me off programming for a few years.

The closest thing that I've seen to a comprehensive game creation "kit" is Unity3d but that has a pretty steep learning curve.

One sort of introduction that could potentially work well for teenagers would be to create a mod for an existing game that they already enjoy.

I don't think those kids would enjoy programming a game even with a good kit. They want to play games, not code them, and thus why I said no amount of graphics will get them to.

Also, what you describe is why I wrote:

http://learnpythonthehardway.org/book/advice.html

That is true, although I think one of the main motivations to learning to program (at least for me and I guess many teenagers) is to have something impressive to show off to friends.

Having said that I think you are right to encourage people to use code as a "secret weapon" rather than an end in itself. It is a great "awesomeness multiplier" to other skills.

Reply on news.ycombinator.com