In your CS career, which book dramatically changed your way of approaching problems?
Most Frequently mentioned:
CodeComplete
By Steve McConnell
ISBN 0-7356-1967-0 (2nd edition)
Microsoft Press
Via Paul Lalonde very high knowledge of this book
Structure and Interpretation of Computer Programs. I learned many valuable things from that book, but the most dramatic change was in the point of view that all programming is language design. All libraries and subroutines object classes and such are ways of extending the language to create a new language in which you solve your problem.
The original GoF Design Patterns. I felt like I'd leveled up after each chapter.
Gödel, Escher, Bach: an Eternal Golden Braid - Douglas Hofstadter
"Hardcore Zen" and "Sit Down and Shut Up", both by Brad Warner.
Their influence isn't just due to their coherent and appealing explanation of Zen meditation. I'd been practicing Zen for years before I read them.
No, what these books really offered me is a great example of getting to the real heart of an issue by throwing away the dogma and looking at the situation with fresh eyes. So often when we're faced with an unsolvable problem, it's because some of our lower-level assumptions make the problem unsolvable.
With teaching Zen, Warner realized that the dogma isn't the point. Freed from the typical methods of teaching Zen, he came up with an even cleaner and more elegant method of doing so. He tossed the bathwater and kept the baby.
Every time I've overcome a major, seemingly intractable snag in a program, it's because of a question I wasn't asking myself that I should have. And I wasn't asking the question because I'd already assumed an answer instead of actually seeing the problem and formulating it.
Both Warner's example and the practice of Zen meditation showed me how to throw out my assumptions and build a problem space entirely from scratch.
"Software Tools" by Brian Kernighan, P.J.Plauger.
The book predates both C and UNIX but had a deep influence on both. And a deep influence on the way I worked and approach problems. Its still a good read if you can get your head around the "Ratfor" program examples.
"Soul of a New Machine" - Tracy Kidder(?)
Taught me a lot about burn-out and work-life balance.
It was a while ago, but Ted Patison's
Programmimg Distributed Applications With Com+ and Microsoft Visual Basic 6.0
More recently, Domain Driven Design by Eric Evans
Having already voted up McConnell's Code Complete, I'll add Getting To Yes by Roger Fisher and William Ury which succinctly outlines key practices in conducting win-win negotiations. Whether talking to team members, project managers, internal departments or external clients, most developers spend at least some of their time in negotiations over features, technologies, timescales etc. Finding an effective way to get the best out of these negotiations is an important skill.
When I first read Getting To Yes many years back, it helped me to get a grip on using negotiations to reach acceptable solutions rather than treating them as an exercise in winning arguments. I suspect it also had a subtle but profound effect on the way that I write code. It's one of those deceptively simple books that seems obvious once you've read it but can have a wide-ranging impact on your professional practice.
I cannot pick one book because there are three of them that deeply influenced my software developer carrier:
Code complete, Steve McConnell, first edition. I read it around 1994 and it was a book that explained fine craft of software development. I still have it and in my opinion it is the book that every programmer must read.
Design Patterns, GoF. I got this one around 1997. Book is so hard that I needed 6 months to read and study pattern catalog. Since then, I'm reading it whenever I am not sure about some pattern. "Head first design patterns" is also great book, but it is to verbose. When I need details about implementation, "Design Patterns" is the really good reference. Drawback is that book is very dense and hard to read.
Domain driven design, Eric Evans. This is the book that taught me how to effectively design object models. I read lots of books in this area, but this one is high above others. "Code Complete" taught me a craft and this one taught me fine design.
The Art of Unix Programming by Eric S. Raymond. Given the infatuation with architectures like J2EE and event the so called "lightweight" containers such as Spring and others, "The Art of Unix Programming" presents an alternative way of solving problems that is tried and true and does actually make some otherwise difficult things easy. For example, efficiently using multi-threading and multi-core hardware is much easier with the approaches described in the book. Plus, it's a good read :)
In no particular order:
Four of them come to mind at once (and you can tell how far back this was):
The Report on the Algorithmic Language ALGOL 60 was earth-shattering for me when I stumbled upon it in 1961.
Peter Landin's triple-threat: "The Mechanical Evaluation of Expressions [MEE]", "A Correspondence between ALGOL-60 and Church's lambda notation," and "The Next 700 Programming Languages" (all mid-60s)
Donald Knuth's The Art of Computer Programming, all volumes but especially vol.1 (along with his "Literate Programming" and Selected Works).
Edsger Dijkstra's A Discipline of Programming, 1976.
ADDED LATER: On reflection, I notice that this book has had a profound influence on my attitude toward development of dependable software: Robert C. Solomon and Fernando Flores, "Builkding Trust in Business, Politics, Relationships, and Life," Oxford University Press (New York: 2001), ISBN 0-19-516111-4 pbk. I summarize some of the importance for me in the post "Trust but Demonstrate."
This from the beginning of my career...
"The Spirit of C, An Introduction to Modern Programming" by Henry Mullish and Herbert L. Cooper.
That was one of the best C books.
And, of course "The C Programming Language" by Brian Kernighan and Dennis Ritchie.
-R
How To Solve It by G. Polya. A book of heuristics for solving mathematical problems, but applicable to just about any problem. Assigned reading for one of my mathematics classes, this is one of very few university books I still refer to decades later.
I would have to say The Design of Everyday Things by Donald Norman. This explains how many everyday objects are poorly designed, and some that are done very well.
Looking at my bookshelf, from most general to most specific, my most-used books are:
The strength of every one of the above books is its mindset. I find myself returning to them time and time again to help me maintaining the ever-important balance overall design and the minutiae of the actual coding. Every other computer book on my bookshelf is a reference book of one kind or another, all trees but no forest. Useful detailed technical data, sure, but nowadays almost always as easy to find online.
The latter book started me on a journey towards understanding Domain-Driven Developement and Software Factories - a journey only just begun, as I will need to read "Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools" by Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent several more times before I understand it.
Object Oriented Design with Applications, by Grady Booch
not a book but this simple wheel (repeatable technique) -
for each problem start at 12 and go clockwise rinse and repeat =>
