This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

268

One of the most important question ever asked on stackoverflow :)
–
SROJun 9 '09 at 19:30

Interesting this is, while the title reads "What is the single most influential book every programmer should read?", there are quite a few books suggested that deal with language specific topics. By definition, and by question as it was put, the books suggested here should deal with language agnostic topics, which proves most programmers have yet to learn how to read.
–
ldigasOct 2 '09 at 19:54

19

If I could go back in time and tell myself to read something, it better be a newspaper or sports fact book that I carried with me. Anything else is a waste of good time travel. :-)
–
jmucchielloNov 8 '09 at 9:38

32

You know, if I wasn't worried about getting down voted a WHOLE lot I would trollishly go and suggest Twilight. "Its ALSO about people who are pale and avoid the sun!"
–
Jacob BellamyFeb 12 '10 at 0:20

You should already know everything in this book. Really.
–
Tim WilliscroftJan 12 '09 at 6:22

416

Everyone always recommends this book, but no one ever says why, which leaves me with the opinion that everyone must have been brainwashed. :P
–
deviosJan 17 '09 at 3:19

76

I read this book 3 years into my career. I hadn't taken a software engineering course nor a programming language constructs course but had taken some intro CS courses. It is by far the best single book I've ever read for becoming a better programmer. It won't make you a specialist but it will make you much more than a tinkerer.
–
ArnsheaApr 25 '09 at 16:11

119

The problem with this book is that for a beginner, it doesn't really make sense as the concepts are a little advanced. By the time you are ready to be able to read it, you should already know and practice 99% of the concepts in the book.
–
esacApr 30 '09 at 1:46

57

That's the deal with common sense suggestions, like those found in this book. Every so often you need to be reminded of them to fall back in line.
–
JohnFxJun 17 '09 at 15:56

@Juan: I know Juan, I know - but there are some things that can only be learned by actually getting down to the task at hand. Speaking in abstract ideals all day simply makes you into an academic. It's in the application of the abstract that we truly grok the reason for their existence. :P

@Keith: Great mention of "The Inmates are Running the Asylum" by Alan Cooper - an eye opener for certain, any developer that has worked with me since I read that book has heard me mention the ideas it espouses. +1

While this doesn't teach you programming, it teaches you fundamental mathematics that every programmer should know. You may remember this stuff from university, but really, doing predicate logic will improve you programming skills, you need to learn Set Theory if you want to program using collections.

There really is a lot of interesting information in here that can get you thinking about problems in different ways. It's handy to have, just to pick up once in a while to learn something new.

The idea being that there are failing parts in any given piece of software that are masked by failures in other parts or by validations in other parts. See a real-world example at the Therac-25 radiation machine, whose software flaws were masked by hardware failsafes. When the hardware failsafes were removed, the software race condition that had gone undetected all those years resulted in the machine killing 3 people.

Also check out The Systems Bible by the same author (John Gall). It's the third edition of Systemantics, he just changed the title. This is the book you'd steal from school. It's the book that grown adults read under a blanket with a flashlight.
–
C. Lawrence WenhamNov 27 '10 at 17:16

Extreme Programming Explained: Embrace Change by Kent Beck. While I don't advocate a hardcore XP-or-the-highway take on software development, I wish I had been introduced to the principles in this book much earlier in my career. Unit testing, refactoring, simplicity, continuous integration, cost/time/quality/scope - these changed the way I looked at development. Before Agile, it was all about the debugger and fear of change requests. After Agile, those demons did not loom as large.

This book explains a lot of things about software engineering, system development. It's also extremly useful to understand the difference between different kind of product developement: web VS shrinkwrap VS IBM framework. What people had in mind when they conceived waterfall model? Read this and all we'll become clear (hopefully)

Excellence in programming demands an investment of mental energy and a dedication to continued learning comparable to the professions of medicine or law. It pays a fraction of what those professions pay, much less the wages paid to the mathematically savvy who head into the finance sector. And wages for constructing code are eroding because it's a profession that is relatively easy for the intelligent and self-disciplined in most economies to enter.

