100 best books on Software Engineering
-
Chris Losinger wrote:
you get a compiler, you look for code samples, and then you solve the problem at hand.
Programmers that just learn by 'getting a compiler' and copy/pasting code from the internet are the same that keep on band-aiding the software, instead of coming up with elegant solutions that only books can teach. My point exactly, crappy code will solve the problem. I just don't look for how to solve the problem. I look for how to solve this problem and future problems and make the software robust and scalable.
Chris Losinger wrote:
i've been programming since 1982.
So, have you been using the internet since 1982?
Chris Losinger wrote:
frankly, most classes are even worse. but at least you can ask questions (or take naps) in class.
Ah, I see, in 1982 you were taking naps, nice way to learn C and C++!
rickyvj wrote:
Programmers that just learn by 'getting a compiler' and copy/pasting code from the internet are the same that keep on band-aiding the software, instead of coming up with elegant solutions that only books can teach.
how silly. band-aiding software has far more to do with schedule and money than with where or how the programmer learned the language. even the best programmer is going to patch rather than refactor, if time is critical. and the idea that only books can teach "elegant solutions" is sheer nonsense. were there no elegant solutions before the first programming book was written ?
rickyvj wrote:
I just don't look for how to solve the problem. I look for how to solve this problem and future problems and make the software robust and scalable.
how wonderful for you! is that work ethic something that can only come from a book or is it simply the common human traits called "taking pride in your work" and "planning ahead" ?
rickyvj wrote:
So, have you been using the internet since 1982?
don't be an idiot.
rickyvj wrote:
Ah, I see, in 1982 you were taking naps, nice way to learn C and C++!
in 1982, there was no language named "C++". BASIC and Assembly were the options for most of us who didn't have access to university computers.
-
I couldn't disagree with you more. Just because you write software and you've been doing it for 10 yrs doesn't mean you're a good programmer. In fact, someone who hasn't had formal training, develops his own habits and methods, and is used to organically grows software that ends up being a nightmare to maintain. Software that works, of course, but highly inefficient and expensive. (I know I'm generalizing but that's the impression I've gotten from my engineers who don't read...) In other words, how do you think this 10yr experienced programmer learned whatever got him in the job in the first place? I don't think there's a way to learn anything without reading, just from classes and going to school is mediocre, you have to go the extra step and teach yourself (by reading) to be exceptional. I don't know anybody who graduated from school with honors without reading (unless maybe me, but I still read a lot, not a nerd but I like to read.) Someone who is interested about reading is someone who's interested about learning and applying new techniques to make the software better, easier and cheaper!
Note that I didn't say you shouldn't read; I even recommended some books. I said it was overrated--I place far greater emphasis on actual experience. I even illustrated the problem of substituting reading for experience. The same applies to formal education. Both lead to a largely academic view of programming because most of both are written by academics. Also note that most the books on the list are about process and those are generally the most useless of all. My own experience is partly the opposite of yours; that developers who read too much or who have PhDs are far to academic in their approach, lack creativity and attempt to force all the examples they read into their code (I can give you several real world stories about that.) Their code is the worse, most inefficient, code I deal with. In general, they are so concerned about design patterns and using the latest "in" thing in programming, their code is overly complex and poor performing. That said, I've also worked with plenty of lazy programmers who appear to have gotten into the field because they heard it paid good or something like that. I actually worked with one such fellow who read all sorts of books on process and was always trying new languages--took me a while to realize he was compensating for the fact that he was a terrible engineer and all the "new" stuff hid that fact (in a Dilbert moment, the guy was a darling of the bosses and got promoted.) Frankly, if you want the very best thing to read it is the entire documentation for the Win32 API in MSDN and, for .NET developers, the entire .NET documentation in MSDN. Sounds boring and tedious, but the payoff is tremendous.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
CDMTJX wrote:
Effective C++ by Meyers
I found Effective C to be a better book, though this isn't bad with some major caveats (haven't read it in a while, but I do recall some of his points were rather academic and a few just plain wrong.) I was confusing Effective C++ and More Effective C++, both by Meyers. The former is a vastly better book than the latter, though I understand many of the problems with the latter (like all the weird errors) have been corrected.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Thursday, January 22, 2009 12:15 PM
-
Note that I didn't say you shouldn't read; I even recommended some books. I said it was overrated--I place far greater emphasis on actual experience. I even illustrated the problem of substituting reading for experience. The same applies to formal education. Both lead to a largely academic view of programming because most of both are written by academics. Also note that most the books on the list are about process and those are generally the most useless of all. My own experience is partly the opposite of yours; that developers who read too much or who have PhDs are far to academic in their approach, lack creativity and attempt to force all the examples they read into their code (I can give you several real world stories about that.) Their code is the worse, most inefficient, code I deal with. In general, they are so concerned about design patterns and using the latest "in" thing in programming, their code is overly complex and poor performing. That said, I've also worked with plenty of lazy programmers who appear to have gotten into the field because they heard it paid good or something like that. I actually worked with one such fellow who read all sorts of books on process and was always trying new languages--took me a while to realize he was compensating for the fact that he was a terrible engineer and all the "new" stuff hid that fact (in a Dilbert moment, the guy was a darling of the bosses and got promoted.) Frankly, if you want the very best thing to read it is the entire documentation for the Win32 API in MSDN and, for .NET developers, the entire .NET documentation in MSDN. Sounds boring and tedious, but the payoff is tremendous.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
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.
-
My mistake. I was confusing Effective C++ and More Effective C++, both by Meyers. I liked much of the former, though some of his advice is bogus, and didn't like the latter. It was chock full of mistakes and mixed some really good advise with really terrible advise, sometimes in the same "chapter." I understand that some of this has been corrected in later versions. One thing I do like about Meyers is that he makes it clear that these are guidelines, not commandments. He seems less rigid in his advise than some of his fans!
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Martin Fowler, Jon Bently, Frederick P. Brooks, and Eric Gamma titles worth a look. Most of the rest are pretty hit and miss. Donald Knuth is a legend, but I agree with the earlier comments, to me he is perhaps not a great popular writer, his books are pretty intimidating. I preferred reading Robert Sedgewicks stuff, he was a student of Knuth. I've read some of the Agile stuff, it has its place but it occupies far too much of the top 100 as stated. A lot of the Agile, UML, SOA and patterns books are in reality pretty average books. No K&R, Bjarne Stroustrup C++, or Penfold get serious ? Never been a fan of Steve McConnell books personally, so I can't see why he gets top spot or four books in top 100. The list seems to take a publishers view of 'Software Engineering' titles, its a pretty lazy list probably generated by a computer ? A few gems in there though...
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.
-
rickyvj wrote:
Programmers that just learn by 'getting a compiler' and copy/pasting code from the internet are the same that keep on band-aiding the software, instead of coming up with elegant solutions that only books can teach.
how silly. band-aiding software has far more to do with schedule and money than with where or how the programmer learned the language. even the best programmer is going to patch rather than refactor, if time is critical. and the idea that only books can teach "elegant solutions" is sheer nonsense. were there no elegant solutions before the first programming book was written ?
rickyvj wrote:
I just don't look for how to solve the problem. I look for how to solve this problem and future problems and make the software robust and scalable.
how wonderful for you! is that work ethic something that can only come from a book or is it simply the common human traits called "taking pride in your work" and "planning ahead" ?
rickyvj wrote:
So, have you been using the internet since 1982?
don't be an idiot.
rickyvj wrote:
Ah, I see, in 1982 you were taking naps, nice way to learn C and C++!
in 1982, there was no language named "C++". BASIC and Assembly were the options for most of us who didn't have access to university computers.
Chris Losinger wrote:
in 1982, there was no language named "C++". BASIC and Assembly were the options for most of us who didn't have access to university computers.
You forgot Fortran and COBOL. I think C and Pascal were around at that time too.
-
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.
Diego Moita wrote:
- How many of these books do people actually read? Did anyone read all of Knuth's "Art of Computer Programming"?
Well, yes, but that was back when there were a lot less programming books and even less that were good.
-
Chris Losinger wrote:
in 1982, there was no language named "C++". BASIC and Assembly were the options for most of us who didn't have access to university computers.
You forgot Fortran and COBOL. I think C and Pascal were around at that time too.
i didn't really forget them, it's just that for most of us who didn't have access to university (or business) computers, there was no way to really use them. home PCs came with BASIC and Assembly and that was what you used (and you liked it!). you could buy compilers for those other languages, but i remember them being very expensive. i did buy a Modula-2 compiler once i was old enough to get a job. probably the only 16 year-old in town who even knew what Modula-2 was :)
-
i didn't really forget them, it's just that for most of us who didn't have access to university (or business) computers, there was no way to really use them. home PCs came with BASIC and Assembly and that was what you used (and you liked it!). you could buy compilers for those other languages, but i remember them being very expensive. i did buy a Modula-2 compiler once i was old enough to get a job. probably the only 16 year-old in town who even knew what Modula-2 was :)
Didn't TurboC come out in the early 80s? Of course, it did cost $99 which was a lot to pay if you even owned your own computer then.
-
Didn't TurboC come out in the early 80s? Of course, it did cost $99 which was a lot to pay if you even owned your own computer then.
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.
-
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.