'The Design and Evolution of C++' by Bjarne Stroustrup
'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).
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.
They might be tied to our preferred software development methodologies, but what we meant is that they are not tied to any specific business domain or programming language.
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.
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.
I disagree. While it's true that it won't make you a "ninja" programmer, books are still one of the best way to learn something, and obviously that doesn't apply only to programming. Hands-on experience is a very important complement, but if the engineers thatbwrote the production code you learn from aren't any good, and your coworkers are so-so, how will you ever know you're doing things wrong?
Books may also open your mind to new ways of doing things, or a deeper understanding of how / why some things work the way they do. Yes it requires dedication, learning (durably) is hard, it should not be a passive read. For example, I've always been curious about how compilers work, and I'm currently reading the Dragon Book. It is hard, but extremely interesting and fulfilling (if that's the right word, english is not my native language).
So my advice, yes keep writing and reading code (especially from a well-known open-source project), but DO read books. Combined with hands-on experience and serious dedication, the lessons learned will become part of your instincts.
This would be a much stronger argument if you didn't start by saying you hadn't read many books. Both Code Complete and Refactoring changed the way I wrote (and thought) about code in a lasting way.
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.
Anyhow, I expect we'll get the usual round up here. Code Complete, of course; plus a smattering of rebels who think it was boring or irrelevant. The Pragmatic Programmer will receive universal praise, especially from those who didn't take the time to read Code Complete from cover to cover.
Some of the debate will be about whether Code Complete is "better" than Clean Code or not. A silly argument, they are complementary (though, really, is this even a debate worth having? Code Complete is clearly the better book).
Let's see, what else?
Structure and Interpretation of Computer Programs 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 Introduction to Algorithms vs everything else, and someone will mention a lisp book that changed their life. Probably Paradigms of Artificial Programming or On Lisp.
The Gang of Four will get nodded at. Like the Bible, Homer, or Peopleware it will be the book everyone says they've read but which almost nobody has actually read.
The C Programming Language will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue.
Myself? I'd definitely have Code Complete (I still have my first edition), perhaps A Discipline for Software Engineering and Software Estimation: Demystifying the Black Art. I've found pretty much everything from Dorset House to be worth my time, so to PeopleWare I'd add The Deadline and Adrenalin Junkies and Template Zombies.
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 Dawn to Decadence by Jacques Barzun for a guided tour). You'll be a better developer and a better person for the trouble.
You saved me a comment, none of the books in OP are really 'must read' and most of them are about project management methodology, not programming.
I was going to add to what you said with a link to a specific former thread I remember that was good, and it caused me to stumble onto a new feature in Google that I haven't seen before and which is most excellent.
If you google for:
site:news.ycombinator.com programming books
You get a summary with covers and links to Google Books of the most-mentioned books on HN.
> Get out of your rut. Read about history, read some classics, read deeply in another field you pursue as your hobby.
Good advice. Sticking close to software, business and economics are handy subjects to understand more about if you're a developer.
Going further abroad is a nice break from all software/startups, all the time. I like to read history books myself, although it's tricky to find good ones.
Sure. Reading lightly in human factors and systems has been a real eye-opener. Reading deeply on Olympic weightlifting, strength training and so forth has also given what are to me deep analogies back into software development.
Similarly, some bits of the bible really speak to me, even though I'm an atheist and I think most of it is hilaribad. There is nothing new under the sun ...
I'd recommend staying away from the classics and also a lot of popular history books, in fact stay away from the books most commonly read by the general population and also by your peers. (Unless you really want to read them, or have nothing better to read, suit your fancy.) Why? If something is read widely, the important parts of it are likely to seep into your brain sooner or later regardless of if you read the book anyway. Especially if the book is fiction, but it works with popular nonfiction too. The advice is for avoiding commonly read books, however, not subjects or genres (indeed, fining uncommon books on "known" subjects that contradict that which is "known" can be very rewarding), and the "by your peers" qualifier allows "guiltless" reading of bestsellers your peers have no clue about.
Reading less-read things will give you an orthogonal base of knowledge from your peers. This will make you more valuable as an individual. (Though if you're ignorant of the cogwork everyone must know as general knowledge you might face job dangers.) By definition adding another dimension to what you know gives you a whole new place to explore that you never could have gone to beforehand. There is a lot more potential to be found by reading the more uncommon things.
Since we're all leaving book recommendations, the last book I read was The Information, http://www.amazon.com/The-Information-History-Theory-Flood/d.... Not incredibly rare but not incredibly common--hardly any of its elaborated history was ever mentioned in my K-12 education. I wouldn't say everyone should read it, though I thoroughly enjoyed it, and you can read the reviews on Amazon if you want a sample of opinions.
Thank you for your comment, I thoroughly enjoyed it. Thank you also for summarizing the many forseeable possible discussions upfront so that we could have avoided them here.
The books were chosen by a group of five, half of us with 10-15 years of experience, so no, they aren't the latest books the author by a chance happend to read.
I admit that, as others have complained, the title might be percieved as misleading. The reason is that these are books that our company recommends to its developers and we want the developers to be something more than coders (= what most people understand under 'developer'). Though it's important to write great code, it's even more important, IMHO, that it is the right code that gets written, i.e. that the resources available are used to produce the maximal business value possible (and we believe that this cannot be planned but must be discovered based on feedback from reality - that's why lean/agile). Going quickly (great coding skills) in the wrong direction isn't progress.
Some of us have read Code Complete or The Pragmatic Programmer but it hasn't made it into the list. More of us will read it now and we will reevaluate the list afterwards. I hope it's good with you :-)
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.
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)
you have to agree on an offer/contract, which include scope + price/cost
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 ...
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 ...
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.
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.
'The Design and Evolution of C++' by Bjarne Stroustrup
'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).
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.