resources - Was ist das einflussreichste Buch, das jeder Programmierer lesen sollte?

original title: "resources - What is the single most influential book every programmer should read?"


If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be?

I expect this list to be varied and to cover a wide range of things.

To search: Use the search box in the upper-right corner. To search the answers of the current question, use inquestion:this. For example:

inquestion:this "Code Complete"

Wenn Sie in die Vergangenheit reisen und sich sagen könnten, dass Sie zu Beginn Ihrer Karriere als Entwickler ein bestimmtes Buch lesen sollen, welches Buch wäre das? Ich erwarte, dass diese Liste vielfältig ist und eine breite ...

Dies ist die Zusammenfassung nach der Übersetzung. Wenn Sie die vollständige Übersetzung anzeigen möchten, klicken Sie auf das Symbol "Übersetzen"

Alle Antworten
  • Translate
    • Code Complete (2nd edition) by Steve McConnell
    • The Pragmatic Programmer
    • Structure and Interpretation of Computer Programs
    • The C Programming Language by Kernighan and Ritchie
    • Introduction to Algorithms by Cormen, Leiserson, Rivest & Stein
    • Design Patterns by the Gang of Four
    • Refactoring: Improving the Design of Existing Code
    • The Mythical Man Month
    • The Art of Computer Programming by Donald Knuth
    • Compilers: Principles, Techniques and Tools by Alfred V. Aho, Ravi Sethi and Jeffrey D. Ullman
    • Gödel, Escher, Bach by Douglas Hofstadter
    • Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
    • Effective C++
    • More Effective C++
    • CODE by Charles Petzold
    • Programming Pearls by Jon Bentley
    • Working Effectively with Legacy Code by Michael C. Feathers
    • Peopleware by Demarco and Lister
    • Coders at Work by Peter Seibel
    • Surely You're Joking, Mr. Feynman!
    • Effective Java 2nd edition
    • Patterns of Enterprise Application Architecture by Martin Fowler
    • The Little Schemer
    • The Seasoned Schemer
    • Why's (Poignant) Guide to Ruby
    • The Inmates Are Running The Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity
    • The Art of Unix Programming
    • Test-Driven Development: By Example by Kent Beck
    • Practices of an Agile Developer
    • Don't Make Me Think
    • Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
    • Domain Driven Designs by Eric Evans
    • The Design of Everyday Things by Donald Norman
    • Modern C++ Design by Andrei Alexandrescu
    • Best Software Writing I by Joel Spolsky
    • The Practice of Programming by Kernighan and Pike
    • Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt
    • Software Estimation: Demystifying the Black Art by Steve McConnel
    • The Passionate Programmer (My Job Went To India) by Chad Fowler
    • Hackers: Heroes of the Computer Revolution
    • Algorithms + Data Structures = Programs
    • Writing Solid Code
    • JavaScript - The Good Parts
    • Getting Real by 37 Signals
    • Foundations of Programming by Karl Seguin
    • Computer Graphics: Principles and Practice in C (2nd Edition)
    • Thinking in Java by Bruce Eckel
    • The Elements of Computing Systems
    • Refactoring to Patterns by Joshua Kerievsky
    • Modern Operating Systems by Andrew S. Tanenbaum
    • The Annotated Turing
    • Things That Make Us Smart by Donald Norman
    • The Timeless Way of Building by Christopher Alexander
    • The Deadline: A Novel About Project Management by Tom DeMarco
    • The C++ Programming Language (3rd edition) by Stroustrup
    • Patterns of Enterprise Application Architecture
    • Computer Systems - A Programmer's Perspective
    • Agile Principles, Patterns, and Practices in C# by Robert C. Martin
    • Growing Object-Oriented Software, Guided by Tests
    • Framework Design Guidelines by Brad Abrams
    • Object Thinking by Dr. David West
    • Advanced Programming in the UNIX Environment by W. Richard Stevens
    • Hackers and Painters: Big Ideas from the Computer Age
    • The Soul of a New Machine by Tracy Kidder
    • CLR via C# by Jeffrey Richter
    • The Timeless Way of Building by Christopher Alexander
    • Design Patterns in C# by Steve Metsker
    • Alice in Wonderland by Lewis Carol
    • Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig
    • About Face - The Essentials of Interaction Design
    • Here Comes Everybody: The Power of Organizing Without Organizations by Clay Shirky
    • The Tao of Programming
    • Computational Beauty of Nature
    • Writing Solid Code by Steve Maguire
    • Philip and Alex's Guide to Web Publishing
    • Object-Oriented Analysis and Design with Applications by Grady Booch
    • Effective Java by Joshua Bloch
    • Computability by N. J. Cutland
    • Masterminds of Programming
    • The Tao Te Ching
    • The Productive Programmer
    • The Art of Deception by Kevin Mitnick
    • The Career Programmer: Guerilla Tactics for an Imperfect World by Christopher Duncan
    • Paradigms of Artificial Intelligence Programming: Case studies in Common Lisp
    • Masters of Doom
    • Pragmatic Unit Testing in C# with NUnit by Andy Hunt and Dave Thomas with Matt Hargett
    • How To Solve It by George Polya
    • The Alchemist by Paulo Coelho
    • Smalltalk-80: The Language and its Implementation
    • Writing Secure Code (2nd Edition) by Michael Howard
    • Introduction to Functional Programming by Philip Wadler and Richard Bird
    • No Bugs! by David Thielen
    • Rework by Jason Freid and DHH
    • JUnit in Action

  • Translate


    @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

  • Pandora Lee

    Discrete Mathematics For Computer Scientists,204,203,200_AA219_PIsitb-sticker-dp-arrow,TopRight,-24,-23_SH20_OU02_.jpg

    Discrete Mathematics For Computer Scientists by J.K. Truss.

    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.

  • Translate

    Systemantics: How Systems Work and Especially How They Fail. Get it used cheap. But you might not get the humor until you've worked on a few failed projects.

    The beauty of the book is the copyright year.

    Probably the most profound takeaway "law" presented in the book:

    The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.

    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.

  • Joanne Lee

    One of my personal favorites is Hacker's Delight, because it was as much fun to read as it was educational.

    I hope the second edition will be released soon!

  • Elliot Lee

  • Marina Lee

    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.

  • Theobald Lee

    Types and Programming Languages by Benjamin C Pierce for a thorough understanding of the underpinnings of programming languages.

  • Sheila Lee

  • Bartholomew Lee

    Database System Concepts is one of the best books you can read on understanding good database design principles.

    alt text

  • Translate

    The practice of programming. By Brian W. Kernighan, Rob Pike.

    The style shown here is excellent - the code just speaks for itself, and the whole book follows the KISS principle. Personally not my languages of choice, but still influential to me.

  • Translate

    Programming from the ground up. It's free on the internet. This book taught me AT&T asm. It is very easy to read.

    alt text

  • Translate

    Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp by Peter Norvig

    enter image description here

    I started reading it because I wanted to learn Common Lisp. When I was halfway, I realized this was the greatest book about programming I had read so far.

  • Translate

    Definitively Software Craftsmanship

    alt text

    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)

  • Upton Lee

    @Peter Coulton -- you don't read Knuth, you study it.

    For me, and my work... Purely Functional Data Structures is great for thinking and developing with functional languages in mind.

  • Greg Lee

    "The World is Flat" by Thomas Friedman.

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

  • Translate

    alt text

    This last year I took a number of classes. I read

    The Innovator's Dilemma (disruptive tech)
    The Mythical Man Month (managing software)
    Crossing the Chasm (startup)
    Database Management Systems, The COW Book
    Programming C#, The OSTRICH Book
    Beginning iPhone Developmen, The GRAPEFRUIT Book

    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!

  • Sally Lee

    hackers, by Steven Levy.

    The personality and way of life must come first. Everything else can be learned.

  • Beck Lee

    The Python language was very influential to me, I wish I would have read these book years ago. The beauty and simplicity of the Python language really affected how I wrote code in other languages.

    alt text alt text

  • Translate

    The New Turing Omnibus,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA300_SH20_OU01_.jpg

    Really good book. Has a high-level taste of the most important areas of computer science. Yes, CS != programming, but this is still useful to every programmer.

  • Frank Lee

    The Mythical Man-Month by Fred Brooks

  • Modesty Lee

    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.

  • Dempsey Lee

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

  • Madge Lee

  • Elma Lee

    Martin Fowler's Refactoring: Improving the Design of Existing Code has already been listed. But I will detail why it has impacted me.

    The essence of the whole book is about structuring code so that it is simpler to read and understand by humans. It teaches me strongly that the code that I write is meant for my colleagues and successors to consume and possibly learn something good out of it. It inspires me to consciously program in a manner that leaves people praising my name, and not cursing me to damnation for all eternity.

  • Georgia Lee

    alt text

    C++ How to Program It is good for beginner.This is excellent book that full complete with 1500 pages.

  • Selena Lee

    Here's an excellent book that is not as widely applauded, but is full of deep insight: Agile Software Development: The Cooperative Game, by Alistair Cockburn.

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

    1. 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.
    2. 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!

  • Translate

    Masters of doom. As far as motivation and love for your profession go: it won't get any better than what's been described in this book, truthfully inspiring story!