A few nights ago I was over at my local Fry’s looking for a battery charger and a new Compact Flash card for my camera when I stumbled upon the book Driving Technical Change by Terrance Ryan. I think it was the distinctive look of a Pragmatic Bookshelf title that caught my eye. I picked it up, glanced over a few pages, said “what the hell,” and bought it. The book weighs in a bit under 150 pages so it’s a pretty quick read. Even with my slow reading pace and note taking I managed to make it through the book in just a few hours.
For me, the most value came from the discussions about:
- Properly handling data hiding through closures.
- Properly handling inheritance.
- Working effectively with arrays.
- Using subscript notation rather than dot notation to avoid eval.
- The custom utility methods such as Object.create, Object.superior, and memoizer.
Many of my issues with this book stem from some statements in the preface:
This is not a book for beginners.
This is not a reference book.
Including the appendices and index the book is only about 150 pages long but I found it to be full of fluff. It really seemed like the author was struggling to reach 150 pages.
- Chapter 9 is four pages describing the coding conventions used in the book (shouldn’t this have been at the beginning?) and why style is important (shouldn’t experienced programmers already be aware of this?).
- Chapter 10 is two and a half pages about the author’s inspiration for writing the book and why excluding the bad parts is important.
- Appendix E: JSON explicitly states “It is recommended that you always use JSON.parse instead of eval to defend against server incompetence,” but then spends the next four and a half pages on a code listing showing an implementation of a JSON parser! If it is recommended that JSON.parse always be used why include the listing?
- Railroad diagrams are useful but many of them take up huge amounts of space. The fact that they were repeated in Appendix D just stretches the length of the book another 10 pages.
Although the book has a repetitive, drawn-out structure I still think the information it contains is valuable enough to make it worth reading. As a supplement I highly recommend watching Mr. Crockford’s Google Tech Talk covering much of the same material. The video covers many of the book’s high points and even touches on some topics not included in the book. In some ways I actually think the video is better than the book even though it doesn’t get quite the same amount of detail on some of the topics.