
The Programming Books That Meant The Most To Me - dcope
http://37signals.com/svn/posts/3375-the-five-programming-books-that-meant-most-to-me
======
diego_moita
Interesting how software is becoming a diversified culture.

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.

~~~
dkarl
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.)

~~~
savonarola
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...](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html)

------
ianstallings
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.

~~~
brandall10
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.

------
abecedarius
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!

------
jijji
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

~~~
edwinnathaniel
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 :)

~~~
georgemcbay
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.

~~~
lrobb
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".

------
adrianhoward
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 ;-)

~~~
Glide
I second this. I made my company buy about 4 copies of this book and some
others to pass around to the team I am on about a year ago.

------
billg32
"Code Complete" by Steve McConnell. A practical tome on how to actually build
large software systems.

~~~
zgm
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.

~~~
billg32
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.

~~~
zgm
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.

------
jorgenhorstink
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.

------
doktrin
Can anyone comment on "Practical Object-Oriented Design in Ruby" vs.
"Smalltalk Best Practice Patterns"?

~~~
steveklabnik
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.

~~~
alxndr
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.

------
jiggy2011
I was somewhat surprised to see "Patterns of Enterprise Application
Architecture".

I thought DHH hated people talking about "enterprise" and "patterns"

~~~
dhh
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.

~~~
jeremyjh
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.

------
malbs
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.

------
xmanifesto
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...](http://stackoverflow.com/questions/1711/what-is-the-single-most-
influential-book-every-programmer-should-read)

------
noelwelsh
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.

------
keeptrying
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>

------
city41
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.

~~~
Bill_Dimm
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.

------
g2e
"Pragmatic Programmer"

------
kriro
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)

~~~
billsix
It is better. C++ is not what the creator of OO had in mind. (Smalltalk is).

~~~
kriro
"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)

------
buzz27
"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.

------
edwinnathaniel
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).

~~~
smartial_arts
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.

~~~
edwinnathaniel
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.

------
zgm
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.

------
dbecker
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?

~~~
justnoise
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.

------
hsmyers
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.

------
pardner
Our team found Rails Antipatterns to be a useful survey of common real-world
issues and how to address them.

------
dschiptsov
"On Lisp"

"Programming Erlang"

PAIP

~~~
jcmoscon
First, the Paul Graham's article "beating the averages" and them On Lisp!

------
manojlds
I would also add Refactoring to Patterns by Joshua Kerievsky.

------
IgorP
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-...](http://www.amazon.com/Practical-Object-Oriented-Design-Ruby-Addison-
Wesley/dp/0321721330/?_encoding=UTF8&keywords=Ruby%20Object%20Oriented%20programming&tag=produc05-20&linkCode=ur2&qid=1356544606&camp=1789&sr=8-1&creative=9325))

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.

------
martinced
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'"

