I'm surprised The Mythical Man-Month didn't make the 30 (only the afterthought section). Given the harm that clumsy estimation, and naieve subdivision of labour from disinterested managers causes to the software industry it should be required reading.
Yes, that's a good list as well. I actually went through that whole SO thread and bought many of the books, but the SO thread is just for programmers. This list is for people in software business in general, especially people in small companies.
Not that these are bad books (I've read a lot of them and they are quite interesting), but I think there's more value in compiling a list of the 5 most important books we should read, rather than the 30.
Of course we can learn something from reading 30 books. It'd almost be hard not to (if you chose the right genre). The problem is that, while entertaining, I'm sure a lot of us are looking at these books not just for fun, but because we want to figure out how to run our software business.
To take every software book that's imparted some little bit of insight and put it in a huge list only gives you a huge list of books to read, with no indication of which 20% of those books will give you 80% of the insight. And while some of us can digest this list in two weeks, for others it's a huge time commitment they don't have the ability to make.
I apologize for ranting, and this list does have some useful information (especially in the commentary on each book). But I get uncomfortable when I see a "Top X design articles" or "Top Y books" and the X or Y is >10. I feel like we are feeding our desire to gorge on numerically delimited information without necessarily getting substance out of it.
I don't agree. Giving 30 books vastly increases the chance that any given reader can find the "right" 20%. Your 20% might not be mine; although I would find it interesting if you posted your top 5 books, I'd rather see the 30 that you read, so that I can read them all and find my own top 5.
My reaction tends to be opposite yours: when someone gives me the "top 5", I consider it only a trailhead; it's unlikely my top 5 would be the same.
> when someone gives me the "top 5", I consider it only a trailhead; it's unlikely my top 5 would be the same.
That's a fair point. The important part, it seems, is identifying not just which books to read but why. That information would help you and I find our 20%.
I did not see it on the list but Showstopper is an very good book(http://www.amazon.com/Showstopper-Breakneck-Windows-Generati...) It tells the story of the Windows NT team's couple years of major ups and downs developing the windows. It starts from the hiring of Dave Cutler from DEC to the release of the project. If you want a good view into how large software projects go I think you can't go wrong with this book. You get an idea for why the Windows team made some tradeoff (like security ;p) made in those days to finish the product and how a strong project leader was a must to keep the project on track.
I can't recommend the book enough I've read it a few times already.
I'd add Business @ The Speed of Thought by Bill Gates. Yeah, yeah, go ahead and laugh if you want.... It's a seriously interesting book. And this is coming from a guy who's a huge F/OSS ideologue and who really isn't a fan of Microsoft or billg. But I can give the Devil his due when necessary, and B@TSOT is a worthwhile read.
Of course, you might ask "Why, mindcrime, why do you recommend a billg book so highly?" Fair question... I find it interesting for the vision that Gates lays out regarding how organizations should use technology to operate more efficiently. He leaned heavily on the analogy with the human autonomic nervous system back in those days, and was throwing around the term "Digital Nervous System[1]" a lot... and I think that that concept A. makes and lot of sense, and B. is still - after all these years - largely unfulfilled.
If you're in the business of software (at least the business of business software) I think the Gates book is still very inspirational and could seed some very interesting ideas, vis-a-vis technology in organizations.
I knew a programmer on the Chandler team. When I read the wiki and tried it out, I remember thinking, "This is Mitch's doomed vanity project." (Of course I had the usual doubts on whether I understood what was going on, but simply I couldn't see it living up to its hype.)
I haven't yet read the book on it (_Dreaming in Code_), but the question in my mind wasn't how it failed, but how it couldn't fail...
I just finished _Dreaming in Code_ Friday night. A deep dive into http://chandlerproject.org/ afterward was one of the more depressing experiences I've had in recent memory: all that effort, abandoned.
Unfortunately I succumbed to several dozen of these mass business books before realizing how utterly insipid this industry is... Just learn to write a business plan and get busy already. Great free articles (& some paid) on both hbr.org and score.org.
"Outliers"? Malcolm Gladwell is an entertaining writer, but I really wouldn't take it too serious... extrapolating way too much, and then reaching faux-unexpected conclusions that resonate nicely with what people like to believe.
