100 best books on Software Engineering
-
according to Wiki, TurboC came out in 87. that's about when i finally graduated from BASIC and started using Modula-2 - didn't get to C for another couple of years.
Wow. That late huh? I remember my boss buying it to try to learn the NEW language everyone was talking about. He was a Fortran programmer for many years up to that time. I didn't get around to learning C until 1992 or so when the company I worked for bought me Turbo C++ 3.0 and it filled up half my 20MB hard drive. I had to spend $100 to get a new 100MB drive so I could do something with it.
-
Wow. That late huh? I remember my boss buying it to try to learn the NEW language everyone was talking about. He was a Fortran programmer for many years up to that time. I didn't get around to learning C until 1992 or so when the company I worked for bought me Turbo C++ 3.0 and it filled up half my 20MB hard drive. I had to spend $100 to get a new 100MB drive so I could do something with it.
Earl Truss wrote:
it filled up half my 20MB hard drive.
yeah. that's another reason i never got a C compiler - hard drive? i didn't get one of those till i was almost out of college! it seemed crazy to need to buy all that hardware just to write programs.
-
Compiled from Amazon reviews/rankings, Google hits and Jolt awards[^]. Personal impressions: 1) So many classics left out because they're too specific about one technology (Stevens on Unix programming, Petzold on Windows programming, K&R, etc...). 2) How many of these books do people actually read? Did anyone read all of Knuth's "Art of Computer Programming"? 3) Lots of injustices. "The Pragmatic Programmer" really deserves a better rating. "Head First Design Patterns" doesn't deserve to be 2nd. 4) Funny how many Agile-specific titles are in the list (including related like SCRUM). Specific for non-Agile I only saw on RUP. 5) Steve McConnell, Martin Fowler and Alistair Cockburn are the masters.
Of all forms of sexual aberration, the most unnatural is abstinence.
...and methodology seems to interest people more than actual methods.. anyway, some of my all time favourites (in order) are:
- "Paradigms of Artificial Intelligence Programming", Peter Norvig (Morgan Kaufmann 1991)
- "PostScript Language Tutorial and Cookbook" ...the 'blue book, Adobe Systems (Addison Wesley 1986)
- "Effective TCP/IP Programming", Jon C. Snader (Addison Wesley 2000)
- "Machine Learning", Tom Mitchell (McGraw Hill 1997)
-
K&R's "The C Programming Language" is the only programming book i really like. it is short and to the point. the examples are clear and concise. and it covers the entire language in just enough detail. it's an invaluable reference.
-
i hate books about programming.
I think everybody is missing the point: software engineering books aren't books about programming, but about managing the software development process, from inception to delivery. Re. the original question, I like "Object-Oriented Software Engineering" by Bernd Bruegge and Allen H. Dutoit, although it's somewhat repetitive. I don't agree with reference books like Booch, Rumbaugh and Jacobson's UML book being in the list. This is just an UML reference book, but doesn't do very good in teaching a SE methodology. "The Mythical Man Month" may be technically outdated, but it's a classic. A must-read for every software engineer. As for the people who hate reading programming books (and I wonder if they even read any kind of book), I've seen too many of the kind writing (or rather copying and patching) code they don't understand, yielding to error-prone, unmantainable, non-reusable code.
Regards, Ricardo Corona
-
I think everybody is missing the point: software engineering books aren't books about programming, but about managing the software development process, from inception to delivery. Re. the original question, I like "Object-Oriented Software Engineering" by Bernd Bruegge and Allen H. Dutoit, although it's somewhat repetitive. I don't agree with reference books like Booch, Rumbaugh and Jacobson's UML book being in the list. This is just an UML reference book, but doesn't do very good in teaching a SE methodology. "The Mythical Man Month" may be technically outdated, but it's a classic. A must-read for every software engineer. As for the people who hate reading programming books (and I wonder if they even read any kind of book), I've seen too many of the kind writing (or rather copying and patching) code they don't understand, yielding to error-prone, unmantainable, non-reusable code.
Regards, Ricardo Corona
GandalfElGris wrote:
I think everybody is missing the point: software engineering books aren't books about programming, but about managing the software development process, from inception to delivery.
point taken.
GandalfElGris wrote:
As for the people who hate reading programming books (and I wonder if they even read any kind of book), I've seen too many of the kind writing (or rather copying and patching) code they don't understand, yielding to error-prone, unmantainable, non-reusable code.
meh. the point you'd really want to make is that people who read books don't make those mistakes. but if you actually tried to make that point, i'd ask to see your data.
GandalfElGris wrote:
and I wonder if they even read any kind of book
what on earth could you mean by that? personally, i read about a book a month: fiction, non-fiction, scientific, essays, whatever looks good - but none of them are programming books.
-
Diego Moita wrote:
"Head First Design Patterns" doesn't deserve to be 2nd.
Yes, that was my impression as well. I have read only 12 full (c to c). I have the Knuth books but never proceeded on them significantly. Same with Cormen, book I read only a few portions of it on an as required basis.
Diego Moita wrote:
Did anyone read all of Knuth's "Art of Computer Programming"?
He will be my hero, though he will not have an time to make a post here:).
-
I hate books ABOUT programming, too! Talk about insomnia cure ;-) Unfortunately, it's still one of the least expensive ways to learn how (the Internet notwithstanding -- getting better; not there yet).
Talk about boring, try a book on linear algebra taught from a theoretical perspective.
-
That's like being a Doctor, not a medicine book reader...would you go to that doctor? How about a Lawyer, not a law book reader...would you trust this guy to get you out of jail? OK, taking classes definitely helps, but how do you think the instructor learned what he's teaching? The internet is full of samples, true, but are they trustworthy? efficient? proven to work? Besides, what difference does it make to read form the internet than to read from a book? I know I know, the internet is more convenient, easy to search the exact topic, etc., in other words, it's like a customizable book, you create your own. But it's still reading! What I can't stand about programming books is that they are so expensive!
rickyvj wrote:
What I can't stand about programming books is that they are so expensive!
Turn that into a formal motion and I'll gladly second it.
-
I think everybody is missing the point: software engineering books aren't books about programming, but about managing the software development process, from inception to delivery. Re. the original question, I like "Object-Oriented Software Engineering" by Bernd Bruegge and Allen H. Dutoit, although it's somewhat repetitive. I don't agree with reference books like Booch, Rumbaugh and Jacobson's UML book being in the list. This is just an UML reference book, but doesn't do very good in teaching a SE methodology. "The Mythical Man Month" may be technically outdated, but it's a classic. A must-read for every software engineer. As for the people who hate reading programming books (and I wonder if they even read any kind of book), I've seen too many of the kind writing (or rather copying and patching) code they don't understand, yielding to error-prone, unmantainable, non-reusable code.
Regards, Ricardo Corona
GandalfElGris wrote:
software engineering books aren't books about programming, but about managing the software development process
So you're saying that Knuth's not about software engineering, and nor is Dahl, Dijkstra and Hoare -- welcome the Brave New World! I know D,D&H is not in Amazon's list, but it's on my bookshelf, I think it was the first SE book I ever bought.
-
Compiled from Amazon reviews/rankings, Google hits and Jolt awards[^]. Personal impressions: 1) So many classics left out because they're too specific about one technology (Stevens on Unix programming, Petzold on Windows programming, K&R, etc...). 2) How many of these books do people actually read? Did anyone read all of Knuth's "Art of Computer Programming"? 3) Lots of injustices. "The Pragmatic Programmer" really deserves a better rating. "Head First Design Patterns" doesn't deserve to be 2nd. 4) Funny how many Agile-specific titles are in the list (including related like SCRUM). Specific for non-Agile I only saw on RUP. 5) Steve McConnell, Martin Fowler and Alistair Cockburn are the masters.
Of all forms of sexual aberration, the most unnatural is abstinence.
I'm surprised that so many seem to think that these books are to be read cover to cover like a novel, surely many of them are works to which one turns in order to solve a problem, divine a solution etc - Knuth's The Art of Programming is a good example of that, as the OP asked who's ever read all of it. I've read Gibbon cover to cover, as well as all 5 volumes of Macaulay; but I cant think of any SoftEng writer that has anything like the literary ability of those authors. Perhaps that's why I almost never read SE books from cover to cover, and then only if they're very short. I doubt any software engineering book has ever featured in The New York Review of Books or Granta, anyone know of any?
Diego Moita wrote:
So many classics left out because they're too specific about one technology
That's not the primary reason; mainly it's because they are out of print. Remember this is a booksellers top 100, you won't find things they can't or don't sell. I would have hoped to see classics like Structured Programming by Dahl, Dijkstra & Hoare and some of James Martin's early works (i.e. before he went into his "book a month" phase), they aren't technology specific.
-
Compiled from Amazon reviews/rankings, Google hits and Jolt awards[^]. Personal impressions: 1) So many classics left out because they're too specific about one technology (Stevens on Unix programming, Petzold on Windows programming, K&R, etc...). 2) How many of these books do people actually read? Did anyone read all of Knuth's "Art of Computer Programming"? 3) Lots of injustices. "The Pragmatic Programmer" really deserves a better rating. "Head First Design Patterns" doesn't deserve to be 2nd. 4) Funny how many Agile-specific titles are in the list (including related like SCRUM). Specific for non-Agile I only saw on RUP. 5) Steve McConnell, Martin Fowler and Alistair Cockburn are the masters.
Of all forms of sexual aberration, the most unnatural is abstinence.
There is a lot of discussion here that seems to be more about individual learning styles rather than the best SE books. Personally, I get a great deal from reading. I always have. However, I would not list anything as skill on a resume from 'book learning' alone. I would not feel comfortable claiming to know an SE methodology, language, pattern, or whatever unless I had actual developed something with it. My own code. Not just running samples. I feel that SE books have had a greater impact on the overall quality of my code than have the nuggets of code and advice I have gleaned from the internet. OOD/OOP concepts, Design Patterns, database design big picture things all come better to me from books. Remembering particular languages switch statement syntax or looking up sample implementations of a pattern is where the internet comes through for me. On a daily basis for the little things I hit the F1 key, then if necessary google, then maybe a reference book. But when experimenting with a new larger topic like learning a new language or development methodology I hit the books first. After reading a bit, I may actual drop this subject from my interests or pursue it in some actual coding effort. If I don't actually use the new knowledge on something I will likely forget most of it fairly quickly.
-
GandalfElGris wrote:
software engineering books aren't books about programming, but about managing the software development process
So you're saying that Knuth's not about software engineering, and nor is Dahl, Dijkstra and Hoare -- welcome the Brave New World! I know D,D&H is not in Amazon's list, but it's on my bookshelf, I think it was the first SE book I ever bought.
Where did you get that? I didn't even question the list as I must admit I haven't read all of the books. What I said was that most replies were not answered re. software engineering books but about programming books. I agree with you that Knuth's & DD&H books should be in any software engineer or programmer's bookshelf.
Regards, Ricardo Corona
-
GandalfElGris wrote:
I think everybody is missing the point: software engineering books aren't books about programming, but about managing the software development process, from inception to delivery.
point taken.
GandalfElGris wrote:
As for the people who hate reading programming books (and I wonder if they even read any kind of book), I've seen too many of the kind writing (or rather copying and patching) code they don't understand, yielding to error-prone, unmantainable, non-reusable code.
meh. the point you'd really want to make is that people who read books don't make those mistakes. but if you actually tried to make that point, i'd ask to see your data.
GandalfElGris wrote:
and I wonder if they even read any kind of book
what on earth could you mean by that? personally, i read about a book a month: fiction, non-fiction, scientific, essays, whatever looks good - but none of them are programming books.
Chris Losinger wrote:
meh. the point you'd really want to make is that people who read books don't make those mistakes. but if you actually tried to make that point, i'd ask to see your data.
How would you know my point better than myself? Anyway granted, a lot of programmers who read programming books do the same and worse mistakes. But they are simply lousy programmers, and would remain lousy with or without reading. My point would really be that I don't see how anyone could learn concepts like modeling, methodologies, frameworks, algorithms, etc., without reading or attending a class -which you also despise-. I wonder how you've learnt these concepts by just reading source code. I must agree with you, however, that many programming books are bad. Most of them show you how to code in a particular language through sample code and algorithms, but they don't teach you how to write applications using a certain methodology -for which a chosen language is needed-.
Chris Losinger wrote:
what on earth could you mean by that? personally, i read about a book a month: fiction, non-fiction, scientific, essays, whatever looks good - but none of them are programming books.
Good for you. I didn't mean for you taking it personally, but I've known quite a few students & programmers who hate reading programming books just because they don't like reading any kind of books.
Regards, Ricardo Corona
-
Chris Losinger wrote:
meh. the point you'd really want to make is that people who read books don't make those mistakes. but if you actually tried to make that point, i'd ask to see your data.
How would you know my point better than myself? Anyway granted, a lot of programmers who read programming books do the same and worse mistakes. But they are simply lousy programmers, and would remain lousy with or without reading. My point would really be that I don't see how anyone could learn concepts like modeling, methodologies, frameworks, algorithms, etc., without reading or attending a class -which you also despise-. I wonder how you've learnt these concepts by just reading source code. I must agree with you, however, that many programming books are bad. Most of them show you how to code in a particular language through sample code and algorithms, but they don't teach you how to write applications using a certain methodology -for which a chosen language is needed-.
Chris Losinger wrote:
what on earth could you mean by that? personally, i read about a book a month: fiction, non-fiction, scientific, essays, whatever looks good - but none of them are programming books.
Good for you. I didn't mean for you taking it personally, but I've known quite a few students & programmers who hate reading programming books just because they don't like reading any kind of books.
Regards, Ricardo Corona
GandalfElGris wrote:
How would you know my point better than myself?
well, if you're asserting that non-readers make lousy programmers, i think you need to show that readers don't make lousy programmers. otherwise, it's like saying "short people make bad programmers because they make all these mistakes!" - but never looking to see if short people make more or fewer mistakes than anyone else.
GandalfElGris wrote:
My point would really be that I don't see how anyone could learn concepts like modeling, methodologies, frameworks, algorithms, etc., without reading or attending a class -which you also despise-. I wonder how you've learnt these concepts by just reading source code.
i got my BS in Computer Science by being a student and taking classes (and i slept through a lot of those, too!). but college classes are a lot different than all those the three- and five-day training classes i've taken in the decades since. in my experience, those short training classes are uniformly weak. they can give an introduction to a topic, but to really learn it, i've got to use it. and there are plenty of other things for programmers to read besides programming books : white papers, CP articles, blog[^] posts[^], etc.. big expensive badly-written books are most definitely not the best way for me to learn.
GandalfElGris wrote:
I didn't mean for you taking it personally
mm k. guess i jumped the gun there.
-
You're absolutely right. I guess ideally you want to look for someone who has a good mix of both, real practice experience and academic/reading experience. Too much of one without the other can lead to trouble. As someone already said, reading is just a complement to experience, not a replacement.
rickyvj wrote:
As someone already said, reading is just a complement to experience, not a replacement.
Likewise, an experienced programmer becomes obsolete without reading.
Regards, Ricardo Corona
-
Where did you get that? I didn't even question the list as I must admit I haven't read all of the books. What I said was that most replies were not answered re. software engineering books but about programming books. I agree with you that Knuth's & DD&H books should be in any software engineer or programmer's bookshelf.
Regards, Ricardo Corona
Perhaps I falsely interpolated what you wrote to be "software engineering books [are] ... about managing the software development process" By my definition of managing a process I don't see much in that regard in Knuth, DDH and some of the other books in Amazons list. I am not saying that SDLC management is not SE. However I am saying that SE is more than SDLC management, other facets include techniques, algorithm selection etc.