"People learn from their mistakes. Wise people learn from other people’s mistakes." I don’t know who said that. I heard it from a friend.

It often frustrates me how people (including me) prefer to acquire knowledge in the most difficult way. How others make the same mistakes I made. How they make exactly those mistakes described in all those books, articles, studies... and how they and I wouldn’t have made them if there was someone to tell us to read, to acquire knowledge instead of painfully researching it by experience.

I get even more frustrated by my inability explain those mistakes and often end up with people insulted by my "mister wisdom" attitude. The fact is that I’m not the most polite person one could ever meet. Another fact is that people when shown mistakes often back up and take a defending position and are often reluctant to accept the opposite point of view. (or if you don’t believe me read some Dale Carnegie – never say: "You are wrong")

I write this document with one purpose. To convince you dear reader to read more. To improve your knowledge. To improve your programming skill. If I manage to convince at least one more programmer to read more I will consider my task accomplished.

The sad point is that if you read this you are probably already convinced.

"If you read one programming book - this is more than an average programmer reads for year." Steve McConnell [1]

As a rule most programmers don’t read books. Or at least books about programming. I’ve met programmers who were fully aware of the cutting edge hardware technology, physics innovations, politics, movies, etc. But never considered reading a book about programming. Of course that is what they do. Why bother reading about it? They know it all.

There is a religious argument whether programming is science or art. What do you think?

1. Science – Science lies in books. We can’t invent physics, can we? After all, the apple had already fallen on someone else’s head. We do need to read about it before colliding with any other type of fruit.
2. Art –I hear you saying: "An artist can draw picture without reading books.". Yes, there are geniuses. It is so in the programming society. But if we take a look at an ordinary art school we will see that future "normal" artists study art techniques, history, idioms, methods etc. Talent is just not enough.

There is an ancient proverb stating that everything requires 90% of work and 10% of talent.

I believe that what programmers like about programming is the satisfaction of the creation. I always enjoy seeing my own creation working. So do others. On other hand we as programmers should be aware what is the limit of this creation process.

Have you lately had this feeling that you had invented something new? Did you realize then when sharing it in the industry forums that it has already been around for several years (if not decades) and has some strange name? I myself did. I stopped doing that after I realized that every genuine idea I had come up with had already been studied, described, categorized (under "not so efficient" chapters) in some book I hadn’t cared to read.

"Still there is nothing like the feeling you get when you actually programmed something completely by your self." Post at flipcode.com.

Programmers enjoy being creative. Being able to resolve problems in some creative way brings them the satisfaction of a man who can cope with any problem, satisfaction of being "genius" because they solved the problem (and every other problem) by themselves. I enjoy being creative as well. Very much indeed. But I know that I’m an average programmer and if I try to design a new algorithm for "something" I’ll end up with average (in the best case) solution, or most probably if pressed by the time with a mediocre solution. So I’d prefer to read first (if I haven’t read before about this "something") and see what others have to say about it. Then I’m being creative in applying these "already invented" ideas into the whole. And this "applying" is not an easy process. It requires a lot of creation as well.

Take for example "searching". Every programmer knows at least several algorithms for searching and which one to use and when. Do you? You probably do.

But what about:

Design patterns? Which one to use and when?

Features of your favorite language (C++ for me)? How to use it? Common pitfalls?

Programming idioms with you favorite language? When to use them?

Code construction? Techniques, what’s good, what’s bad, coding styles?

Algorithms? Data structures?

If your answer to all these is "Yes, I covered every single topic pointed here" you read this article by mistake.

I’ve heard different excuses why a programmer doesn’t read (books). Here are few of them:

"I don’t need reading I know it all. I’ve been programming all my life since 7 years old."

"I don’t have the time. Anyway I know enough to get my job done."

"I can’t afford to buy all those expensive books" (That’s mine)

"Everything written in the books is wrong"

What is yours?

"Many programmers are under the false impression that the most important thing they can do is to hammer out code lines." Charles Bloom [2]

Programming books are not fiction. We shouldn’t only read them – we should understand them. Only then we can see what suits our current solution most. Behind every line a programmer writes there should be a sensible reasoning. The programmer should be able to explain why he is doing that (btw "I do it because it is written in a book" is not a valid explanation). Have you ever met people who cut and paste code from examples without having a clue what it does? If you haven’t (which I doubt) now you met one. I used to do that.

In fact in this I find the benefit of code reviews. If a programmer is at a code review and his code is being inspected he will often receive questions about the code and will have to explain why he wrote it like this. By doing this he will find the gaps in his knowledge and hopefully improve them if he wants to be perfect at the next code review. And so it goes...

"...what struck me, and it often does, is that this is an incredibly young industry rot with inexperience." John Stenersen [3]

Game programmers are young people (me too), often inexperienced because the game industry was their desire since early childhood (me too). And they just couldn’t wait to graduate to get into the game developing business.

Game programmers are under pressure. They are in a hurry. They code like "hell" to get the milestone finished. They don’t have the time to read books (especially some books that are not game related? Madness, waste of time.).

One delusion of game programmers is that they think The "game" programming is some very special type of programming, very strange, very cutting edge and normal programming idioms simply does not apply to it. Why bother reading normal books then? Lets read the brand-new game books. (As a matter of fact this is already something: the game programmer reads...) If we take a close look at the general programming chapters of Game Programming Gems books we will notice how simple "normal" programming idioms and techniques try to make their way to the poor game programmer. Excellent though, they are in a very brief form. One cannot fit a whole book in a single chapter. Why not read the books? They are under the "References" section.

