Books every developer should read

Two books I think every developer should read:<p>'The Design and Evolution of C++' by Bjarne Stroustrup<p>'The Old New Thing: Practical Development Throughout the Evolution of Windows' by Raymond Chen (you could just read through his blog, book I quite enjoyed having a book).<p>What I feel these books really helped with was understanding how a large complex real-world system, designed and maintained by clever people, can end up with so many weird features, and how the smallest things can end up being problems the dog you for decades. These are the only two books I am aware of that make an attempt at discussing how some big complex systems (C++ and Windows) ended up how they are, and tell some interesting stories of how various features arose, and why others didn't.

"<i>The books chosen are generally and broadly useful and not tied to some too limited domain</i>"<p>Yet 3 of 4 have "lean" or "agile" in the tile ..

I'll be honest, I've read a very small number of books on software development throughout the years. I've learned all my stuff on the way, from mistakes I've made, associated documentation, and from reading the code that's powering production systems from the engineers before me. In the end? I'm doing pretty well. I'm sure that anyone else in a similar situation would agree.<p>Reading these books isn't going to make you a rockstar/ninja/allstar programmer. Keep doing what you're doing, learn from the mistakes you make; the lessons you learn from them are going to last a lifetime. The lessons you learn from these books might make you a better programmer, but almost all of it will be gone in a week.

These are a bit specific. I feel as though they might, in fact, have been the last 4 books the author has happened to read.<p>Anyhow, I expect we'll get the usual round up here. <i>Code Complete</i>, of course; plus a smattering of rebels who think it was boring or irrelevant. <i>The Pragmatic Programmer</i> will receive universal praise, especially from those who didn't take the time to read <i>Code Complete</i> from cover to cover.<p>Some of the debate will be about whether <i>Code Complete</i> is "better" than <i>Clean Code</i> or not. A silly argument, they are complementary (though, really, is this even a debate worth having? <i>Code Complete</i> is clearly the better book).<p>Let's see, what else?<p><i>Structure and Interpretation of Computer Programs</i> will get mentioned, which will spawn a fertile subthread arguing about whether computer science books really belong on a list for developers. That subthread will debate the merits of <i>Introduction to Algorithms</i> vs everything else, and someone will mention a lisp book that changed their life. Probably <i>Paradigms of Artificial Programming</i> or <i>On Lisp</i>.<p>The Gang of Four will get nodded at. Like the Bible, Homer, or <i>Peopleware</i> it will be the book everyone says they've read but which almost nobody has actually read.<p><i>The C Programming Language</i> will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue.<p>Myself? I'd definitely have <i>Code Complete</i> (I still have my first edition), perhaps <i>A Discipline for Software Engineering</i> and <i>Software Estimation: Demystifying the Black Art</i>. I've found pretty much everything from Dorset House to be worth my time, so to <i>PeopleWare</i> I'd add <i>The Deadline</i> and <i>Adrenalin Junkies and Template Zombies</i>.<p>What we don't do in this industry, however, is read more widely. Get out of your rut. Read about history, read some classics, read deeply in another field you pursue as your hobby. Everything illuminates everything. Get out there, see the intellectual sights (for which, get a copy of <i>Dawn to Decadence</i> by Jacques Barzun for a guided tour). You'll be a better developer and a better person for the trouble.

Speaking as a non-developer, here's one which I think every developer and manager should read: Rapid Development by Steve McConnell. I am currently about 3/4 of the way through and it has been excellent so far.

Here is my list : <a href="http://www.zenmodeler.com/design-matters/books-recommandations/" rel="nofollow">http://www.zenmodeler.com/design-matters/books-recommandatio...</a> It's the books that struck me the most, I do not pretend it to be exhaustive.<p>I also strongly agree with @shock3naw: do a lot, read a little in between

one big problem that i found most software development methodology ignore is whether you are the developer or the client (the IT department hiring contracting the developer)<p>you have to agree on an offer/contract, which include scope + price/cost<p>how can i be lean or agile or whatever, if i am bound by a contract from the start ... making change requests mean that me the IT department failed to deliver on time and on budget, which eventually leads to bad annual reviews ...<p>having the have a contract or a signed offer approved by business, enforces the water fall model, an internal IT department have to do this to protect itself from the client when a change request is made later on ...<p>of course i am only speaking on the situation where you work in an IT department and getting your software developed by external vendors

That's according to you. So the title is misleading.<p>None of these books are any good. I've been in software development for over 20 years and I would recommend a completely different list of books, that are not as trendy as yours, but probably more important.

So, how many pages do you have to peruse to get "lean"?

sheesh, if you want get better, ditch the books and put the time into learning haskell or something.