Part of being a good software developer, is constant learning. Without reading, listening to pod casts, and in general improving ourselves our knowledge quickly fades and becomes outdated at best. On the other hand finding the right books is a challenge on it's own right. Many people will tell you, that books will not tell you anything useful, since they are written by people who were not successful at practicing their craft. That is true of certain books - I read many, that should not have been written to begin with - so I decided to write a few words on each book I read, and found useful, so that others have place to start when looking for something to read. This section will be extended when ever I find a good book.
General software development
A. Hunt, D.Thomas
It's never easy to tell what is the best way to approach a problem. Software development is full of decisions. While many books on software development "methodologies" will try to tell you exactly how to work, this book will give you a huge number of ideas that you can use to improve the way you work. What makes this book one of the most useful ones, is that it breaks away from well marketed dogmas, and focuses on what is believed to work in practice. This book is a good foundation, it introduces most of the best practices at least at a basic level and tells you when and how to (or how not to) use each.
E. Gamma, R. Helm, R. Johnson, J. Vlissides
Object oriented programming was one of the most important advances in our industry since it's birth. A well designed object oriented code can be way more modular, and much easier to change than a procedural equivalent. How ever using objects in a procedural code won't bring you this flexibility. The gang of four introduces some of the most useful techniques to modularize your design, and break up dependencies as far as possible. Learning these patterns, and practicing them will make you a much better software architect, and a much better programmer in general.
I hate to break the bad news, but there is no such thing as perfect design. No matter how carefully you separated parts of the program into modules, packages and classes, eventually you will realize, that something is off. (The very reason Waterfall and RUP fail in so many odd ways.) So the day will come, when you wish you did something differently. Most young programmers fall into one of two traps: either they start introducing globals, and other evil structures into their program until it becomes an unmaintainable monstrosity, or they throw away the entire code base they've been working on, and start over only to end up with another disaster. The solution is to understand the practice of refactoring: the changing of a programs structure without changing it's observable behavior. Fowlers book is an excellent introduction into the field, and contains a refactoring catalog, that will remind you when each refactoring can be used, and how to perform them safely, without risking to introduce bugs. By using the practices introduced in this book you can become a better programmer, one who doesn't have fear of design flaws, because she knows that she can fix it in a matter of minutes. (Before reading this book, you might want to read the Design Patterns book first.)
R. C. Martin (Uncle Bob)
Martin Fowler in his book wrote: "Any fool can write code that the computer understands. Good programmers write code, that humans can understand." Uncle Bobs book is a crusade on bad code, code that only computers can understand. The author presents a list of heuristics and smells that can help you in identifying hard to understand parts, and turn them into easy to understand prose that happens to be also executable by a PC. Your fight against bad code shall never be over, but this book will train you to be a first class warrior. The book introduces many OO design principles, and does it in an easy to read anecdotal style. Once you start reading, you won't be able to put it down, and the thoughts in it will stick into your mind whatever you do. Be careful, clean code is addictive.
R. C. Martin (Uncle Bob)
The Clean Code book tells you how to recognize where you can improve your code. The Clean Coder however focuses on your own improvement as an employee. How should you behave? When should you confront your boss, or your employees? What practices should you stick to by all means? This book has the same anecdotal style as the other one mentioned by the same author, and it's just as useful. For a more in depth review in Hungarian, you can watch my presentation on it on YouTube I held at an Agile meet up.
S. S. Skiena
Learning how to tell the computer what you wish it did is one thing. Knowing how to make the process as effective as possible is another one. Unfortunately not all programmer courses put enough emphasis on algorithmic design, and even if they do programmers tend to forget most of what they learned since most of these techniques are rarely needed at a day to day job. Non the less, when algorithmic problems do come up - and they always do - they can hurt you big time. Sometimes a simple change to your method can speed up your algorithm by a factor of a million or more, but many times it's not straightforward what needs to change, and how it has to be changed. The ingenuity of Skienas book lies in it's structure. It introduces the basics first, which is useful on it's own, but the best part is the catalog of algorithms which takes up most of the book. When you find out which class of algorithmic problem you are facing, you can just look it up in the catalog, which will give you staring points on designing, and analyzing your algorithmic solutions. It provides the very information that you have already forgotten by the time you would need it. This book should be at hand on the shelf (or e-book reader) of every serious programmer.
This one is not really a book, more like lecture notes, and it's only available online behind this link. (There is also a Hungarian version there, and both are free.) It is a bit more detailed as Skienas book, and it's structure is more fit for learning the theory (along with proofs) once than looking back periodically. Still I believe, that reading it will make you a better programmer in the long run, but don't be disappointed if you don't get it all the first time. This is a hard to read book, and you may need to go through it a few times before you get it all. (Especially if this is the first book you read on algorithmic complexity.)
Project management related
Kent Beck was a pioneer in agility. His Extreme Programming methodology - which is defined to take agile values, principles and practices to the extreme - was a trigger to the whole Agile movement, and the Agile manifesto. The book first presents the values, principles and practices behind XP, and gives advices on practicing and introducing it.
D. J. Anderson
Kanban finds its origins in manufacturing and David Anderson has applied it for software development. It introduces a "Kaizen" culture (continuous process improvement) through the implementation of a pull system on the production line. I believe it is most useful in operating teams that maintain an existing system, or where nature of the tasks is highly unpredictable, priorities change quickly. This book is not an easy read but it's very useful, so be patient while reading it.
C++ is one of my favorite languages: it's a nice middle of the road between extremely effective early languages like Fortran or C, and modern easy to use, but inherently slower languages like Java or Python. However this flexibility comes at a price: C++ is a language full of pitfalls... well... actually more like land mines. The Effective C++ series by Meyers is a very good collection of rules that helps you avoid running on mines while programming. The first book in the series focuses on the language itself, and introduces the most important rules along with an explanation of the problems that can be avoided.
The second book in the series moves on to discuss the techniques and pitfalls related to the standard template library. If you have some basic familiarity with C++, than reading the first two books in the series should be enough to become a fairly good C++ programmer.
The last book also concentrates on the language features, but focuses on more advanced techniques that may not come up for everyone. These more subtle topics are a bit harder read than the first two books, but they are just as useful.
N. M. Josuttis and D. Vandevoorde
Templates are a very important part of C++, and not many people understand them well enough to use them to their full potential. Still this book barely made it into this list, since the first two parts of the book is more concerned with language design, than with actually using the language. The third and fourth part (Templates and Design, Advanced Applications) are however extremely useful. It introduces many basic techniques to unleash the real power in templates. So all in all: skim through the first part, skip the second part, and take your time with the third and fourth. The ideas presented there will help you in recognizing computations that you can push to compile time, thereby making your software more effective, and more reliable (compile time failure is much better then runtime failure).