Book Review: Code Complete

I've been trying to be constantly reading a book for about the past year and a half now.  And in addition, I started a dev book group where I work, where we pick a book and read it a certain amount each week and then meet for an hour to discuss that section - whether it be making decisions on whether this is something we want to do as a department, or how we can apply the topic to our projects, etc.

The latest book we just finished was Code Complete.  I feel like I was long overdue reading this one as I've heard a few times in the past that this was one of those required reading books on programming.  Actually, on more than one occasion, I've been asking during a job interview what books I've read and liked the most and after giving my list, the interviewer has said "all great books... the only one I'd add is Code Complete".  So I was pretty excited to finally read through this one.

I've broken up my review into a section of positives, negatives and then a summary.  I find that helpful because sometimes reviews get too verbose and will be filled with double speak such as "the paragraph on *whatever* was great, except ..." .  So I'm going to try to avoid that and just talk about what I liked, what I didn't.

POSITIVE:

I can't stress enough how much good information this book is packed with.  There's a ton of information to digest about a wide range of topics - from how to organize and comment your code to team dynamics, estimation tipis and even programmer human characteristics - this book does a great job of taking a good 1000ft.view of a lot of aspects of software development and also gives a lot of "read this next" resources for topics that you might want to delve deeper into.  McConnell (the author) does a pretty good of using case studies to back up his points.  And while some of the information is a little out of date in the book (happens often in these types of books... the software industry just moves too fast), a lot of the information is plenty applicable no matter what language you develop in, type of development you do, etc.

NEGATIVE:

First off - this book is long... REALLY long.  We actually skipped a few chapters early on during the book group and it still felt like the book would never end.  That's a bit nitpicky though as the Lord Of The Rings trilogy is long as hell, but it's a great read   I think the biggest disappointment to me was that a lot of the information put forth was stuff that you learn your first few years in professional software development and it just becomes common sense.  More often than not, I found myself (and I believe some of the others in the group) saying "these are great points - but I already knew this" or "these are great points - but this is common sense".  And then, of course, the problem with a 1000ft. view that I mentioned earlier is that if you find yourself interested in one of the ideas that he presents, you would love to learn more, but it's just not there.  That's not a problem with this book in particular... but I guess my preference is with more directed learning books.  Books that take a smaller array of topics and really delve into them in greater detail.

SUMMARY:

I'm not sure I'd ever read this one again.  Like I said, it just contains too much information that I already knew.. and I don't even pretend to be a software guru by any stretch of the imagination.

However, this book is far from worthless.  I think this book should be required reading in a college course on programming, or the first book a young developer reads before ever working on their first project.  This is type of stuff that you can either learn organically by being in the industry for a while and seeing it all come to life in both good and bad ways in your projects, or you can just read this book and enter the industry with this knowledge in hand.  It'll put you on level playing ground with people who take the long path.

I also think this is one of those books that would be a checkmark in the thumbs up column if a prospective new employee had mentioned reading it.  It would be a sign that the developer was equipped with knowledge of good programming practices and ideas (of course - whether they apply them is a different story, but you'd rarely get that out of an interview anyway).

Bottom line... new developers should be forced to read this book.  Older developers probably already know most of what it contains.  But it was nice to get some of this knowledge reiterated (much like how I re-read The Pragmatic Programmer every year or two just to get rejuvenated) and also have the case studies to back up the information with statistics.  It's one thing to do something a certain way because it works for you, and even better when it turns out that it works for the entire industry :)

Print | posted @ Wednesday, May 12, 2010 9:15 AM

Comments on this entry:

No comments posted yet.

Your comment:

Title:
Name:
Email:
Website:
 
Italic Underline Blockquote Hyperlink
 
 
Please add 8 and 5 and type the answer here: