The Programming Books That Meant The Most To Me (opens in new tab)

I work for a company where our "suite" consists of 3 large components: a back-end system, a web-app, and software installed to the devices.

The back-end systems guy read mostly Java, JavaEE, EJB3.x (the better one of course), JMX, PostgreSQL (admin, performance, the usual drill) and everything that DHH mentioned.

The web-app guys read mostly front-end stuff (JS, Backbone, Underscore, MVVM/MVC/MVP technique, CSS spriting, YUI compressors).

The software/firmware/hardware guys are reading what you listed above (including Advanced Programming in the UNIX Environments, UNIX Network Programming vol 1-2, Windows Internals, etc).

Still relevant :)

The Peter Van Linden's book is the most fun and engaging programming book I've ever read (despite being a bit dated at the time I read it).

There's a limit to what can be learned in college, though. You can't teach CS undergrads patterns of enterprise architecture in a meaningful way any more than you can teach history undergrads the craft of writing a book when they're still only writing papers. Teaching them to absorb rules of craftsmanship without any personal experience to judge them by will only encourage them to become astronauts and "best practices" prigs. (Not to mention that the professors themselves might be relatively inexperienced and mediocre at those things.)

Same goes for the article. The author clearly thinks that these books have helped him succeed but unlike some essays there is no sense of him dissing other approaches. "that meant the most to me" He succeeded. But he didn't lose his perspective.

My alma-mater (UBC.ca), the CS Dept touches a few subjects:

- Design Patterns (still using GoF, which is probably not the right fit for 3rd year students)

- Refactoring (we do refer to Martin Fowler's book albeit we don't dig that deep)

- Barbara Liskov book (touches a few thing regarding type-systems and its relation with OOP, IN-OUT contract/verification, a bit more academic/formal but most of us saw her work in C# contracts, the L in SOLID principles, some of the OOP best practices probably).

SBPP is a classic for years, and POODR is new, so it's hard to make a comparison. SBPP takes a little bit more effort to apply to Ruby, as Ruby's features are a bit different than Smalltalk's. POODR is excellent, but the one thing that I don't like about it is that it uses the physical metaphor for objects: bikes and wheels and mountain bikes. Getting out of the mindset that objects were only for physical analogues was one of the hardest things for me to level up with in OO design, so that part was slightly disappointing. But everything else about POODR is great, and I'd recommend it to anyone who programs in dynamically typed languages.

Really, you should own and read them both.

Case and point: Singleton design pattern in Java (and JVM) vs Singleton design pattern in C++. Try implementing it in a production environment and make sure it is thread-safe, network-safe (can be sent through the wire), etc. You'll end up with different approaches.

I love talking about patterns when the discussion is centered around actual code. Which is exactly why PoEAA is so good.

That was the book that put me on a path 3 years ago from C# enterprise code monkey to being where I am today, as an independent Rails consultant. I never even heard of Rails before reading this book, let alone had any idea of the current tech landscape outside of the enterprise bubble.

When I quit my job 6 mos ago I reread it in an evening - startled to find that I actually adhered to a majority of the advice in the book, which at first read was mostly alien to me. I credit that phenomenon to Chad Fowler's subversively succinct writing style, it has that get under your skin, call-to-action quality to it.

Overall, I found that the book taught me a lot about looking for deficiencies in my own designs or what to look out for when weaving new functionality into an existing software project.