The Programming Books That Meant The Most To Me(37signals.com)
37signals.com
The Programming Books That Meant The Most To Me
http://37signals.com/svn/posts/3375-the-five-programming-books-that-meant-most-to-me
62 comments
Most academic departments don't dedicate classes to practical skills, but they do acknowledge them in curriculum planning. A history major won't see "How to structure a research paper" on the syllabus of any class they take, but that doesn't mean the professors don't intend to teach them. How to organize research notes, how to read a book, how to structure a paper or a program, and so on are supposed to be learned alongside the academic subjects that are listed on course syllabuses.
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.)
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.)
Unfortunately though, the desire to make curricula that are practical is increasingly infiltrating CS departments, only the academics have no idea what is practical, and end up teaching the language du jour that recruiters happened to be looking for 5 years ago which is out of date by the time students graduate.
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:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...
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:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...
I think exposing students to architectures and patterns can't be bad. As a student myself, I'm glad to have this exposure as I can now look at frameworks I couldn't really understand before, and at least make some (more) sense out of it. I can recognize the way things are named and organized.
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.
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.
Thanks for that bit of perspective. If every thread like this had a comment like that at the top we could all get where we are going a lot faster.
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.
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.
I'd say software is becoming more 'specialized'.
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).
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).
These are all good books. One I would add myself that has had the most impact on me is "The Passionate Programmer: Creating a Remarkable Career in Software Development". It used to be called something like how to keep your job from being outsourced but I think it does a good job of showing one how to be more than just a 9-5 programmer and really dive into the profession and distinguish yourself.
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.
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.
I would give you a +10 if I could.
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.
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.
I wouldn't even recommend the first couple from my list, today -- e.g. there are surely better intros to algorithms now. But here's an approximate top 5 for changing my programming when I read them.
Brodie, Thinking Forth
Sedgewick, Algorithms
Abelson & Sussman, SICP
Liskov & Guttag, Abstraction and Specification in Program Development
Norvig, PAIP
It's hard to stick to 5!
Brodie, Thinking Forth
Sedgewick, Algorithms
Abelson & Sussman, SICP
Liskov & Guttag, Abstraction and Specification in Program Development
Norvig, PAIP
It's hard to stick to 5!
I guess I grew up in a different time:
* 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
* 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 think you meant The C Programming Language by Brian Kernighan and Dennis Ritchie.
Unless there is another C Programming Language book that I am not aware of...
Nah, just different domains that's all.
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 :)
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 :)
I do think there is a "generational" (used loosely, as the generations here are much shorter than what we usually think of in terms of generations) component to it as well, just in the sense that what you consider the "software/firmware/hardware" guys were much closer to being the entire set of developers up until the early to mid 1990s than they are now. The concerns of today's embedded developer were the concerns of virtually everyone back then.
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.
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.
I agree.
When I read this list, my first thought was "I know exactly when you started programming, and the types of apps you were writing".
When I read this list, my first thought was "I know exactly when you started programming, and the types of apps you were writing".
Is The Unix System still relevant now?
It's just a good book written by one of the founders, and offers unique insight into the design and implementation of *nix systems.
I like that you included a Richard Stevens book. He is underrated IMO. I own 3 of his books.. pretty much taught me C. He really knows how to explain C in a clear, easy to understand way. Great for beginners who want to learn.
Great list.
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).
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).
I know that feeling :)
It actually made me interested in participate in the International Obfuscated C Code Contest. http://www.ioccc.org/
Nice to see Domain-Driven Design mentioned. As DHH said it's a bit of a slog - but worthwhile.
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 ;-)
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 ;-)
"Code Complete" by Steve McConnell. A practical tome on how to actually build large software systems.
As a junior in an ECE/CS program I cannot recommend this book enough. It will teach you things most classes can't/won't.
I've noticed this book is very popular among engineers (real engineers, with 4-yr degrees in engineering from accredited schools), but not so much with compsci people.
The professor for my software engineering class mentioned it briefly at the beginning of the semester, but it was never brought up again. If you don't do a lot of learning on your own, you're probably not going to encounter it.
I love the fantastic book Domain Driven Design written by Eric Evans too. Glad to see it is on DHH's top 5 as well. The concepts of that book (Entity, Value Object, Repository, Aggregate, Aggregate Root) have helped me a lot developing well written software.
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.
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.
Can anyone comment on "Practical Object-Oriented Design in Ruby" vs. "Smalltalk Best Practice Patterns"?
Disclaimer: I was a reviewer of POODR, and my name is in the 'thanks' section.
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.
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.
I like the bike/wheel/rental place examples; it helped me conceptualize what she was talking about.
That said, I would love to read a sequel that deals with more abstract objects that sync or authenticate or what have you.
That said, I would love to read a sequel that deals with more abstract objects that sync or authenticate or what have you.
The closer the book to the language you'd like to apply to the better it is. Nothing beats applying it in real-life regardless whether it's a classic or not.
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.
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 recently bought the ebook and have been reading it when I have spare time. So far I can say that the writing style has been excellent...and the concepts of OOP and how an abstract app is refactored under good OOP practices is so clear that I don't know if she's covering relatively basic OOP material or if it seems simple because she explains (and diagrams) it so well. I suspect it's more of the latter.
I was somewhat surprised to see "Patterns of Enterprise Application Architecture".
I thought DHH hated people talking about "enterprise" and "patterns"
I thought DHH hated people talking about "enterprise" and "patterns"
The "enterprise" bit is a misnomer for this book. Doesn't have anything to do with enterprise.
I love talking about patterns when the discussion is centered around actual code. Which is exactly why PoEAA is so good.
I love talking about patterns when the discussion is centered around actual code. Which is exactly why PoEAA is so good.
I'm not telling you anything you don't already know David, but Fowler and many of his peers and contemporaries grew up developing object-oriented systems that ran in large enterprises. You could read the title as "patterns we are using to build enterprise systems". That is primarily the market Thoughtworks continues to serve. Good code and design is much more broadly applicable, of course.
Fowler's writing is what makes the books so good: PoEAA is much more approachable than the GoF books. It's more approachable than his early books (Analysis Patterns).
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'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..
Rails is new J2EE, don't you see?)
Smalltalk Best Practice Patterns is one of my favorite books, my copy is incredibly beaten up. I just really like the way Kent writes.
I picked up my copy because I love Smalltalk, but I use a lot of those same patterns in Delphi, C#, and Python.
I picked up my copy because I love Smalltalk, but I use a lot of those same patterns in Delphi, C#, and Python.
Working my way through Structure and Interpretation of Computer Programs at the moment, and surprised it wasn't on this list.
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...
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...
It interesting to see a completely different background to mine. If I have one criticism of this list it's that it is very mono-cultural -- all OOP, nothing FP here, for example.
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.
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.
WARNING: I've not bought this so I don't know if its exactly the same as the paperback.
Theres a cheaper kindle version of "Are your lights on?" ... http://www.amazon.com/dp/B004WOXYV2#tags
Theres a cheaper kindle version of "Are your lights on?" ... http://www.amazon.com/dp/B004WOXYV2#tags
My number one book on a list like this would be Accelerated C++ by Andrew Koenig and Barbara Moo. The book is targeted at beginners, but is challenging and very intelligent. Koenig is concerned with teaching good practices and overall design. It was one of the first programming books I ever read and I struggled through it at first. By doing every exercise and persisting, I think it played a significant role in the kind of programmer I am today. To me the book is in a similar space as SICP. Sadly it's now out of date, but at least was written using the STL.
If you're into C++, definitely check out the books by Scott Meyers (Effective C++, More Effective C++, Effective STL). They're not "how to get started" books, they are "how to fix the stuff you are doing wrong" books. He is very insightful and writes very clearly. He also has a sense of humor, so look for little jokes in the index.
[deleted]
"Pragmatic Programmer"
How does the Smalltalk book compare to "Object-Oriented Software Construction" by Meyer? The latter is my goto OO book (in combination with "Object Oriented Design Heuristics" by Riel)
It is better. C++ is not what the creator of OO had in mind. (Smalltalk is).
"Object-Oriented Software Construction" uses Eiffel which is an excellent OO language especially for explaining certain OO related concepts. Preconditions, postconditions, invariants (design by contract) etc.
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)
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)
"Are your lights on" is a fantastic book, my high school comp sci teacher lent me a copy and i've read it many times since then, always getting a little something new from it.
It is interesting to note that DHH reads books that most Java developers read as well :) (and soon the C# people, since y'all are typically a few step behind the Java crowd).
This comment reads especially funny when you realise that most of the new language features in last Java are somewhat reminiscent of the C# features that were around for, well, quite some time.
Language features are not the topic that these books focused on. Techniques, libraries, and tools are what the communities of Java and C# focused on.
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.
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.
In addition to all the other patterns books mentioned, Head First Design Patterns is a great intro the subject. I think you will get more out of GoF if read this first.
I've been considering reading Fowler's Refactoring book, but I haven't written Java in 10 years. Is the book accessible to someone with minimal Java knowledge?
Certainly! I've never written a line of Java but I had no trouble following the examples in the book. The naming of variables, methods, etc. makes for easy reading without any Java knowledge. You just need to be able to identify a class and the public/private members and variables. That isn't a problem in Java.
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.
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.
8 Books---All by D. Knuth, The 4 on algorithms and the 4 on Typesetting. Not to forget the article on DDJ long ago that started it all for me.
Our team found Rails Antipatterns to be a useful survey of common real-world issues and how to address them.
"On Lisp"
"Programming Erlang"
PAIP
"Programming Erlang"
PAIP
First, the Paul Graham's article "beating the averages" and them On Lisp!
I would also add Refactoring to Patterns by Joshua Kerievsky.
I am currently reading Practical Object-Oriented Design in Ruby: An Agile Primer by Sandi Metz (http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-...)
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.
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.
For me it's not necessarily books: it can be essays, blog entries, thesis, articles, etc.
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'"
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'"
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.