Code Complete 2... A Review

One-liner: Read it. 3.5 stars

I came into this with super high expectations. Things I'd heard people say: "I make everyone on my team read this." or "Every developer should start with this book". So, I thought, "sweet, a great 'back to basics' book... I can't wait!". I read through this book with a host of colleagues all with quite different experience levels and in different areas of expertise.

It was the best of times. It was the worst of times.

Well... maybe not the worst, but not my favorite ;)

Needless to say the book didn't live up to my expectations... however, the book is still a gem. I think the book is best approached (especially for more experienced devs) with a 'back to basics' mindset or an 'I'm starting fresh here... forgetting everything I know' type of attitude. It can be incredibly easy to completely discount large portions of this book without that type of attitude.

The Best

The absolute best part of the experience was having a group of peers to bounce ideas off of. Many pieces of information in the book invoked questions in my head that needed some consideration. Having a discussion forum like a book club was an excellent way to solidify my understanding of things I thought I already knew, and to break down some misunderstandings with opinions and feedback from the group.

Some specifics...

Simplicity is a common theme throughout the entire book... and I think rightly so. Software has such a knack at becoming complex, and without always striving for simplicity, the complexity will overwhelm anyone.

In particular, I appreciated the performance chapters where he talks about how to improve performance (loaded term...) in your system. The gist of the story is that you have to measure. If you don't measure how do you know you got better? Developers almost always assume the bottleneck is in the wrong place (odd isn't it?). And this gem of a quote "if it isn't worth profiling [/measuring:] it isn't worth improving". PLEASE keep that in mind the next time you're performance hacking! Oh yeah... just in case that bit didn't do it for you... MEASURE BEFORE AND AFTER you enhance performance! It's so simple, really.

He talks about standardizing in many areas of the book. Standardizing on naming, style, layout, design concepts, standards themselves, etc., etc. Standardizing is great, and keeps things simple... until someone puts out an eye. It's easy after reading this thing to want to go CRAZY on standards. "Spaces here, not there; Braces here, not there; Capital letter here, and there, and there, but not over there!". "A good style applies to most cases" (emphasis mine). I think this holds true for most standards. When a standard is defined in absolutes, I think, it becomes less about simplicity and more about rigidity (BTW, simplicity != rigidity).

Steve gives some amazing stats that are often quite surprising and inspiring, and are usually well backed (although, I'm guessing he could've found stats to back any statement he wanted to make). The wealth of information and completeness of the book in the areas that it touches are impeccable and spot on.

The Worst

I don't want to hate on the book too much (or at all really), but I do have some nits to pick.

This thing is freakin' huge! I had to use a hand-truck to haul this thing around! I needed a social contract to get myself through this book. I had been trying to read it for years. A group of us set out to read this together, meeting once a week as a book club, so that gave me the social commitment I needed to get through this monster.

I felt a general 'anti-Agile' undertone, though he never really stated it explicitly. I'm no Agile Zealot, but I do like to be lean and nimble.

Many of the things I felt like I already knew, or already had opinions on. Some of his suggestions (PPP in particular) just seemed weird, and not generally (or even specifically) applicable to how I work. Maybe I was just looking to be shocked and awed by the experience and wasn't. I think had I approached some of the book with a more open mindset I might've been able to glean more out of those 'basics'.

Terribly bloated. Long-winded and trivial. I do not get the high score for this book; in a related area, but much more crisp is Programming Pearls (it even engages your brain, imagine that).

Much of this book was created before multi-core processors became mainstream, and before the Internet, before the world wide web became the preferred way to publish applications and before the prevalence of distributed systems.

This book is the perfect book for 1993 (the year edition the first edition was published), but right now some of these topics are of lower importance.

If you work with structured, imperative, object-oriented programming languages, with no functional programming features, and without concurrency primitives (such as threads or futures/promises), this book might be still relevant.

A lot in this book can be achieved through the use of static analysis and adopting a proven coding standard. Today, you will make your software more reliable by reducing shared mutable state and by constructing for verification.

Despite it is old it is still applicable, excellent book that gives you recommendations what to do in given situations and become one of the best programmers.

Една от най-добрите книги за софтуерно инженерство, които съм чел (и според мен е задължителна за всеки, който смята да се занимава сериозно с това). Пълна с много полезни принципи за това как да пишеш по-качествен код и да разработваш по-качествен софтуер като цяло.

This is were I learned to make well documented code.
I prefer to write code that is modular and easy to follow... ...easy for the next guy if necessary.

Often called "'The Joy of Cooking' for coding", Code Complete is an excellent book that doesn't say HOW TO code, but is ABOUT coding. Considerations with project size and complexity, coding style, comments, testing strategies, even developer communication are all touched upon.

Many things won't click with people who don't have at least a year or two of development under their belt, but for any kind of programmer, this book contains many gems that are worth referencing for years to come.

This was my second attempt to read this book. The first time was 5 years ago, just after finishing my computer science degree. At that time, I had difficulty understanding importance of the ideas presented in the book. Eventually I lost my interest and stopped reading it.

After spending some time in the industry and facing with harsh realities of software development, I decided to give it a try again. This time I gained much more insight than my first reading. Because now I had a chance to reflect on my past experiences while reading.

Even though it has been more than a decade since the book was published, I think most of the ideas presented in it still apply. The book is huge as it includes all of the stages in software development process. So it is so hard to read it from cover to cover. I suggest taking notes from each chapter while reading the book. So that you can revisit your notes from time to time in order not to forget most of the ideas.

Can be useful for Junior developers in some chapters, but book requires a newer edition to represent actual state of development especially for Java related snippets. More experienced developers can deep dive more in software development processes on a high level. Book also contains many good references for future readings in a software engineer career growth.

All concept can be just added into few sentences, like, before you start programming, think (and predict) very well what functions you'll need, as not Mather how well you though, damn thing anyway will grow into something too complex. It is tempting to add features, but that's a suicide if those not thought off before the project. Complexities have tendency to fail.

Considering this book is 20 years old, it's still full of good advice that is applicable today.

I'd give a 1-star review to a book that was wrong, or that purported to be scientific and yet was absent of references. This book gets 2-stars because although there were a tiny handful of useful tips, the vast majority of the text was a stream of minutiae, such as an entire chapter on variable naming (Should you capitalize the first letter of method names? What about prefixing constants with "c_" vs making the whole name upper case?).

I've been reading a few articles lately about "tricks" for reading more, and one recurring theme that stuck out to me was the recommendation to put a book down that "isn't really doing it for you" because it's stopping you from reading the books you may enjoy more. I think this book meets that criterion.