Programming has already eroded to the point of paying less than, say, plumbing. Plumbing can't be "offshored." You don't need to pay $2395 to attend the Professional Plumber's Conference every other year for the privilege of receiving an entirely new set of plumbing technologies that will take you a year to learn.

If you live in North America or Europe, are young, and are smart, programming is not a rational career choice. Businesses that involve programming, absolutely. Study business, know enough about programming to refine your BS detector: brilliant. But dedicating the lion's share of your mental energy to the mastery of libraries, data structures, and algorithms? That only makes sense if programming is something more to you than an economic choice.

If you love programming and for that reason intend to make it your career, then it behooves you to develop a cold-eyed understanding of the forces that are, and will continue, to make it a harder and harder profession in which to make a living. "The World is Flat" won't teach you what to name your variables, but it will immerse you for 6 or 8 hours in economic realities that have already arrived. If you can read it, and not get scared, then go out and buy "Code Complete."

Each book was amazing but the Innovator's Dilemma by Clayton Christensen (1997!!!) is really a fantastic book, and it got me really thinking about the modern software world. The challenge addressed is disruptive technology, and how disk drive companies and non-technical companies are always disrupted by new, game changing technology. It gives one a new perspective when thinking about Google, probably the biggest 'web' company. Why do they have their hands in EVERYTHING? It's because they don't want to have their position disrupted by something new. The preview on google is plenty to get the idea. Read it!

I think starting new programmers with Python would reduce the amount of ugly code in the world. I work with someone who randomly indents lines - that person wouldn't do that if they had worked with Python for a few months.
–
xnineOct 25 '10 at 5:56

6

I think starting new programmers with Python would reduce the amount of other languages.
–
Marco MarianiOct 25 '10 at 8:51

I think that "The Art of Unix Programming" is an excellent book, by an excellent hacker/brilliant mind as Eric S. Raymond, who tries to make us understand a few principles of software design (simplicity mainly). This book is a must for every programming who is about to start a project under Unix platform.

While I agree that many of the books above are must-reads (Pragmatic Programmer, Mythical Man-Month, Art of Computer Programming, and SICP come to mind immediately), I'd like to go in a slightly different direction and recommend A Discipline of Programming by Edsger Dijkstra. Even though it's 32 years old, the emphasis on "design for verifiability" is highly relevant (even if "verifiability" means "proof" instead "unit tests").

What's so special about it? Well, clearly everyone has heard the term "Agile", and it seems most are believers these days. Whether you believe or not, though, there are some deep principles behind why the Agile movement exists. This book uncovers and articulates these principles in a precise, scientific way. Some of the principles are (btw, these are my words, not Alistair's):

The hardest thing about team software development is getting everyone's brains to have the same understanding. We are building huge, elaborate, complex systems which are invisible in the tangible world. The better you are at getting more peoples' brains to share deeper understanding, the more effective your team will be at software development. This is the underlying reason that pair programming makes sense. Most people dismiss it (and I did too initially), but with this principle in mind I highly recommend that you give it another shot. You wind up with TWO people who deeply understand the subsystem you just built ... there aren't many other ways to get such a deep information transfer so quickly. It is like a Vulcan mind meld.

You don't always need words to communicate deep understanding quickly. And a corollary: too many words, and you exceed the listener/reader's capacity, meaning the understanding transfer you're attempting does not happen. Consider that children learn how to speak language by being "immersed" and "absorbing". Not just language either ... he gives the example of some kids playing with trains on the floor. Along comes another kid who has never even SEEN a train before ... but by watching the other kids, he picks up the gist of the game and plays right along. This happens all the time between humans. This along with the corollary about too many words helps you see how misguided it was in the old "waterfall" days to try to write 700 page detailed requirements specifications.

There is so much more in there too. I'll shut up now, but I HIGHLY recommend this book!