- I read a programming book on your list, and I think the author is wrong.

Reading programming books should challenge your thinking and understanding. Disagreeing with the author is not wrong. But try to look at what they are saying from their perspective and ask yourself why you disagree.

The point of reading a programming book is to learn. Disregarding an author’s opinion without reflection will yield little reward. However, there are often lessons to be learned even if you disagree.

Look at the programming book Clean Code by Uncle Bob. A popular programming book from 2008 that uses Java, often a target of criticism like it is dated and not relevant anymore. Does that make it a poor book to learn principles and practices? Not at all! One only needs to consider the context surrounding the statement. Here is a sentence from the third chapter about functions.

The ideal number of arguments for a function is zero (niladic).

This statement makes no sense in Haskell (or lambda calculus) since all functions take one argument, and functions with zero arguments are illegal. Does that mean that the ideal function can not exist in Haskell?

No, this is an unfair judgment. Uncle Bob wrote this book with an OOP (Object-Oriented Programming) perspective with examples in Java. The point is that many arguments can be complicated to use and understand. It can also be a smell of too many dependencies.

Always try to see where the author is coming from and what lesson they are trying to teach. For example, the first chapter of Clean Code says something important:

Books on art don’t promise to make you an artist. All they can do is give you some of the tools, techniques, and thought processes that other artists have used. So too this book cannot promise to make you a good programmer. It cannot promise to give you “code-sense.” All it can do is show you the thought processes of good programmers and the tricks, techniques, and tools that they use.

- The examples contain bad and ugly code.

Programmers usually jump to code examples because we want to see how it works.

One should not blatantly copy code examples. Examples are there to illustrate an idea. It is about showing you what the text is discussing.

A great example of this is in the programming book Design Patterns by GoF (Gang of Four). I have seen people transcribe the examples in this book from C++ to their language of choice, and what they usually end up with is a more complex solution than is needed.

The irony is that the definition of a design pattern stated earlier in the book (which is a quote from another book) says this:

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice