Java Puzzlers, by Joshua Bloch and Neal Gafter
(This review appears on Amazon's site.)
Java Puzzlers is a wonderful book that demonstrates how easy it is to fall into one of the numerous traps or pits that the Java language has strewn about. Even expert level Java developers make many of the mistakes that Bloch and Gafter show you how to avoid in Java Puzzlers.

The book contains about 90 brief programs. The authors ask you to read each snippet, think through it, and determine what the output of each program should be. Each program is always carefully positioned on the bottom right hand side, so that you can't see the solution beginning on the next page.

The code snippets don't just represent cute little problems that you come across when deliberately attempting to code poorly or with obscurity (like the code examples you might see in a Java certification exam). Most examples look like code you might see (and that I see quite often) in a typical app, code that on the surface looks like it should work just fine.

Bloch and Gafter explain the cause for each interesting result. They then tell you "don't do that," and patiently explain how to improve your approach so as to produce the correct code.

I really enjoyed Java Puzzlers, and along with Bloch's Effective Java (and of course Agile Java), it's one of the few Java books I can universally recommend. It will definitely make you a better professional programmer if you take its lessons to heart. As someone who's developed in Java for almost 10 years and written a couple books on it, I can guarantee you that you'll learn quite a bit from this book. I certainly did.

The book is a fun and quick read, and for me it contained some very interesting "wow" moments. The optical illusions (and the brief discussion of them in the back of the book) add to the attractiveness of Java Puzzlers.

Most of the coding errors demonstrated in Java Puzzlers should never see the light of production day. Unfortunately, many of them do. My only suggestion for the book would've been to include a bit of emphasis on how comprehensive unit testing would help eliminate these defects as soon as they're introduced. But if you want to learn how to do that, you can always check out Agile Java.

Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
An obvious choice for influential books, but it has its problems. It's not one of the easiest books to read, and it only shows C++/Smalltalk code examples. Other authors have tried to produce follow-on works for other languages including Java. None have succeeded in making things any better or simpler.

If you want to understand the now-10-year-old hype of design patterns, this is the book. It's about the only book I continue to use as a reference—for most other topics, the best references are on the web. Not so with Design Patterns. While you can find web sites that talk about the various design patterns contained within this book, they generally do not have the depth and breadth of discussions that the original book contains.

Anyone who considers them a software development professional should have at least read this book.

The Secrets of Consulting, by Gerald M. Weinberg
This book, subtitled "A Guide to Giving and Getting Advice Successfully," is one of the few books I re-read at least once a year. While the advice often borders on the obvious, there are many secrets that go counter to intuition. My personal experience has backed up the "secrets:" I've done both the right things and the wrong things, and the results have always gone the way that Weinberg predicts.

Secrets of Consulting is very easy to read and enjoyable. At about 225 pages, it is brief but packed with valuable information. Weinberg uses stories to help reinforce the ideas; each of these stories translates into some memorable rule of consulting. Normally, remembering a list of rules is difficult. But when they're named things like "Rudy's Rutabaga Rule," it's very easy to recall the jist of the guideline.

Extreme Programming Installed, by Ron Jeffries, Ann Anderson, Chet Hendrickson
Forget all the other dozens of XP books. If you want to learn how to apply the concepts set forth in Kent Beck's Extreme Programming Explained, the "pink book" is a great place to get started. Ron manages to distill the manifestos and philosophies into practical steps. Yet, unlike many of the other XP books, he manages to retain the "zen" behind doing XP. As usual, Ron manages to keep the book engaging and easy to read.

If there were any of the "XP Series" books that needed a rewrite, Beck's Extreme Programming Explained was one of them. That recently occurred; a second edition is now available. Let's hope that Extreme Programming Installed becomes the next and only other one. While little of the underyling practices, principles, and values in XP have changed, many insights have since been gained in the four years since this was published. I'm anxious to see how Ron updates things.

Agile Software Development: Principles, Patterns, and Practices, by Robert C. Martin
Don't confuse this book with the Alistair Cockburn book of the same name, which is also a good book. This is a hardback design book with what's probably a nebula (but what looks to be an exploding brain) on the cover.

Few people know more about design than Bob Martin, and no one makes reading about design more enjoyable. Bob knows his stuff! While this book takes you through a number of agile topics (how-tos, largely centered around XP), the core of the book is his thorough discussions of how to approach design in an agile manner. Yes, there is UML in the book, and yes there is code. In fact, there is a lot of both. Bob goes over classic design patterns from the Gamma book, and adds a number of very useful patterns to boot. He also presents comprehensive coverage of a set of named, but unfortunately not very well known, class and package design principles.

Using examples from C++ and Java, Bob talks about the nuances of these patterns. He shows you what actually happens when you try to take a design and implement it. Often we find out that there are things that you're just not going to consider when coming up with a picture (an approach) for a design. The Bowling Game example, reprinted here, bears this out. Bob and Bob Koss code a simple design for a Bowling Game, and find out that the planned design is nothing like the final implementation. If one of the best designers out there can't come up with a perfect design for such a small application, who can? It doesn't matter: Bob will show you how to proceed in the absence of perfection.