

Books every developer should read - simenfur
http://blog.iterate.no/2012/08/19/books-everybody-should-read/

======
CJefferson
Two books I think every developer should read:

'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.

~~~
nikcub
Here is the Reymond Chen blog, which I would +1, sorted by most popular post:

[http://blogs.msdn.com/b/oldnewthing/default.aspx?PostSortBy=...](http://blogs.msdn.com/b/oldnewthing/default.aspx?PostSortBy=MostViewed&PageIndex=1)

------
gizzlon
" _The books chosen are generally and broadly useful and not tied to some too
limited domain_ "

Yet 3 of 4 have "lean" or "agile" in the tile ..

~~~
mortenberg
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.

------
shock3naw
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.

~~~
PuerkitoBio
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.

------
jacques_chester
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.

~~~
nikcub
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.

Link to the search result page:

[https://www.google.com/search?num=50&hl=en&newwindow...](https://www.google.com/search?num=50&hl=en&newwindow=1&q=site%3Anews.ycombinator.com+programming+books)

Image link incase you don't see it on your Google:

[https://img.skitch.com/20120820-g8phi24s3ngq7khyimq5wqnabg.j...](https://img.skitch.com/20120820-g8phi24s3ngq7khyimq5wqnabg.jpg)

~~~
timo614
It looks like those aren't limited to what hacker news users have mentioned
but the web in general.

If you just do a normal search for programming books the same exact list in
the same order appears.

Still a cool feature if you want the most mentioned books on the web for a
given subject.

------
_gbc
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.

------
jgrodziski
Here is my list : [http://www.zenmodeler.com/design-matters/books-
recommandatio...](http://www.zenmodeler.com/design-matters/books-
recommandations/) It's the books that struck me the most, I do not pretend it
to be exhaustive.

I also strongly agree with @shock3naw: do a lot, read a little in between

------
systems
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

------
JPRan
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.

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

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

