Point #2 is the Little Coder's problem _Why spoke of: a beginning programmer is likely to be discouraged by the vast difference between the toy programs displayed in introductory books, and the real code that inspired them.

I think any purported attempt to teach programming which does not end with the student creating a non-trivial, cool app, is a shame. What went wrong between SICP and current (non-Hartl/Shaw) beginning texts?

The "worthless example to explain features" in my pet peeve...

This is something like "we're going to have a class named Vehicle" and "class Car inherits Vehicle" in an OO language.

You would almost never use something like this in a real program, and it takes what's a minor and problem fraught feature (inheritance) and quickly has new programmers creating bizzaro hierarchies that never should be.

I'd like to add a 4th one:

Those arbitrary and excessively long introductory chapters that teach you the history of the language. Granted, that might have some merit in a classroom setting where an instructor is going to ask you a pointless question about who designed the first interpreter, but this is the sort of thing that should be kept to a minimum, or kept out.

Zed Shaw's "Learn to code the hard way" are brilliant for this. They get right to it, nothing you don't need to learn and get your hands dirty.

I started learning programming in January using K & R. It is a wonderful book which avoids all of these problems.

It's short. You write challenging programs in the tutorial introduction. And the accompanying "C answer book" has good solutions for all the exercises.

I also like the fact that each example is a working program. You learn the concepts by applying them. And the exercises really make you think.

People say its "not for beginners". I actually think it's an ideal way to start. The "beginner" books are just confusing.

My pet peeve is books that show the wrong way to do something followed by the right way. If I'm new to a language, I haven't committed these sins yet, so please just skip to the preferred method. All this does is add mental overhead.

3: If there are multiple valid solutions to an exercise, list them. If some solutions are better than others, explain why. If there are solutions which are technically invalid but commonly thought up by new programmers, explain what they did wrong.

I would also add a forth point: "Overdoing the 'lol im not like those nerdy others programmers, im a regular normal person like you' rhetoric. Instead of mentioning an old cliche (and then trying to distance themselves from it), why not just not mention it at all?

#1 is a great point and a great recommend. There is certainly a place for long, ponderous reference book-like tomes, but they are a poor substitute for concise beginner books. Eloquent JavaScript is amazing in that respect.

I believe there is a start-up that is gaining traction that is looking to remedy all of those issues. I can't remember what it's called right now, but the concept is you learn to program online in an environment that shows you where the mistakes are and also what the outcomes are to keep you motivated. Seems like an ideal situation; and frankly it's a little surprising something like this hasn't come out sooner considering most programmers go through this sort of pain... Maybe it's seen as a right of passage, if you can put up with the BS, you deserve to be a programmer?

I'm no expert, but I think it's possible that the fact that's a book at all may be a failing. The goal is to get them writing code and seeing results, as well as mimicking their later real world experience of experimenting to find the right answer. That's why I think things like code academy better reflect the way we'll be teaching this in the future.

How about another one.. "Takes too long to get to the interesting parts."

i.e. learning Obj-C and taking until the very last chapter to give even a cursory intro to apps. By the time they get there a ton of people will be burnt out / disinterested.

My pet peeve are books/tutorials that spend most of their time in the interpreter. I appreciate interpreters for what they are, but I don't thing the ability to type 2+3 and get 5 is relevant to any programming language skills.

Also:

- Please stop including math in every example. I just can't stand see another fibonacci example. Ok we get it, it's awesome for showing recursion, but use other things. Also, don't put math problem on exercises. I'm learning a language, I don't want to recap all my scholl math at the same time. I'll die if I see another "get all the prime numbers from 1 to 100" yada yada yada...

- Don't use the concept of "throughout the chapters we will be building an app...", most of the times these apps suck and are plain boring, and it's demotivating for the beginner. Instead create different small apps in every chapter.

- Bonus: It would be awesome if books started including a cheat sheet.

I was thinking about how I never "look at the language's documentation" when a book or tutorial tells me to.

As a beginner/intermediate coder myself, I can't just "look at online documentation" because I don't truly understand how to use it and understand properly. Does anyone have a good resource for learning how to use documentation?

I know that may sound trivial to experienced hackers, and possibly paradoxical, but I'm actually quite sincere about this request.

Random idea: tailor programming books somewhat to personality types? Eg an ENTP and ISTJ are not going to enjoy creating the same kinds of programs.

I'm also pretty tired of "foo" and "bar". At the very least they teach nothing about the thought process that should go into naming things.

Although point #3 has also annoyed me no end, I believe I learned a lot from being forced to solve problems myself. Peeking at the solution is just too easy and severely diminishes what you can learn by being forced to think more about the problem. I believe Introduction to the Theory of Computation by Sipser gets it right: answers to about half the exercises.

Totally agree, except for his point three - beginners typically don't care about exercises, they want to get something working. As long as it works and does what they want, they're happy.

...not to mention 'From Beginner to Professional in 28 days!'

undefined

"Teach yourself blah in 21 days", anyone?