Other delusion is that for almost every line of code they write game programmers ask the question: "Is this fast enough? This is a game. We need speed. Optimize, optimize..."

What about the 80-20 rule? 80% of the time is spent executing 20% of the code? It is written in the books, believe me.

To be fare to the game industry and programmers there is a vast amount of cutting edge technologies and algorithms in games. But from a certain point of view those technologies are roughly one percent of the development (if such development happens at all in the game company X) everything else is already researched by someone. With the level of the contemporary algorithms one should be with a strong mathematical and computer science background (including deep knowledge about current hardware) to actually invent something new or at least improve currently used algorithms. Point: most of the current game algorithms are part of someone’s thesis and research papers. (or invented by John Carmack)

Game programmers are often under pressure. There are always impossible deadlines. It is true that in such circumstances one can hardly read. The only thing they don’t realize is that often lack of knowledge (reading) is the reason for the nasty bug, not working solution, bad timing and unfinished deadline. (Well, bad project management also has its finger into this but this is another story.)

Someone once said on a news group: "I can understand why people write bad books, but I can’t understand the people who buy them."

One sad but very true fact is that if I write a book and people buy it I will earn money no matter how bad this book is and how wrong concepts I will distribute among the programming society. What is a bad book? Book that has mistakes, that is not complete on the topic, that provides fake knowledge, that does more harm to the programmer than help. Book that gives firm rules instead of guidelines.

I’ve heard many criteria about how to judge if a book is good or not. Here are some of them:

• find on the internet who are the experts, read the books recommend (or written) by them
• read one "good" book and see which books does it refer to
• ask fellow programmers about good books (potential danger, here)
• search web forums, read comments at electronic bookstores

I’d say that it is quite easy to investigate which books are the good ones. Take your time and visit some news groups, web forums and ask. After all it is your money. You want to spend them wisely, right?

This is my list of favorite books. Take heed that these are only books I read and I find valuable for every programmer like me. But you don’t have to trust me. Do your own research. Read other recommendations. Find out about the authors on the web.

Note: I haven’t put any game programming related books.

My programming language is C++. So I’ll start with some C++ books.

1. Introductory books on C++. These are the books that provide the basics. Reference on the simplest idioms and features of the language.

This is a minefield of books. If I saved a pound every time I see a book with "C++" in the title I’d probably save enough to buy my whole wish list of books. There are number of excellent books in this section but to keep it small I’ll mention only two of them.

"The C++ Programming Language"; Bjarne Stroustrup – I suppose that no comments are needed.

I started with Bruce Eckel and "Thinking in C++" for the only reason that it was available for free downloading on the web. (Sigh, money matters.)

2. Intermediate and advanced books on C++. Improve your knowledge. Find out what are the common mistakes and pitfalls found by experts and fellow programmers.

Scott Meyers:

Effective C++

More Effective C++

Effective STL

Mr Meyers has incredible style. I almost never started an Item (small chapter on a specific topic) without finishing it. I simply can’t believe that there are people who program in C++ and haven’t read his works.

"Modern C++ Design: Generic Programming and Design Patterns Applied" Andrei Alexandrescu (part of C++ In Dept Series)

Classical design patterns in generic form. Modern C++ idioms explained. Advanced knowledge for you: the advanced modern C++ programmer.

"Exceptional C++" Herb Sutter (part of C++ In Dept Series)

"More Exceptional C++" Herb Sutter (part of C++ In Dept Series)

"This is a remarkable book, but it wasn’t until I had nearly finished reading it that I realized just how remarkable it is. This could well be the first book ever written for people who are already familiar with C++ - all of C++." Scott Meyers

Although I haven’t read the whole "C++ In Dept Series" it is definitely something I consider doing this year.

3. Design Patterns and OO design.

"Design Patterns: Elements of reusable Object Oriented design" (often referred to as the GoF (Gang of Four) book)

Being extremely stupid I have always found OO design not so easy thing to do. Design patterns helped me to find the way in this often-dark tunnel.

Although this is an essential book there is a lot more about OO design, UML and designed patterns. I haven’t read more books on the topic (but some articles though) but that is certainly a field I should improve in.

4. Data structures and algorithms.

"Algorithms in C++" Robert Sedgwick

Classic programming algorithms can be implemented in every language. I remember an old book title: "Data structures + Algorithms = Programs".

There are thousands of data structures and algorithms books. This is essential part of the computer science. Recently I found out that a lot of fellow programmers are not aware of datastructures like heaps, graphs, trees although they use some basic form of them.

Of course if you are a game programmer be sure to check the game dev dedicated websites and specialized books for game related algorithms.

5. Code construction.

"Code Complete" Steve McConnell

This book turned upside down the way I was constucting my code. Made me ask myself if my code was good, readable, comprehensible. Pricesless list of guidelines, statistics, studies about programming practices.

The very best thing about it is that it offers guidelines and often describes something from differnt points of view so the reader can think for himself and then choose the position he like and is more comfortable with.

This is only a start. It is up to you dear reader to complete and extend it for yourself.

A question that I was asked by fellow programmers during my short programming career: "How do you know that I’m wrong and the people who wrote this book are right?"

Unfortuantely the answer is: "If you read it you would be able to say for sure if you are right or wrong."

We can’t judge something we don’t know about.

Programming is about knowledge. Without reading we are left without knowledge. And may be this is the rigth moment for us to ask the question: "Am I a genius? Can I invent everything I can read about?" And if the answer is no then we’d better acquire the knowledge rather than create it.