As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

Note, they are a bit silly, but they use the silliness to drive the points home.
–
user1249Aug 1 '11 at 18:42

I find them too simple and distracting. I like short sentences/books/simple ideas such as "Don't Make Me Think". I like it when the text is sprinkled with graphics. However, I prefer succinct, laconic and somewhat dry diagrams. Simple concepts can be expressed in text (or skipped altogether if they are common sense). Hard stuff sometimes needs to be drawn, but I prefer densely packed and laconic diagrams such as upload.wikimedia.org/wikipedia/commons/thumb/5/51/… rather than what Pierre posted.
–
JobAug 1 '11 at 18:48

1

I don't like Head First Java Very much because they are explaining the same thing over and over again and one may confuse after reading it.
–
user71736Nov 3 '12 at 9:20

Agreed with user71736. The book on servlets is 750 pages long and they just say the same thing over and over again making it confusing, frustrating, over-complicated and difficult to get an overall picture.
–
W.K.SMay 13 '13 at 7:52

There are two extreme opinions about Head First: The first is that they're awful, and the other is that they're excellent.

I personally think they're awful because their explanations are way too long and very off topic most of the time. They're big books with not so much content. They feel like books for kids (or childish adults).

Some people (most people I think) love those books because they're very easy to read and it's almost impossible not to understand their explanations.

Head First books are good only if you're a beginner. They cannot be used as reference books. They're written for people who know absolutely nothing about the topic.

Note that there are many Head First books and many Head First authors. The most famous ones are "Head First Design Patterns" and "Head First Java". And they also have books which aren't related to programming (about physics and statistics). So you cannot really say anything about the whole "Head First" series. The only "Head First" books I'v tried reading are "Head First Design Patterns", "Head First iPhone Development" and "Head First Servlets & JSPs". I didn't like them (found their explanations, metaphors and jokes annoying) but I know about people who did like them.

In my opinion, they're good if you are a beginner in programming in general - not only in the topic in question.

That is, before learning the options for conditionals in a language, they will spend a lot of time - and a lot of simple and silly examples - to explain what conditionals are.

The solutions they propose are often very lean and lightweight, but they tend not to explain why they chose that solution and which the alternatives are.

Use cases:

A C++ programmer wants to dive into web development, using PHP. I would recommend one of the mid-level books also by O'Reilly, like "Learning PHP, MySQL and Javascript". Those are still very careful (borderlining on the pedantic) in explaining how the language works, and full of examples: still, if you have the right attitude towards learning new technologies, one of them would suffice to let you build solutions for almost anything within the standard scope of that technology. Also, they can be used as a reference.

A web designer wants to learn some Javascrtipt to liven up his pages. He is a nice specimen, so he prefers having an idea, albeit vague, of what he's writing rather than copypasting around. Nevertheless, he does not want to master that technology and he never read a programming manual - so there would be a steep learning curve for language and conventions themselves with a nice course/reference book, and it's not worth it. In that case, Head First manuals are definitely the best option.

They are great, you can definitely start a new topic with those books without any pre-knowledge on those topics, But, If you are already familier about those topics, then sometimes, you will feel a slow learning. Simple, for beginners, those are great!

I've read, Head First SQL, Head First Servlet and JSP, Head First EJB(3) without any prior knowledge on those topics, I've a nice explanation from there.

I'm not terribly fond of them personally: I prefer denser texts that allow me to absorb information very quickly. However, I've been coding since age 6 and am accustomed to picking up new skills/languages on the fly. The exercises are a waste on me (if I'm learning foo, it's because I need to use foo for something -- that is my exercise).

Many newbies I know swear by the Head First series, for exactly the reasons I dislike it: the language isn't very dense, so (to the newbie) it feels more approachable, and there are plenty of exercises to practice with.

So, it comes down to your learning style: do you like to wander around a subject to get your bearings, try some exercises, and take it slow, or do you want a dense manual from which to launch into some project-at-hand? Head First books are good for the former, not for the latter.

Yes -- buy one, they are excellent. I read the Head First Design Patterns book, and I found it to be helpful with examples I could understand. I also didn't get bored because of the fun style. I recommended Head First Javascript to a friend, and she has also found it to be a great book.

I don't know about the other Head First books so I'm going to state my opinion about the book that I'm reading right now, Head First Servlets and JSP.

The first half of the book is definitely great, hands down. They explained the concepts in a straight-forward fashion through pictures and stories. As a developer who built a J2EE web app in the wrong way as a way of diving in, I found the book really helpful in patching up some of the holes in my knowledge of J2EE. Most of the questions I find myself asking when I was still starting out was answered by the first half of the book.

However, I find the remaining half of the book to be written as if it was intended for advanced developers already. The book makes you dive into several advanced topics and concepts without really explaining how everything happened in words that beginners can understand. The book tosses you several topics at once, so it's giving me a hard time to understand everything. I even find the diagrams, and pictures to be confusing as well.

I'm still on the process of reading the book right now, but I'm now under the impression that the book was rushed, because the book failed to explain the topics clearly that I can't piece everything in my head together now. This dilemma led me to ask this question.

I don't know if other Head First books are the same way since I haven't read anything other than Servlets and JSP.

The Head-First series books are my favourite. They make learning both easy and interesting with humour and great conversation style. Every book begins with an illustration of how our brains work and how to get maximum out of our brain's capacity. I try to adopt them. They made learning design patterns very easy for me.

I have read both Head First Java and Head First Design Patterns. The style used is indeed unique, and is something of a love/hate for most people.
What everyone should, in my opinion realize, is that these kind of books make things very clear and simple, but at a cost. The cost is the overhead that this way of explaining things imposes. Things are explained over and over again, with multiple examples and metaphores. It is a significant overhead, that does not let you dive immediately into the core of the problem.

I thought that this style suited the Head First Java book very well. I liked everything about that book, and it was extremely helpful for me, in grasping the concepts and developing an intuition about them.
On the other hand, I did not like Head First Design Patterns at all. My impression was that it becomes way to verbose, and at times, totally misses the point. There was too much meta-information, but not a lot of real useful information.