Book Review: Java Puzzlers

Book: Java Puzzlers

Authors: Joshua Bloch and Neal Gafter
Publisher: Addison Wesley
Pages Read: all
Sections: all
Thumbs up/Thumbs Down? Up, slightly sideways
Link: Amazon

Summary of Content Read

Java Puzzlers is not so much a book, but a collection of obscure corner cases in the Java programming language.  The author (Joshua Bloch) is well known as the author of "Effective Java" which is widely regarded as the premier text for the language, and furthermore he is one the designers and authors of the Java Collections Framework.  So to say the least, he knows his stuff.

Each chapter of the book features a collection of "puzzlers" centered around a particular section of the language (examples include loops, strings, exceptions, classes, etc).  Each "puzzler" is formulated where a puzzle (typically in the form of a code snippet) is given, and the reader is encouraged to try and predict what the output will be, or why the code is incorrect.  Then an answer/explanation of the puzzler is given.  All-in-all there are 95 different puzzlers across the book, and they range from the fairly common "if you thought about it a bit you'd figure it out" to the extremely obscure "unless you were a Java language designer you'd never have any hope of figuring this out".  The explanations also often include commentary to language designers (ex: "the lesson for language designers here is..."). 

From an academic "curiosity" point of view the book is quite intriguing.  As a fairly experienced Java developer I found myself surprised with the vast majority of the puzzlers.  The programming languages guy in me found this fascinating (ex: wait, so you can have Unicode literals in comments, and those literals are interpreted by the compiler?).

Having said that, the book does reach a point where the puzzles and concepts hit upon by the puzzles are extremely obscure.  For a typical Java developer you'll almost never run into most of the tidbits in this book.  That's not to say that reading it isn't useful, you'll definitely learn a bit about the book, but if you're looking to learn "how to write good Java code" this is not the book for you (again, see Bloch's other book for that).

Book Review - The Clean Coder

Book: The Clean Coder - A Code of Conduct For Professional Programmers

Author: "Uncle" Bob Martin
Publisher: Prentice Hall
Pages Read: all
Sections: all
Thumbs up/Thumbs Down?  Up
Linky: Amazon

Summary Of Content Read

This book is largely a follow-up to Martin's other very well known book "Clean Code".  Whereas that book focuses on the artifacts (code) we developers produce this book focuses on the developer his/herself.  How should we as professional developers act?  What is the difference between a commitment and estimate?  What are our responsibilities?  When can we say no & how do we do it?  When are we obligated to say yes?  How do we get better at what we do?

Martin tries to distill his nearly 40 years of experience into some hard fought lessons.  While it is very much appreciated to hear "tales from the trenches", the book does have a fairly heavy-handed "do as I say" tone.  Don't do TDD?  Well then you're not a professional.  Do you create ambitious estimates?  Well then, you're not a professional.  From a rhetorical point of view, the book does rely on this "proof by appeal to professionalism" approach, rather than give solid evidence and data to back up many of the arguments he makes.  For example, the TDD chapter has the passage:

Yes there have been lots of controversial blogs and articles written about TDD over the years and there still are.  In the early days they were serious attempts at critique and understanding.  Nowadays, however, they are just rants.  The bottom line is that TDD works, and everybody needs to get over it.

I feel like the paragraph should have ended with "QED".  Hardly a conclusive argument in favour of TDD, and the off-hand dismissal of any critiques of the practice really does hurt the point he's making.

Having said all this, it is certainly clear that much of what he offers is good advice, and represents an open challenge to developers to be better.  If you put aside the "if you don't do this you're not professional" rhetoric, at its core this book is a call for developers to live up to the responsibility of the job they have been hired to do.  Oftentimes we as developers like to silo ourselves off, focus on our narrowly defined technical tasks, and that is simply unrealistic.  Part of the responsibility of being a developer is to understand the context of the work you do, why it's important and why it adds value to the customer/client/business/etc.  And if that value isn't there, it's up to you to find it.

As such I found this book both refreshing and terrifying.  Refreshing to hear a voice from the agile community who doesn't seem to feel that the PO is the only entity responsible for identifying value. 
Terrifying to think that I, as an introverted software developer, has a duty to do more than just simply write good, clean code.

In terms of structure, the book is divided into 14 different chapters each covering a topic of interest to professional developers.  While there is some technical discussion, it is relatively rare, by in large the chapter topics focus on "soft" skills rather than technical ones.

All-in-all, while heavy-handed and at times "preachy", it is very much a worthwhile read for anyone considering or living a career in software development.