The most annoying part about passing by the Computer section of bookstores is when you realize that all of the books in the bookshelves will be obsolete in 5-10 years. This is why serious software engineers prioritize books on processes and methodologies over books on tools.
One guy (Jurgen Appelo) compiled a list of the best of SE books based on “1) number of Amazon reviews, 2) average Amazon rating, 3) number of Google hits and 4) Jolt awards”. Think SE version of Personal MBA.
Below the cut is the top ten. I’ve included my own mini-reviews for the books that I’ve already read.
1 Steve McConnell
Code Complete: A Practical Handbook of Software Construction
This list explains why I am a Steve McConnell fanboy. His books are generally considered the best books in the software engineering field; not only are they informative, they’re also much more accessible and pragmatic compared to other books.
Code Complete 2 is his book on Construction (“programming” in layman’s term). This thick book contains advice and best practices on almost everything related to construction, from requirements and design, down to variable naming standards. Pragmatism is evident in the text, the book even provides the reader the correct way of using GOTO, a statement widely considered harmful.
2 Elisabeth Freeman, etc.
Head First Design Patterns
On a nutshell, Design Patterns are like best practices. They are, under certain circumstances, the best solutions for common problems and scenarios in Object Oriented Programming. What makes DPs better than BPs is that there’s a definitive/seminal book on the subject (see #4) wherein the authors decided to give the DPs names. This allowed software developers to have a common vocabulary: instead of describing the pattern, they can simply say their name e.g. “We’re going to use the Strategy Pattern to…” or “I think we should convert this to an Abstract Factory..”
The Gang of Four book Design Patterns (#4) is indeed an informative book, but it’s also written like an average computer textbook (read: boring). It also uses Smalltalk for its examples, a language rarely (relatively speaking) used in the industry.
Head First Design Patterns deals with these problems. It’s a Head First book, meaning it’s a “for Dummies” book on crack. Not only that, the book’s examples are in Java, a much more popular language.
3 Steve McConnell
If Code Complete is the book for coders, Rapid Development is the book for managers. The “rapid development” in the title is not about championing yet another buzzword methodology, it’s all about “how not to screw up”. In other words, the best way to finish a software project “rapidly” is by not screwing up (too much).
The only drawback to reading Rapid Development is that it’s examples hit’s home. A lot. Everyone I know who had read that book could mention cringe-worthy real-life instances that were addressed in the book.
Oh and yeah, it was also written before the Agile Manifesto was drafted. So if you could read this Mr. McConnell, we need Rapid Development 2 NAO!!!1!!1
4 Erich Gamma et al
Design Patterns: Elements of Reusable Object-Oriented Software
5 Bruce Schneier
Applied Cryptography: Protocols, Algorithms, and Source Code (2nd Edition)
6 Robert C. Martin
Agile Software Development: Principles, Patterns and Practices
7 Joel Spolsky
Joel on Software
I haven’t read the three books above yet. Which is kinda sad because Bob Martin seems like a nice guy.
Seriously though, Applied Cryptography isn’t that applicable nowadays. Even Bruce Schneier himself said that social engineering (e.g. people posing as someone of authority getting your password) is more of a threat than crackers. As for Joel on Software, you could just go to his site and read his articles.
8 Tom DeMarco, Timothy Lister
Peopleware: Productive Projects and Teams (2nd Edition)
Ahh.. Peopleware, the one book that focuses on the importance of people in the software engineering workplace. Less informative, but about as cringe inducing as Rapid Development.
9 Frederick P. Brooks
The Mythical Man-Month, Anniversary Edition (2nd Edition)
If there’s one book in the list that proves that some lessons are timeless in the SE field, it’s this book. The first edition of this book was written in 1975, and the lesson derived from the title (“adding manpower to a late software project makes it later” or in more digestible terms, “nine pregnant women can’t give birth to one baby in a month”) is still unaddressed in most software development projects around the world.
Note that the book is a collection of essays — it does not stop with Brook’s Law. Other timeless lessons include The Second System Effect, which explains why Version 2.0 usually sucks, and No Silver Bullet, which explains why there won’t be a single product that could provide productivity gains to an order of magnitude.
10 Martin Fowler
Refactoring: Improving the Design of Existing Code
Refactoring is the OOP way of “cleaning your code”. It’s another fundamental process in SE so I’ll explain more about it later in another blog post.
Anyway, this book popularized that term. It provides a list of (potentially) problematic programming structures and then provides a list of better ways to structure your code. It’s technical, but it’s a lot more readable than #4 and #17 below.
I skipped 3 books so I’ll make up for it by giving a brief review to the next 3 books that I’ve actually read.
14 Steve McConnell
Software Estimation: Demystifying the Black Art
Yet another Steve McConnell book. This time it’s for everyone who has to deal with estimates i.e. everyone. His advice is practical, but the main challenge (as is also mentioned in the book) is to convince higher ups that traditional views on estimation doesn’t work and they themselves should change their perceptions on it.
UP Diliman Computer Science students respect/idolize Prof Quiwa. Prof Quiwa idolizes Donald Knuth. Therefore, we all idolize Knuth by proxy.
Seriously, though, anyone who wants to review their data structures and algorithms should consider reading these (highly technical) books before moving on to other books.
17 Martin Fowler
Patterns of Enterprise Application Architecture
A DP book written by the Refactoring guy. “Why should I read this highly technical book?” you may ask.
It describes the building blocks of every web application on the Internet.
Read it, and be enlightened.