Comment by exch | Hacker News Reader

Comment by exch | Hacker News Reader

Parent Full thread

I understand where the OP is coming from, but I will go one step further.

If you are teaching programming to someone who has never written a line of code, you need to do away with the programming language all together. When you start out, you are learning two distinctly different things at once:

    * General programming principles; abstract thought patterns.
    * The language it is being taught in, along with all of its oddities and quirks.

These two do not mix very well and can, in some cases, be counter intuitive. I believe that teaching someone to /think like a programmer/ and learning analytical and iterative problem solving are of primary importance. They apply to any language. Once you grasp these, the actual language of choice is considerably less difficult because patterns in the language are immediately familiar.

I'm fairly confident that you can effectively teach someone to /think like a programmer/ without ever showing them a single line of code.

This doesn't work well, in my experience. Non-programmers don't want to program -- they want to get a computer to do something. As a teacher, it's your job to seduce them into programming as a way to get the computer to do what they want it to do.

I learned to program, not because I wanted to program in the abstract, but because my friend's dad showed him how to make a little car drive across the screen, and I wanted to do the same.

I spent hours typing programs in from books, not because I wanted to program, but because I wanted to get 3d shapes moving around.

When I taught programming classes, I'd often digress to talk about some interesting abstract concept -- and immediately lose 90% of the class. Start practical, and enrich from there, as the material becomes relevant.

I came here just to agree with this ... I took Computer Engineering in college, did quite a bit of C++, Assembly programming and Data Structures ... but I really didn't 'get' any of it, even though I could pass tests and ace my finals. It wasn't until I happened on a PHP tutorial that showed how you could post user information to a db and replace a section that once said "login" with "Welcome xxxx" that it all clicked. My brain started to go crazy with possibilities and I immediately started trying to learn EVERYTHING about programming.

I spent hours on Sitepoint, printing out articles and just reading them over and over, and trying them out. (I still have the huge stack of printouts in a section of my home office as a reminder of all the work I put it ... you know ... when I start to doubt myself). I had learned OOP in college but I really didn't get it ... one day I went to Barnes and Noble and spent the whole day reading a Head Start OOP book ... and I 'got' it. I felt like Neo in the Matrix (I know Kung Fu!!!)

The point of the story is ... keep all the boring crap out of the way at first, get beginners excited about building things, that will give them the passion that will carry them through the (necessary) minutae later.

I disagree, I think it's far easier to teach coding by showing easy code examples without going into algorithms or abstractions at all. I'll point to codeacademy, who are doing this very well. People learn really fast with their method, it's working very well. Abstractions are much harder to understand than things you can actually use and see it working.

You just have to avoid the mistakes the article talks about. Which is assuming the reader knows what you're talking about and introduce too many topics at once, forcing him to run in circles trying to understand each one. I think that's the n1 mistake in teaching in general.

Yes. In general as a teacher, I've found that those that love a subject are tempted to teach it by presenting conceptual overviews they arrived at after they actually understood it themselves. They have these "holy shit" moments where whole areas of seemingly disparate ideas converge, and they think that presenting that first will help others get to their level.

But in fact, you have to figure out what will bring people to an understanding (and it differs depending on what type of thinkers they are), not what their understanding will bring them to. Or at least, you can't just do those overarching explanations.

* General programming principles; abstract thought patterns.

* The language it is being taught in, along with all of its oddities and quirks.

That's why some people swear by Scheme for teaching. Simple language that exposes principals, concepts, abstract thought patterns with minimal syntax, oddities, and quirks.

http://www.trollope.org/scheme.html (referenced from http://paulgraham.com/avg.html)

I feel the same about music instruction, except that there is essentially only one language it is written in. I hated music classes as a kid because I hated (still do) they way music is written down. But I found out later in life I have a decent intuition for music and melody. From what I've read of the Suzuki method, that sounds like the absolute best way to do it. Start with the ideas, and only later worry about how they are written and read.

cf. http://news.ycombinator.com/item?id=3840979 (How To Train Your Robot)

Reply on news.ycombinator.com