What is the single most influential book every programmer should read?(stackoverflow.com)
stackoverflow.com
What is the single most influential book every programmer should read?
http://stackoverflow.com/q/1711/142240
35 comments
Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable.
Also, it should have a short appendix explaining that you do not get geek brownie points simply by using as many patterns as you can think of.
I realize these are not problems with the book per se, and it's worth reading, but some developers seem to get the wrong message from it.
Also, it should have a short appendix explaining that you do not get geek brownie points simply by using as many patterns as you can think of.
I realize these are not problems with the book per se, and it's worth reading, but some developers seem to get the wrong message from it.
"Design Patterns needs to be read with the understanding that the patterns are for specific types of languages and are not universally applicable."
Not really. I've found a use for design patterns in just about every language I've used. They're not all equally useful, but that was never the book's claim.
It's become a little fashionable to be cynical about Design Patterns, but most of them have held up well. A few of the patterns were always obscure (even at the time of writing), and a few others are trivially implemented in newer languages, but honestly, there are a lot of people who are doing a poor job of re-implementing the patterns, then doing an worse job of communicating their work. There's something useful about the notion of a consistent engineering vocabulary.
Also, I talk to a lot of people who claim to hate Design Patterns, but haven't actually read the book. They've used Java, decided that they hate Singletons and Factories, and thrown the baby out with the bathwater. There's a lot more to the book than just Singletons and Factories.
Not really. I've found a use for design patterns in just about every language I've used. They're not all equally useful, but that was never the book's claim.
It's become a little fashionable to be cynical about Design Patterns, but most of them have held up well. A few of the patterns were always obscure (even at the time of writing), and a few others are trivially implemented in newer languages, but honestly, there are a lot of people who are doing a poor job of re-implementing the patterns, then doing an worse job of communicating their work. There's something useful about the notion of a consistent engineering vocabulary.
Also, I talk to a lot of people who claim to hate Design Patterns, but haven't actually read the book. They've used Java, decided that they hate Singletons and Factories, and thrown the baby out with the bathwater. There's a lot more to the book than just Singletons and Factories.
> trivially implemented in newer languages
Well this is just wrong! I would call them good languages but that just my opinion.
I have never really found it helpful to think about these patterns. Witch one do you find helpful to think about?
Well this is just wrong! I would call them good languages but that just my opinion.
I have never really found it helpful to think about these patterns. Witch one do you find helpful to think about?
A lot of them are still useful abstractions (for vocabulary, if nothing else). In particular, I see Strategy patterns used all over the place (but not referred to as such), as well as Adapters, Bridges, Decorators, Facades and Proxies...but most people who have claimed to have read the book couldn't tell you the differences between those ideas.
Lots of people seem to independently "re-invent" the Observer and Visitor patterns (badly), which is a shame, because there's lots of room for subtlety in their implementations. And of course, Ruby makes use of Interpreter all over the place, and frameworks like Rails use Command, Chain of Responsibility, Mediator, Template Method, and so on...but don't really call them by their names. Blargh.
Lots of people seem to independently "re-invent" the Observer and Visitor patterns (badly), which is a shame, because there's lots of room for subtlety in their implementations. And of course, Ruby makes use of Interpreter all over the place, and frameworks like Rails use Command, Chain of Responsibility, Mediator, Template Method, and so on...but don't really call them by their names. Blargh.
I read Design Patterns and was unimpressed. Maybe it's because I'm used to large codebases that are already well designed, but all I got out of Design Patterns was formal names for patterns that I already used in my code because they're intuitively the correct thing to do.
[deleted]
Indeed, that is the only correct use of Design Patterns.
I agree. I would place Dijkstra's 'A Discipline of Programming' and Feijen and van Gasteren's 'A method of multi-programming' right up there with 'Introduction to Algorithms'.
What sets these books apart is that they try to tackle the problem of _how_ to design elegant algorithms. In the process they introduce crucial concepts like invariants which, once you understand them, become indispensable tools in reasoning and designing algorithms.
More generally, their stress on elegant proofs develops a taste for mathematical elegance which would serve all programmers well as they design new systems.
These books are much too under-appreciated, in my opinion.
What sets these books apart is that they try to tackle the problem of _how_ to design elegant algorithms. In the process they introduce crucial concepts like invariants which, once you understand them, become indispensable tools in reasoning and designing algorithms.
More generally, their stress on elegant proofs develops a taste for mathematical elegance which would serve all programmers well as they design new systems.
These books are much too under-appreciated, in my opinion.
Personal preference I guess.
I reread Pragmatic Programmer every year.
The other two you mention I find pretty poor, to be honest. I may reference them once in a while, but to really understand the topics they cover I'll rely on a well written, colorful article over those books.
In general I've found books written by more than 2 authors to be quite boring, impersonal, and oftentimes misleading.
Code Complete and Pragmatic Programmer are two of my favorites alongside C, and the Practice of Programming.
I reread Pragmatic Programmer every year.
The other two you mention I find pretty poor, to be honest. I may reference them once in a while, but to really understand the topics they cover I'll rely on a well written, colorful article over those books.
In general I've found books written by more than 2 authors to be quite boring, impersonal, and oftentimes misleading.
Code Complete and Pragmatic Programmer are two of my favorites alongside C, and the Practice of Programming.
It is SICP for me.
Design Patterns are only needed if your language is not powerful enough.
In assembler subroutines and classes are design patterns.
Design Patterns are only needed if your language is not powerful enough.
In assembler subroutines and classes are design patterns.
At least they remembered K&R.
Judging by the "The Pragmatic Programmer" book on subversion alone, this series of books has got to be absolutely horrible because they literally half-copied the svn redbook and dumbed it down so you pay good money for so very little information which you could all very easily find by spending 10 minutes with the svn redbook.
You can't really judge a book solely by the imprint it belongs to or, in the case of "The Pragmatic Programmer", stated. They're all written by different authors so their style and quality will naturally differ.
For what it's worth, it's the same imprint that gave us the pickaxe book (Programming Ruby), so perhaps that ought to be a point in it's favour.
For what it's worth, it's the same imprint that gave us the pickaxe book (Programming Ruby), so perhaps that ought to be a point in it's favour.
"Without Conscience: The Disturbing World of the Psychopaths Among Us" by Robert Hare. If only I understood more about how many corporate executives and venture capitalists think about things and regard others earlier in my career, it would have saved a lot of grief. Now that I understand this disorder and how it works, I am able to avoid distasteful and frustrating scenarios and get much more done.
What sort of situations have you encountered?
While I agree that some degree of emotional detachment is necessary to succeed, this is a bit too harsh of a judgement...
Man, still Code Complete? I dunno. Wasn't that big a fan, honestly. I think I got more out of the first three chapters than the sum of the rest of the book.
If we're talking about technical books, Refactoring is easily the most beneficial read I can remember having. I was pleased to see it (barely) trump Design Patterns... a book that I think (through no real fault of it's own) has spoiled more developer-years than it's benefitted.
If we're talking about technical books, Refactoring is easily the most beneficial read I can remember having. I was pleased to see it (barely) trump Design Patterns... a book that I think (through no real fault of it's own) has spoiled more developer-years than it's benefitted.
I think Code Complete deserves its usual top spot on these lists. You need to understand the skill set of the typical entry level coder, even after acquiring a CS degree. There is so very, very much they don't know and Code Complete helps fill in a lot of the gaps. Most usefully it helps instill the idea that it's important to use practices that are backed up by evidence and that there is a lot more to learn when you get out of school. A lot of the advice in it may seem a little outdated or even trivial to a lot of developers, but it is not less fundamental. Being inculcated in the ideas that it's bad to break the build, that you need to build often, that finding and fixing problems earlier saves a crap-ton of effort, that using proper source control tools and bug tracking tools is generally incredibly helpful. It's easy to forget that there are devs out there who don't know these things, don't have the habits we think should be universal, etc.
As far as coding skill, I agree about Refactoring. Design Patterns is just a grab-bag of tools that are useful in some situations and harmful if misused or abused. Refactoring is a set of skills that are globally useful and are married to equally important models, terminology, and advice. Studying refactoring gives devs a much stronger ability to talk about, study, understand, reason about, and modify code. I'd much rather work with someone who was an expert in refactoring than someone who was an expert in design patterns.
Edit: also, Refactoring concentrates on changing existing code vs. greenfield development, which tends to be far more useful in practice.
As far as coding skill, I agree about Refactoring. Design Patterns is just a grab-bag of tools that are useful in some situations and harmful if misused or abused. Refactoring is a set of skills that are globally useful and are married to equally important models, terminology, and advice. Studying refactoring gives devs a much stronger ability to talk about, study, understand, reason about, and modify code. I'd much rather work with someone who was an expert in refactoring than someone who was an expert in design patterns.
Edit: also, Refactoring concentrates on changing existing code vs. greenfield development, which tends to be far more useful in practice.
The value of the GOF book is in the way of thinking, not in the actual patterns themselves.
Someone once told me that the value of the GOF book was that it provides a common vocabulary for shared ideas. I believe that now. That's what (and maybe all) it's good for in my mind.
The problem with using it to impart a method of thinking in my mind is that the way of thinking (and the patterns themselves) really have to be earned. I think it's possible for a book to do a fair job at imparting that wisdom, but GOF is setup terribly for it. It's sort of like picking up a recipe book full of classical french dishes without learning about french cooking first. It's too easy to misunderstand the specific values and compromises of specific 'ingredients' and undo the benefit the pattern could provide altogether.
I've wondered before if GOF could be rethunk with Refactoring in mind. Starting with code smells is exactly right. The book should focus more on identifying problems with an approach, because that's the hard part. Solutions are much easier.
The problem with using it to impart a method of thinking in my mind is that the way of thinking (and the patterns themselves) really have to be earned. I think it's possible for a book to do a fair job at imparting that wisdom, but GOF is setup terribly for it. It's sort of like picking up a recipe book full of classical french dishes without learning about french cooking first. It's too easy to misunderstand the specific values and compromises of specific 'ingredients' and undo the benefit the pattern could provide altogether.
I've wondered before if GOF could be rethunk with Refactoring in mind. Starting with code smells is exactly right. The book should focus more on identifying problems with an approach, because that's the hard part. Solutions are much easier.
Very much so. However, it's much less successful at instilling that way of thinking than Refactoring is. Worse yet, many readers becomeoverly enamored with the "canonical" design patterns, seemingly not realizing that most of them are special purpose constructs and only useful in very specific circumstances (and in some languages wholly obsolete). They also often don't understand that those examples are but a drop in the bucket amongst the universe of useful patterns (many of which assuredly haven't even been created yet).
>Very much so. However, it's much less successful at instilling that way of thinking than Refactoring is.
That's why I like PoEAA - Fowler is better writer than the GOF so his books do a better job of bringing the ideas across.
That's why I like PoEAA - Fowler is better writer than the GOF so his books do a better job of bringing the ideas across.
I was seriously disilusioned when I have learned that most of the design patterns make sense only in strongly-typed languages, and that the whole mess that is abstract factory can in, say, PHP be replaced with a simple
new $className();But then you realize, some people can only barely decipher what's printed on the pages, they consider it a bible, when it is in fact, a consequence of design compromises in pseudo-OOP langs like C++ and java.
I really really hate singletons, visitors, factories, and all the lot, but I'm glad I can understand the intent of these things.
I think being disillusioned with this book is a good stepping stone for devs, it felt like one to me.
I really really hate singletons, visitors, factories, and all the lot, but I'm glad I can understand the intent of these things.
I think being disillusioned with this book is a good stepping stone for devs, it felt like one to me.
I'm not sure I agree. I suspect the vast majority of them (including abstract factories) make loads of sense in most languages.. it's just that strongly typed languages make many of the patterns complicated enough to implement that they deserve a chapter's worth of description.
Yes. See Peter Norvig (Director of Research at Google)'s slides on this topic here: http://norvig.com/design-patterns/
Going through the list:
Code Complete: First ed 1993
Prag Prog: 1999
SICP: 80s?
K&R C: ditto
CLRS: 1990
Refactoring: 1999?
GoF DP: 1994
Mythical Man Month: late 70s, 80s?
TAOCP: Decades ago, and not a serious suggestion
Dragon book: 1986
GEB: 80s was it?
Programming Pearls: 1999
CODE: 1999
Off the top items in that list, only two have them have been published in the last TWELVE years, which in our industry is at least two full generations.
I don't know about you guys but that makes me a little sad. I think somethings have changed a lot in the last 20 years. I refuse to believe that Brooks had the last word on project management several generations ago.
I accept the notion that "the more things change, the more they stay the same" but I can't help but think this Greatest Hits List couldn't be improved somewhat.
Code Complete: First ed 1993
Prag Prog: 1999
SICP: 80s?
K&R C: ditto
CLRS: 1990
Refactoring: 1999?
GoF DP: 1994
Mythical Man Month: late 70s, 80s?
TAOCP: Decades ago, and not a serious suggestion
Dragon book: 1986
GEB: 80s was it?
Programming Pearls: 1999
CODE: 1999
Off the top items in that list, only two have them have been published in the last TWELVE years, which in our industry is at least two full generations.
I don't know about you guys but that makes me a little sad. I think somethings have changed a lot in the last 20 years. I refuse to believe that Brooks had the last word on project management several generations ago.
I accept the notion that "the more things change, the more they stay the same" but I can't help but think this Greatest Hits List couldn't be improved somewhat.
There's an element of inevitability here. It is natural that the most widely applicable material was written long ago, because the basic problems were solved long ago as well.
Today's problems tend to be more specialised, which means even a brilliant book about how to solve them isn't going to be as widely influential. Something accessible to mere mortals about functional programming probably has the best chance today, given the increasing penetration of related ideas into mainstream programming languages, but while there are some brilliant presenters working in that field, their focus is still typically far too academic for mainstream interest. Something about non-traditional databases, distributed systems, and why certain key problems can't be solved and there are necessarily always trade-offs, might also be applicable to many programmers today, but again I know of no natural figurehead to write a definitive book on the subject.
The drop-off in top-notch books also correlates pretty well with the rise of the WWW as a mainstream information source. Of all subjects, computing is one of the fastest evolving and perhaps the most natural candidate to find a home for new information on Web pages rather than paper. It's tough to write a book that won't date scarily quickly today, again partly because of the specialism aspect, but a Web page stays up-to-date for as long as you care to update it.
What's left? Lowest-common-denominator commodity books: X For Dummies, Learn Y in Z hours, the latest unsupported advocacy from some "Agile trainer", and occasionally a printed snapshot of an interesting web site as it was six months ago when the publishing process was started. Not exactly the kind of material written by the industry giants and sagely academics of 20 years ago, alas.
Today's problems tend to be more specialised, which means even a brilliant book about how to solve them isn't going to be as widely influential. Something accessible to mere mortals about functional programming probably has the best chance today, given the increasing penetration of related ideas into mainstream programming languages, but while there are some brilliant presenters working in that field, their focus is still typically far too academic for mainstream interest. Something about non-traditional databases, distributed systems, and why certain key problems can't be solved and there are necessarily always trade-offs, might also be applicable to many programmers today, but again I know of no natural figurehead to write a definitive book on the subject.
The drop-off in top-notch books also correlates pretty well with the rise of the WWW as a mainstream information source. Of all subjects, computing is one of the fastest evolving and perhaps the most natural candidate to find a home for new information on Web pages rather than paper. It's tough to write a book that won't date scarily quickly today, again partly because of the specialism aspect, but a Web page stays up-to-date for as long as you care to update it.
What's left? Lowest-common-denominator commodity books: X For Dummies, Learn Y in Z hours, the latest unsupported advocacy from some "Agile trainer", and occasionally a printed snapshot of an interesting web site as it was six months ago when the publishing process was started. Not exactly the kind of material written by the industry giants and sagely academics of 20 years ago, alas.
Given that JavaScript and Python are very mainstream now, we need some sort of text that covers functional techniques for the average programmer in scripting languages. SICP is dated and doesn't really match what modern languages can do.
Mark-Jason Dominus' "Higher-Order Perl" is fantastic, but unfortunately specific to a language that's most programmers are not choosing in 2011. There was an attempt at a JavaScript port. Maybe someone should take that up again.
Mark-Jason Dominus' "Higher-Order Perl" is fantastic, but unfortunately specific to a language that's most programmers are not choosing in 2011. There was an attempt at a JavaScript port. Maybe someone should take that up again.
> SICP is dated and doesn't really match what modern languages can do.
I disagree. There's over 200 pages before they even introduce mutation and impure functions. Later they touch on the thorny problems that mutation creates when they touch on concurrent programming. There's sections on building lazy streams which are core parts of Clojure and Haskell. And I don't think there's a more accessible intro compilers and programming languages text than chapters 3 and 4.
While there might be other places to learn about functional programming to apply to working in Python and JavaScript, SICP is a fine place to learn the fundamentals. In some ways, I would say modern programming languages are just starting to catch up to SICP. (yes I know Haskell is pretty old, and disclaimer: I'm a huge fan of SICP)
I disagree. There's over 200 pages before they even introduce mutation and impure functions. Later they touch on the thorny problems that mutation creates when they touch on concurrent programming. There's sections on building lazy streams which are core parts of Clojure and Haskell. And I don't think there's a more accessible intro compilers and programming languages text than chapters 3 and 4.
While there might be other places to learn about functional programming to apply to working in Python and JavaScript, SICP is a fine place to learn the fundamentals. In some ways, I would say modern programming languages are just starting to catch up to SICP. (yes I know Haskell is pretty old, and disclaimer: I'm a huge fan of SICP)
> I disagree. There's over 200 pages before they even introduce mutation and impure functions.
That's kind of the point. I tend to be the one defending SICP on this board, but only for someone who wants the very particular kind of education SICP brings.
Meanwhile, over in languages people are using, you don't have the option of living without mutation. Time to learn how to protect yourself, or not, with closures.
Recursion has a bigger speed and space penalty. You need to tell people when to use maps and folds and when not to.
SICP doesn't really do combinators, and they are very useful in JS.
Also, a lot of libraries in JS use chaining, so a grounding in their theory (maybe even a discussion of monads à la Haskell) might be very fruitful. SICP has nothing like that.
Callbacks are everywhere in JS programming, so a discussion of how to avoid spaghetti would be good.
Latency is a much bigger deal for JS -- how to balance very fast local resources with potentially never-returning remote resources -- and techniques for beating that are not to be found in SICP, as far as I remember.
And of course there's no discussion at all of UI or media in SICP.
That's kind of the point. I tend to be the one defending SICP on this board, but only for someone who wants the very particular kind of education SICP brings.
Meanwhile, over in languages people are using, you don't have the option of living without mutation. Time to learn how to protect yourself, or not, with closures.
Recursion has a bigger speed and space penalty. You need to tell people when to use maps and folds and when not to.
SICP doesn't really do combinators, and they are very useful in JS.
Also, a lot of libraries in JS use chaining, so a grounding in their theory (maybe even a discussion of monads à la Haskell) might be very fruitful. SICP has nothing like that.
Callbacks are everywhere in JS programming, so a discussion of how to avoid spaghetti would be good.
Latency is a much bigger deal for JS -- how to balance very fast local resources with potentially never-returning remote resources -- and techniques for beating that are not to be found in SICP, as far as I remember.
And of course there's no discussion at all of UI or media in SICP.
> SICP is dated and doesn't really match what modern languages can do.
You really need to elaborate on that. Especially given how Guido could have used reading SICP when implementing Python and how Brendon was thoroughly inspired by Scheme (and I assume SICP) for Javascript.
You really need to elaborate on that. Especially given how Guido could have used reading SICP when implementing Python and how Brendon was thoroughly inspired by Scheme (and I assume SICP) for Javascript.
"TAOCP: Decades ago, and not a serious suggestion"?
TAOCP is not even finished. My copy of volume 4a is copyright 2011. Although it's definitely not something every programmer should read, it's a fantastic resource when you run into a really, really hard problem. I think it's also a great source for recreational programming problems if you like that sort of thing.
TAOCP is not even finished. My copy of volume 4a is copyright 2011. Although it's definitely not something every programmer should read, it's a fantastic resource when you run into a really, really hard problem. I think it's also a great source for recreational programming problems if you like that sort of thing.
it is somewhat reasonable that older books have more people who read them and learned from them, the effect of a book written more recently may yet be small but will be important later. (Cue van gogh related factoids)
> Off the top items in that list, only two have them have been published in the last TWELVE years, which in our industry is at least two full generations.
> I don't know about you guys but that makes me a little sad.
It doesn't make me sad at all. It says that computer programming is not just about the latest whiz-bang tool. Rather, the field has a core of worthwhile, enduring knowledge that does not become obsolete just because you switch to a new language/framework/platform/whatever. And this core is worth spending time and effort to learn, because it is not going to go out of date.
> I don't know about you guys but that makes me a little sad.
It doesn't make me sad at all. It says that computer programming is not just about the latest whiz-bang tool. Rather, the field has a core of worthwhile, enduring knowledge that does not become obsolete just because you switch to a new language/framework/platform/whatever. And this core is worth spending time and effort to learn, because it is not going to go out of date.
Euclid's Elements: 300BC
Many of the books above focus on the fundamentals which is what makes them classics.
Also, The second edition of Programming Pearls was around 1999. The first edition was much earlier.
Many of the books above focus on the fundamentals which is what makes them classics.
Also, The second edition of Programming Pearls was around 1999. The first edition was much earlier.
this is just a reflection of the fact that now we can use the internet to spread ideas and this audience are/were the earliest adopters.
in 5-10 years (or even now, maybe?) people will be talking about what single blog post is the single most influential post every programmer should read.
in 5-10 years (or even now, maybe?) people will be talking about what single blog post is the single most influential post every programmer should read.
[deleted]
Haha, I clicked the HN headline thinking "I am going to see the top answer as Code Complete and then be annoyed again".
Softies are overrepresented on stackoverflow.
Edit: Oh, no wonder. This is a very old repost.
Softies are overrepresented on stackoverflow.
Edit: Oh, no wonder. This is a very old repost.
While I have never read Code Complete, I know of at least one very smart guy who read it, highly recommends it, and is utterly incapable of maintaining legacy code he did not write. He simply refactors everything he touches, which is not to be recommended. There are no books I know of that teach you how to work in legacy code. It's a dying art.
Feathers's Working Effectively With Legacy Code is /excellent/
Part II (Creating High Quality Code), V (Code Improvements) , VI (System Considerations) and VII (Software Craftmanship) from Code Complete is one of the best SE reading I have had the pleasure to read. I don't consider that stuff basic (as compared to variable naming which you might be alluding to). The first three chapters are too basic IMO and are not even worth reading for any experienced professional.
Wow there were a lot of bad suggestions in that thread. I was just waiting for 'C Programming for Dummies' to pop up posted by E. Trollguy.
If you work in an object oriented language, I think one of the most useful books you could read would be Kent Beck's Smalltalk Best Practise Patterns. The reason being that the lessons and tricks Kent discusses in his book can be applied to Ruby, Python, Java, C#, C++, Delphi, and any other language that I insultingly forgot, where you are working with objects and polymorphism.
But it certainly wouldn't be useful for _every_ programmer to read. Those would be much more abstract like the already listed ones (mythical man month, sicp, code complete, gof, pragmatic programmer)
If you work in an object oriented language, I think one of the most useful books you could read would be Kent Beck's Smalltalk Best Practise Patterns. The reason being that the lessons and tricks Kent discusses in his book can be applied to Ruby, Python, Java, C#, C++, Delphi, and any other language that I insultingly forgot, where you are working with objects and polymorphism.
But it certainly wouldn't be useful for _every_ programmer to read. Those would be much more abstract like the already listed ones (mythical man month, sicp, code complete, gof, pragmatic programmer)
Hey, I know it's a laugh, but "C for Dummies" was my very first introduction to C when I was 13 (I didn't know about K&R yet) and is responsible for teaching this hacker about pointers and math thereupon.
While I still don't usually write C, having that base knowledge before jumping into high-level stuff like Perl and PHP in my middle teens was invaluable.
While I still don't usually write C, having that base knowledge before jumping into high-level stuff like Perl and PHP in my middle teens was invaluable.
The Mythical Man-Month
As always. Considering we are making great software, but a lot of projects still seem to go over the estimated time....then I guess learning about that is what will bring us ahead.
Also this talk by Greg Wilson: http://vimeo.com/9270320
As always. Considering we are making great software, but a lot of projects still seem to go over the estimated time....then I guess learning about that is what will bring us ahead.
Also this talk by Greg Wilson: http://vimeo.com/9270320
I remember hearing about it while I was at uni, and checking it out of my uni library. I read through it, and it was a dusty old tome full of references to long dead systems.
And it was good, while not saying anything I was hugely shocked by, but making clear and sensible points.
And now a few years down the line, I'm out of uni and working, and I find myself toying with buying it for my boss...
And it was good, while not saying anything I was hugely shocked by, but making clear and sensible points.
And now a few years down the line, I'm out of uni and working, and I find myself toying with buying it for my boss...
Do it, I bought Peopleware for a previous boss as a kind of thanks present when I left that project. He really enjoyed it I think.
A Mathematician's Apology is a good read on why the most abstract of subjects is worthy of study. It is a justification of pure mathematics, without resorting to applied mathematics. Though not directly related to computing, it has some lovely insights, and is a thought provoking read. In computing we talk a lot of "elegant" code, without ever defining what elegance is, and in A Mathematician's Apology, Hardy talks of how the most beautiful mathematics is that which has not applicable to the outside world. It is odd in a way that the foreword to the book (a biography of Hardy, written by his friend C.P. Snow) is by a mathematician who is remembered for his contribution to physics; mathematics that seems to be the opposite of Hardy's definition of beauty.
Just to be contraversal, I'm going to suggest 'The Old New Thing', by Raymond Chen.
Not so much for the details of windows (although those are interesting), but it is the only book I have ever seen that attempts to show how a large software project evolves over a long period of time.
Not so much for the details of windows (although those are interesting), but it is the only book I have ever seen that attempts to show how a large software project evolves over a long period of time.
The funny part is the first page is all development books, my recommendation would be one on the business of software development or on usability design. Developers are naturally going to run across the information in those books if they are interested. Understanding business or users is one of the things that separates a good programmer from a great developer. Unless you are going into some pretty hardcore space, read about the parts of software development that you don't like, because the stuff that should be in a CS classroom will be picked up along the way if you like what you do. Read a book on QA or SCM, you will be the better for it.
Recently, I've come to know "Code: The Hidden Language of Computer Hardware and Software"[1], and I really enjoyed it. I don't think it's necessarily the first book every programmer should read, but I do think it's a book every programmer should read. It's an easy read, it's fun, and really does provide what it promises. Highly recommended.
1. http://www.amazon.com/Code-Language-Computer-Hardware-Softwa...
1. http://www.amazon.com/Code-Language-Computer-Hardware-Softwa...
I really enjoyed it. Being self-taught, it provided a really handy primer and computer-architecture fundamentals, logic gates, etc. that I imagine I'd have otherwise gotten in school.
H. Abelson and J. Sussman "Structure and Interpretation of Computer Programs" aka SICP if I had to chose only one, but Cormen, Leiserson, Rivest, Stein: "Introduction to Algorithms" and Sipser: "Introduction To The Theory Of Computation" are other must read ones.
Seriously, asking for one book to read is silly in a profession that is all about lifelong learning and disruption of established assumptions and paradigms. If you want something timeless, then you need to go way low level to the mathematical fundamentals of this profession.
Seriously, asking for one book to read is silly in a profession that is all about lifelong learning and disruption of established assumptions and paradigms. If you want something timeless, then you need to go way low level to the mathematical fundamentals of this profession.
Clean Code wins hands down for me http://stackoverflow.com/a/317750/261363
I though this was a great book too. It covers a lot of the stuff thats in Code Complete but without being a massive tome.
I've seen so many lists like this and they always list the same books... Code Complete, Prag Prog, SICP, Design Patterns, Refactoring, etc...
I'm not sure that all those people on Stackexchange have read the question properly.
The question is "What is the single most influential book every programmer should read?" I.e. given the set of books that every programmer should read, which one is the single most influential?
As a programmer, lets consider the answer to the question, as parsed logically (regardless of intent).
Typing 'most influential books' into Google brings me to this list: http://en.wikipedia.org/wiki/The_100_Most_Influential_Books_...
It turns out its just one persons opinion - but pageranked to the top for 'most influential books'; and notable enough for wikipedia - thats good enough crowd-vetting for my purposes.
If I knew which books all programmers should read, it'd now be a simple matter of finding the highest ranked; but here, I have to use my judgement.
So I suggest:
Number 13, Euclid's Elements
Number 32, Machiavelli's The Prince
Number 93, Orwell's Nineteen Eighty-Four
I'm not sure every programmer should read Elements - maybe, but its a little abstract these days.
I think The Prince would be good reading for the softer skills of the programming profession - and genuinely has really influenced management thinking; its short, so probably worth everyone's time.
Finally, I believe without a doubt, 1984 should certainly be required reading for all programmers - a single read is worth a great many 'ethics for technologists' courses.
There are other candidates on that list too, but I don't think there's anything that I'm as certain all programmers should read as 1984.
Any differing opinions?
The question is "What is the single most influential book every programmer should read?" I.e. given the set of books that every programmer should read, which one is the single most influential?
As a programmer, lets consider the answer to the question, as parsed logically (regardless of intent).
Typing 'most influential books' into Google brings me to this list: http://en.wikipedia.org/wiki/The_100_Most_Influential_Books_...
It turns out its just one persons opinion - but pageranked to the top for 'most influential books'; and notable enough for wikipedia - thats good enough crowd-vetting for my purposes.
If I knew which books all programmers should read, it'd now be a simple matter of finding the highest ranked; but here, I have to use my judgement.
So I suggest:
Number 13, Euclid's Elements
Number 32, Machiavelli's The Prince
Number 93, Orwell's Nineteen Eighty-Four
I'm not sure every programmer should read Elements - maybe, but its a little abstract these days.
I think The Prince would be good reading for the softer skills of the programming profession - and genuinely has really influenced management thinking; its short, so probably worth everyone's time.
Finally, I believe without a doubt, 1984 should certainly be required reading for all programmers - a single read is worth a great many 'ethics for technologists' courses.
There are other candidates on that list too, but I don't think there's anything that I'm as certain all programmers should read as 1984.
Any differing opinions?
If we're assuming an America-centric question and your abstract definition then you can summarize it with just one book:
1. The Bible.
Closely followed by whatever the first book that people in stackoverflow's demographic read whilst learning to read.
1. The Bible.
Closely followed by whatever the first book that people in stackoverflow's demographic read whilst learning to read.
Why is this being downvoted?
I'm an atheist, but even I can see the bible's profound impact on the course of western and near-eastern civilisation.
I'm an atheist, but even I can see the bible's profound impact on the course of western and near-eastern civilisation.
Certainly, it is very influential - but is it a book that all programmers (even western ones) should read?
I'm not sure - it is very long. Its probably worth reading some subset of, but I'd be more certain about 1984 and even The Prince, depending on whether we mean 'read all the way through'.
I'm not sure - it is very long. Its probably worth reading some subset of, but I'd be more certain about 1984 and even The Prince, depending on whether we mean 'read all the way through'.
As you have mentioned 1984, I have to add Brave New World to the list. It provides a view of the future which in many aspects is a lot closer to our current culture than 1984. In terms of "ethics for technologists", this should definitely be required reading.
Not sure of the reason for you downvotes (perhaps it's because you're talking non-technical books), but I think everyone should read 1984 regardless of their profession. The problem being, of course, is that people take it too literally as a story and not enough as a social commentary designed to make people think twice about turning themselves over to micro-regulation.
On War by von Clausewitz. Capitalism and Freedom by Friedman for me from my 3rd year in university it completely changed me as a person.
"I'm not sure every programmer should read Elements - maybe, but its a little abstract these days."
I don't understand the "these days". Does Geometry decay? Or logic? What is the half-life of a Pythagoras' right-triangle theorem?
I don't understand the "these days". Does Geometry decay? Or logic? What is the half-life of a Pythagoras' right-triangle theorem?
Fair comment: if the geometry is done right, the geometry should be timeless.
But whether the particular presentation is worth reading, can change. 150 years ago, every person hoping to do anything vaguely mathematical should probably have read Elements.
But now, there is so much other material to pick from, I'm not sure it'd be a good use of time - it might now be a little on the abstract side, to recommend it to all modern programmers.
Thats what I was trying to get at; I should have phrased it better.
But whether the particular presentation is worth reading, can change. 150 years ago, every person hoping to do anything vaguely mathematical should probably have read Elements.
But now, there is so much other material to pick from, I'm not sure it'd be a good use of time - it might now be a little on the abstract side, to recommend it to all modern programmers.
Thats what I was trying to get at; I should have phrased it better.
Personally I'd vote for Montaigne's Essays.
Many of those books are great, and I have read shockingly many of them. However, I find all "... every x should know/have done/have read" lists very disturbing, since they seduce my ego into wasting time. Right now, my priority is reduce todo-lists, focus on less stuff that actually gets done, and use lean/just in time in as many areas as possible.
Ah, good old karma whoring times on StackOverflow, with inane questions that make people feel warm and fuzzy (and press the plus).
Please note this question was asked in 2008, when StackOverflow was considerably more tolerant of subjective questions, and it was locked to prevent any more votes. The notice on the question says "This question exists because it has historical significance, but it is not considered a good, on-topic question for this site".
For me it's not even a programming book... which is what I felt the people who have answered have artificially limited themselves to.
For me, it's: http://www.amazon.co.uk/dp/0195019199
Pattern Language
It's about architecture, buildings, towns. How to make them work, to serve all the needs of them, and how to allow them to grow.
What is important to me and influenced me heavily is the thinking behind it. All parts of a large system in harmony, well-separated concerns, and working together to achieve a common goal.
In architecture (computer as well as construction), there is also politics. We pour ourselves into these systems, our beliefs come out in their design and implementation.
There was a lot that I learned from that book, and a lot that I still go back and refer to.
GOF took their inspiration here, it's obvious from the structure... perhaps you should see why?
For me, it's: http://www.amazon.co.uk/dp/0195019199
Pattern Language
It's about architecture, buildings, towns. How to make them work, to serve all the needs of them, and how to allow them to grow.
What is important to me and influenced me heavily is the thinking behind it. All parts of a large system in harmony, well-separated concerns, and working together to achieve a common goal.
In architecture (computer as well as construction), there is also politics. We pour ourselves into these systems, our beliefs come out in their design and implementation.
There was a lot that I learned from that book, and a lot that I still go back and refer to.
GOF took their inspiration here, it's obvious from the structure... perhaps you should see why?
What is this sudden feeling? It is like a thousand HN readers cringed simultaneously.
Innovator's Dilemma would be a pretty good option for those who want to get into business with the software they make.
Nobody mentioned Programming Language Pragmatics? It's a pretty great text about how programming languages work, knowledge that's imho a prerequisite for any decent programmer.
The Elements of Style by Strunk&White.
If it has to be a programming book, then The Unix Programming Environment by Rob Pike and Brian Kernighan.
If it has to be a programming book, then The Unix Programming Environment by Rob Pike and Brian Kernighan.
Like others, I wish I had read "The C Programming Language" earlier than when I did (probably did not get to it until my mid-20's or so). However, I am really glad I read "The Road Ahead" by Bill Gates while still in high school. That gave me a "vision for the future". So in terms of "what influenced me the most" starting out, it was definitely that.
How To Win Friends & Influence People by Dale Carnegie, because software development is about a lot more than writing code.
Free Culture by Lawrence Lessig
http://www.free-culture.cc/
Patterns of Enterprise Application Architecture is one of my all time favourites, though it hasn't been as influential as it should have been.
It's sitting proudly behind me next to The Mythical Man Month, the GOF book, the Dragon book, Refactoring, Code Complete and The Visual Display of Quantitative Information.
It's sitting proudly behind me next to The Mythical Man Month, the GOF book, the Dragon book, Refactoring, Code Complete and The Visual Display of Quantitative Information.
No love for Edward Yourdon's Death March?
I think a copy should be given to every CS student upon graduation.
I think a copy should be given to every CS student upon graduation.
Haven't heard of Edward Yourdon, so Google'd. Since you are familiar, can you comment on this:
http://sunsite.uakom.sk/sunworldonline/swol-07-1997/swol-07-...
http://sunsite.uakom.sk/sunworldonline/swol-07-1997/swol-07-...
It's a good read, but it's nearly 15 years old and there may not be enough context to where Yourdon was coming from. Almost as much time has passed since this essay was written as there was in Yourdon' career up to Death March. Much has happened since then. No one uses heavyweight methodologies, like UML. Processes are light and agile. Languages like Java, Python, and Ruby are way better, as are the associated tools. I consider the 1-week release cycle the biggest contributor to productivity.
It's ancient history. Lessons have been learned.
It's ancient history. Lessons have been learned.
Maybe at the leading edge, but I joined a death-march project in 2004, then left another one in 2008.
And I believe that many young programmers are still being thrown onto late projects.
I'd really love to believe that UML is dead, but can it really be true? cite?
And I believe that many young programmers are still being thrown onto late projects.
I'd really love to believe that UML is dead, but can it really be true? cite?
The biggest takeaway from Death March for me was that politics can dominate everything else in a project. Learning the skills to identify political nonsense, understanding how it got that way and what options you have (and sometimes that meansno options at all) is something programmers should learn as soon as possible.
To be honest, I had forgotten the book contained anything about heavyweight process methodology. I'll have to grab it out of the shelf when I get home.
To be honest, I had forgotten the book contained anything about heavyweight process methodology. I'll have to grab it out of the shelf when I get home.
I'm a little surprised by the results. Why would a tome on C be the most influential book that every programmer should read?
I would think that before any of these books I would prefer that someone I was working with or hiring had read something like "How to Win Friends and Influence People" or a book on writing effectively, instead of any of the books on the first two pages.
My reasoning is that the most common problem I find with other programmers is not their programming skills, but their communication of interpersonal skills.
Edit: Aha! "How to Win Friends and Influence People" is on page 5 with 74 points!
I would think that before any of these books I would prefer that someone I was working with or hiring had read something like "How to Win Friends and Influence People" or a book on writing effectively, instead of any of the books on the first two pages.
My reasoning is that the most common problem I find with other programmers is not their programming skills, but their communication of interpersonal skills.
Edit: Aha! "How to Win Friends and Influence People" is on page 5 with 74 points!
It's not just a great C book, it's a great book. The writing is extremely clear and concise, and packs an incredible amount of information into a few short pages (short by comparison with the "doorstop" books that seem to be in vogue).
People associated with writing technical documentation of any kind could learn a lot from it.
You won't find many programming books from 1988 that are still relevant and on the market -- the only exception that comes to mind is SICP, which also has a very high rank.
People associated with writing technical documentation of any kind could learn a lot from it.
You won't find many programming books from 1988 that are still relevant and on the market -- the only exception that comes to mind is SICP, which also has a very high rank.
That's a good point. Interestingly, it also shows the weakness of the English language as a technique for expressing an idea.
I think there's an unwritten condition in the question:
"What is the single most influential [explicitly programming related] book every programmer should read?"
My guess is that is how most people interpreted the question. Of course, there's no explicit reason to interpret it this way. This just highlights the weakness of human language (that is on a standalone basis, using context human language is probably very powerful).
I think there's an unwritten condition in the question:
"What is the single most influential [explicitly programming related] book every programmer should read?"
My guess is that is how most people interpreted the question. Of course, there's no explicit reason to interpret it this way. This just highlights the weakness of human language (that is on a standalone basis, using context human language is probably very powerful).
The Hacker's Dictionary (or Jargon File, if you prefer) introduced me to a wealth of tidbits about the programming field. Either directly or indirectly, it prompted me to learn Emacs, TeX, and Lisp; to study Knuth; to volunteer for the GNU Project... but this was years ago, at a time when much of the contents of the book were somewhat historical, but still relevant. It's more out of date now, and perhaps wouldn't be as useful to novice programmers as it was for me.
Great programmers won't learn a lot of things from 'Code complete' but since the question says 'every programmers', I guess it makes sense to have it rank #1.
But talking for me, the most influential book I read is SICP.
But before that, the book that really opened my mind about 'professional programming' was effective C++. I wonder if Scott Meyers read HN.. and what's happening with him. For some reasons, I even remember the name of his dog (Persephone) which one of his book was dedicated!
But talking for me, the most influential book I read is SICP.
But before that, the book that really opened my mind about 'professional programming' was effective C++. I wonder if Scott Meyers read HN.. and what's happening with him. For some reasons, I even remember the name of his dog (Persephone) which one of his book was dedicated!
I think that if you had to select just one book, none of the obvious, literal programming or technical books would seem enough... so I would suggest "Fictions" by Borges as a real mind opener.
I just think that it will be more helpful if there is a list of books which programmers don't need to read.
there is comprehensive list at
http://www.goodbookson.com/index.php/category/programming/
the answer to this is "It depends on what matters to you". Or maybe the question was asked wrong and it should be "list the most influential books for a programmer".
Deitel and Deitel Turbo Pascal, my first programming book.
The one that helps you most. I hate questions like this because there's really no answer. If the question were which books would you recommend to me that had a big impact on you then I'd feel differently but as it stands I hate this question.
What's the best widget to help me get a random task done? Let the "definitive" answers be spewed.
What's the best widget to help me get a random task done? Let the "definitive" answers be spewed.
I'm not much of a butt-licker, but Hackers and Painters: Big Ideas from the Computer Age from PG is a classic.
http://www.amazon.com/Hackers-Painters-Big-Ideas-Computer/dp...
Code Complete is a fine book. The Pragmatic Programmer is okay. But neither book holds a candle to Introduction to Algorithms for career-long usefulness. For that matter, neither one holds a candle to Design Patterns for the ability to expand your mind and improve your ability to think about code (I read both at the same time, and Design Patterns is the only one whose lessons I remember distinctly, years later).
I think the main problem here is that the easy, mechanical reads get more votes than books that are harder, but more valuable. It's the technical equivalent of a lolcat photo.