Probably all these books mean less than nothing for people that work in algorithm theory, low-level systems programming or AI. For designers of big systems nursing databases in commercial applications, however, Martin Fowler is the great guru and Object Oriented Design and Programming are the gospel.
Also, it is interesting how most Comp. Sci. departments ignore this whole culture.
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.)
The best thing that can be taught to undergraduates is the first principles of the field so that they at least have a solid foundation to build on.
I lament the loss of courses built on Structure and Interpretation of Computer Programs - one need only read this post by Joel Spolsky to see similar sentiments expressed:
Also, when facing a particular problem in a project or homework, instead of unconsciously reinventing the wheel, I can refer by name to a solution that is already implemented, or at least be aware that I'm reinventing a wheel.
While I'm not about to design an Enterprise Application by myself, I think I can at least work in such a context and understand better where's my part in the whole.
In my previous life as a platoon commander in the army, I was specifically trained to command a platoon. I was however given exposure as to what higher levels were doing, so that I could work with the whole formation.
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).
In fact I really love the whole pragmatic series because they focus on the craftsmanship and techniques surrounding it more than the specifics of a technology. Kind of like most of the books you have listed there.
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.
Brodie, Thinking Forth
Abelson & Sussman, SICP
Liskov & Guttag, Abstraction and Specification in Program
It's hard to stick to 5!
* The C Programming Language by Dennis Kernighan and Brian Ritchie
* Expert C Programming: Deep C Secrets by Peter Van Linden
* TCP/IP Illustrated Volume I: The Protocols by W. Richard Stevens
* The UNIX System by S.R.Bourne
* The Algorithm Design Manual by Steve S. Skiena
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 :)
As a 39 year old, my list is virtually identical to jijji's and most people I know who program and who are about the same age or older would almost certainly cite a huge overlap if not the exact same list.
When I read this list, my first thought was "I know exactly when you started programming, and the types of apps you were writing".
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).
For those who want a good overview and don't fancy the slog I'd recommend taking a look at http://www.infoq.com/minibooks/domain-driven-design-quickly - a 100 page summary of the book from InfoQ.
The original is definitely worth a read - the summary might let you see why it's worth the effort ;-)
I still don't get it why I've seen so few Node.js applications using Application Service layers, Domain Models and Repositories, and instead clog their MVC containers with calls to whatever datastore directly, with no Domain Model at all.
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.
That said, I would love to read a sequel that deals with more abstract objects that sync or authenticate or what have you.
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 thought DHH hated people talking about "enterprise" and "patterns"
I love talking about patterns when the discussion is centered around actual code. Which is exactly why PoEAA is so good.
I'm surprised that you didn't mention The Pragmatic Programmer..
I think that a lot of the people here (and who read your blog) could do worse than to check out "Team Geek". It's about people, not programming, but the impact it has had on me is equal to PoEAA..
I picked up my copy because I love Smalltalk, but I use a lot of those same patterns in Delphi, C#, and Python.
Also, interesting to note that only 3 out of the 5 books listed are on the 'best programming books' stackoverflow thread - http://stackoverflow.com/questions/1711/what-is-the-single-m...
My background is K&R, Code Complete, SICP and related books in the Scheme canon (HtDP, PLAI), and lots and lots of papers and blog posts. Having absorbed the fundamentals I find online material both more accessible and up to date.
Theres a cheaper kindle version of "Are your lights on?" ... http://www.amazon.com/dp/B004WOXYV2#tags
That's why I'd be quite interested in a comparison because Smalltalk is another excellent OO language (arguably the best for explaining concepts etc. but I'd say Eiffel is close enough)
Despite all the awesome C# language features, people are talking about DI, IoC, build tools, dependency management tools, continuous integration, DDD, ATDD, unit testing, refactoring, ORM, MVC, MVP, AOP, etc.
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.
I am finding this book to be very helpful in understanding proper Object Oriented Design. It explains concepts that I have struggled with previously regarding Object Oriented Design and Programming.
So far, the main point I have taken from this book is: Pay more attention to the messages being sent between objects rather than focusing solely on classes.
As someone who is learning Ruby, it is taking me some time to understand these concepts. However, this book is providing me with some valuable insights into Object Oriented Design and Programming.
But basically the "writings" that means the most to me are the ones making 75% of those that matter the most to you irrelevant ; )
"Pattern means 'I have run out of language'"