The Five Most Influential Books to Me as a Developer
I remain one of the few people in irc://chat.freenode.net/##java who will consistently recommend a Head First book. But there’s only a single book from that series that I’ll recommend - Head First Design Patterns.
Why do I recommend it? My recommendation is based on personal and sentimental reasons. You may think what you will about the Head First series of books, and you would probably be correct, but this specific book was one of the books that really changed my frame of mind around programming… more on that in a bit.
The most recent time I recommended Head First Design Patterns, it started a series of thoughts in my head about the programming books that have influenced the way I work the most. Picking books I’ve read from my past is something I’ve never really explored until now. I figure this activity is now due since I’ve finally been developing long enough to actually have retrospective to apply to this subject. I now give you my (current as of the time I write this) Top 5 Most Influential Books to Me as a Developer
I list this book first since it is the first book I’ve read with an interest towards learning a general purpose programming language to do more things than just the absolute minimum amount of scripting. Prior to this I read books on databases and on Linux, but never one that taught programming. I’m still not entirely sure what made me want to visit writing code in the first place but for some reason I did, and a certain amount of searching lead me to this book.
At the time, Think Python essentially competed with Mark Pilgrim’s Dive Into Python book as the common “free and online introductory python book” that was recommended. I was drawn to this book mostly because of how it introduced concepts pretty seamlessly with code whereas I thought Dive Into Python was entirely more skewed toward pacing you through syntax and API. I was in need of far more than a syntax and API primer at this point - which you can read as that I needed a certain amount of handholding.
What I loved about this book was that it introduced trickier concepts to you in a very gentle way… e.g. how assigning a variable in a language like python really means you are assigning a name to a reference of an object. I see this sort of thing trip up newbies all of the time in Java. Did I mention that figuring out just what the heck an object is, which is a rather difficult abstract concept to nail for an absolute newbie, was made fairly simple by the book too?
If I was asked by a high school student who was interested in learning how to write computer programs but hasn’t started yet, this is the book I’d tell them to start with.
About the time I started learning Java, I really didn’t understand how to write Object Oriented code. Basically, everything I wrote was a poor abstraction over some concept that ultimately delegated to some other poor abstraction of another concept and it all might have been greatly simplified if I just scripted all of my work in one big giant method (sad but true!). I had very tight coupling and little to no usage of composition in any code I wrote. At some point, I checked out a copy of the GoF book from the University library, but reading that popular tome left me with more questions than answers (when would I ever is this Flyweight thing if I’m not rewriting a word processor?!). That prompted me to go a simpler route to explore the subject matter of improving my code organization, and one could not go much more simple than a book written in a very graphical and example driven style of pedagogy.
Once you get past the fact that there are stale images of emo teenage models with bubble dialogues talking about how a Tiger jumping at you will make you absorb new material more efficiently, you’ll come to realize, as I did, that this is really a great introduction into how to think about and write good Object Oriented code. Head First Design Patterns is not a great reference catalogue that covers all details, advantages, disadvantages, and lots of conceptual minutiae about each and every pattern. Instead, the book talks you through the most simplistic of examples. Instead of examples where you are building a Word Processor or some other non-trivial real world application with scary (to me at least) C++ code, the examples work you through things like building a silly encapsulation of a Pizza Parlor (in the case of the Factory Pattern) with reliance only on small code snippets. But despite being simplistic, one read through each chapter was enough to understand the basics of what the hell was going on in a given pattern.
As an anecdotal example of how effective this was, I never really understand why the classes in java.io were written the way they were until I finally read the Head First Design Patterns chapter on Decorators.
While reading this book, I began thinking more about and writing more loosely coupled code and that used patterns here and there where applicable. In short, I finally understood OO beyond the textbook definition.
Bloch’s Effective Java was influential in the sense that it was the first time I stopped performing cargo cult programming and started thinking about why code was written the way it was and what certain idioms existed in Java, which is the language I was getting paid to use at the time and the language I still get paid to use today. I started using immutability (even before knowing much about FP) when writing domain classes and I understood why I was doing it - which at the time it was a pretty decent way I could preserve class invariants.
Overall, there isn’t anything earth shattering about Effective Java. But that doesn’t keep it from being one of my favorites and something I still come back to often.
I read this book by Kent Beck sometime around 2011. I had spent a couple of years doing more build engineer/ops style of work and away from application development. However, during those dark ages I came across this book and it has changed the way I’ve programmed since. Prior to reading this book, I never performed TDD at all. In fact, I had very few automated tests whatsoever for my code.
Beck wrote this book in a very informal and conversational manner. Almost as if he were narrating to you as you watched over his shoulder. Thought it wasn’t immediate, I eventually started groking TDD a couple of weeks after reading this book and stubbornly trying to practice TDD.
Now, if it’s new code that I’m writing, there’s about a 95% chance I’m quickly writing a failing test first before I write the code. As I’ve mentioned previously though , this isn’t just about ensuring correctness about my code, but it is also about putting a very loud guard in front of the assumptions I’m making while programming so that other developers, including my future self, will be warned when they touch production code in significant ways.
Right about the time I read Test Driven Development By Example and shortly after my foray into build and ops work, I started performing consulting in the ESB and SOA space. I was already vaguely familiar with Enterprise Integration Patterns, having dabbled a good bit into Mule and a small bit into Apache Camel. Though where reading the GoF book for design patterns really did me no good at the time I read it, Hophe’s tome was a venerable godsend.
It is entirely one thing to think about how to write decent object oriented code for a specific app that is loosely coupled and easily extendable, but an entirely different thing altogether to design and think about architecting a large system of heterogeneous apps and services that depend on processing high loads in a highly parallelized way to scale appropriately while also providing guaranteed messaging and many other such non-functional concerns. This was the book that at least helped me define what the toolbag is and helped fill in the “why” part of how these perplexing constructs came to exist in libraries and tools such as Mule and Camel.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)