Beyond Legacy Code, David Bernstein
This is my most recommended book. I really like, and agree with, his idea that this book is a "Why To". It's WHY we want to develop software in the industry recognized (current) best practices way.
The reason that this is my most recommended book is that it can provide valuable information to EVERYONE involved with software development. A lot of other books I suggest will be pretty dev specific. This is a standout of being important for everyone involved to read.
I'm not saying that this book could be read by everyone on the team (including managers and product owners); I'm advocating that it SHOULD be read by everyone on the team.
It provides insight into... as David says, the 'why' we want to develop software following certain practices. While I know it can help both technical and non-technical roles understand the why better; That's the no biggest value I see from having the entire team read it.
The value of having the entire team read "Beyond Legacy Code" is that it will establish a common vocabularly. It will provide a foundation to have conversations. If there's questions on meaning, or reasoning - The book can act as the arbitrator of those disagreements. It can help the entire team move forward in producing higher quality software by enabling their communication to be more informative.
What it helps the team talk about is vastly important as well; and it helps the talking go smoother.
Growing Object Oriented Software, Nat Pryce & Steve Freeman
My review - Pending
I should have read this book years ago. I should have read it the day I got it. I didn't; I suffered.
Honestly, I'm not sure I would have gotten as much value out of it as it holds. It's a book that will probably take more than 4 passes to get where the insights are far apart.
I really question if I would have been capable of really getting the value from the book when I got it.
I wish I'd tried.
There's a lot of books I have read that didn't help me. Even when I understood what they were saying to do; they didn't make my code better. This could have... and I missed it.
If I failed to understand it; my understanding now would have highlighted there was some book that could have helped. It's the only one I can think of that would have actually been a potential, "I didn't understand it, that's why it took me longer". A lot of books tend to be more, "It doesn't tell me the underlying assumed requirements after this becomes useful".
This has A LOT of great insights. If you've read it before, read it again. I've made more notes in this book than any other.
Definitely one to read, even if you don't understand everything.
A Philosophy of Software Design, John Ousterhout
My review - Pending
This book added more terms to my vocabulary than other other. It's has had a huge impact on my understanding and communication about why good software looks like it does. It's literally a book about the philosophy of software design.
The ideas presented strongly reflect the practices I've found value in. A lot of what the book presents are results I've seen from working in the MicroObjects style.
Narrow interfaces, deep modules.
Define errors out of existence.
All great things and all result we see when we apply the microobjects practices.
I suspect this will provide a lot of opportunity for discussion. On its own, I don't think that it'll be an immediate help to developers. There's a lot of ways this could be mis-applied. Almost every chapter has a "taken too far" section. I probably fall into this for a few things. I take my practices to the extreme, to see the extreme results. So far... I like what I see, even if this book disagrees with how far I go; we're going for the same thing.
Agile Software Development, Robert C. Martin
My review - Pending
A really great book for some of the guiding principles of software development. A number of great design patterns.
There's a few patterns that he basically says that, "You'll probably not need this often"... It's good to have them known, but not at the level he goes into, IMO, for this book. There are a lot of frequently used patterns he covers and I think more should have been squeezed in instead of infrequently used patterns.
The package level practices and patterns he covers is really important to successful code sharing.
I've seen a number of developers and teams that suffer from package explosion. If they follow the practices laid out here; I don't think the could have gotten into the situation they have.
Read this book. Keep it around for reference.