Had I read this book between 2004 and 2010, I would have definitely given this book a 5 out of 5. However, due to its age, it's no longer a must-read for every developer. That said, it still contains a treasure of timeless insights, and several individual chapters undoubtedly deserve a 5/5 rating.

This is one the best books for programmers and I think every programmer should read it. The only problem this book has is some parts of it is written specifically for senior developers and architects; so, you may want to skip them, if you're not a SENIOR developer yet, like myself.

It is a nice book but too MS-centric. Some of the things are
going to confuse you if you come from a different environment. For example, it took me a while to realize that the term "magic number" was used for hard-coded constants; in Unix, the magic number is used to identify file type as described in /etc/magic. Similarly, the author did not like the indentation standard use by Gnu. There was something he did not like about Kernighan and Ritchie either Overall, I still think it was a decent book..

It took me a while to read this book cover to cover, yet I cannot in good conscience recommend reading it in any other way. Yes, it's extensive. Yes, it goes into great detail. Yes, it examines the "appropriate" number of spaces between lines and comments. So I can see why some might say it's too heavy or technical. But the underlying theme of the book is introducing several core principals that every developer should have, as well as breaking some very prominent myths that can inhibit individual developers, or teams and companies as a whole, from reaching their full potential.

The book is also not as heavy as a first glance might reveal. The book is sprinkled with hilarious quotes that hammer home a certain lesson, and "hard data" blocks usually quote relevant research in the topic discussed. I found myself laughing more than once, and even sharing some quotes with other programmers.

I highly recommend this book.

A classic that every software developer should read. My copy is from 1993, but it is still very relevant.

Yay! Finally done.

If there is a book that does justice to its name, it is this one! It is indeed Code complete. No matter how small or insignificant the topic, it gets full attention and discussion in the book. Small details discussed with loving care. :D

This is a book that I read at least 10-12 years too late! One reason is of course that so much of the content of the book I have discovered via diverse online sources in bits and pieces but also because so much of it has now become part and parcel of being a decent programmer. In that sense, there is not many eye-opening insights in those 900 odd pages. But it is a pleasure to see many things that you have adopted over years being systematically analyzed and supported. I have a visceral disliking for comments on the code lines. But if you asked me, I would probably just chalk it up to personal choice. But this book discusses them and clearly articulates why they are a bad idea.

The thing I got out of working through those 900 pages is that it provided words to express scattered ideas and practices. Software construction is about managing complexity. A programmer's journey can begin only once he has accepted his inability to conquer the complexity and has thus started looking for ways to manage it as best as he can.

The book mostly takes examples from Java, Visual Basic and C/C++. Some of the material is also specific to those languages. If your primary language is Python, you may start feeling a bit left out as the book progresses. It would be lovely for someone to write a distilled version of this with a interpreted language at the center.

What I read
Code Complete 2

What I expect
Techniques to write code effectively. Tips and tricks on optimization, refactoring, design classes/functions...

What I got
- What I expect is in chapter 14-26. The other chapters are eye-opening, mind-expanding time. Those chapters literally change how I approach software development:
- I accepted changes in requirement are common and that we have to better control it.
- I learn (or re-learn) Pseudo-code and never have thought it could be so helpful in my coding job.
- When I encounter a problem, I no longer fix it quick but truly spend time to understand it.
- Programming into a language, not in it. Make programming language work for you, not the other ways around.
- Advices on how to be a better developer, how to be aware of religion and experiment instead, how to never stop curiosity or how to write clean code.
- The list goes on...

10 years in, yet the advices in the book are still beneficial to this day. Kudos to the author for creating such a masterful book!

Often regarded as the one book you must read if you care about programming well and I'm beginning to understand...

Only a five chapters in, I can see it's already improving not only my programming skills, but also with how to correctly deal with clients and bosses in order to minimize risk and increase productivity.

More thoughts on it will be posted later.

This book is a really good examination of low-level design of code. This older version was written before widespread adoption of Java, web development, or object oriented development. However, it's focus on well-designed routines (methods/functions) meant that the meat of the content was still highly useful and actually unencumbered by more hyped up features of more recent programming trends.

The new version, Code Complete Second Edition includes content about newer programming techniques, including object oriented development and design patterns.

Finally finished it after attempting it repeatedly over the past 8 years. Very good tips but EXTREMELY dense. If you want the TL;DR read the last 3 chapters. From there, you can then go through whichever chapters you want information on.

First, the positive:

It is a great resource! The topic of code construction is covered inside-out. As they say from where I come from, one can find milk from a chicken. The recommendations got me thinking from time to time (OK, much more than from time to time) 'I have to remember to come back to this once I start doing anything like that'.

Also, the book is organized well. It has a structure that doesn't change with the different chapters. This makes it easy to follow. The bibliography at the end of each chapter is invaluable.

Good thing, he gives measurements on optimizations, and advices on when to go into performance tweaking.

Some of the jokes and insights are pure joy!

The room for improvement :

It is overwhelmingly long! The big picture is somehow in the shadows of the details. I understand why it would be interesting to mention variable naming but it is not practical to discuss the topic in such depth. It's worth a blog post, a book on its own (given its such pet peeve of the author's) but give us the meat and let us go. We need the most important lessons in a certain area and pointers for something more if we are interested. Even though, the author makes the argument that people cannot handle too many details and we as programmers need to simplify as much as possible our code, I didn't get the feeling he follows his own advice in the book.

Less is more, right?

We are curious by default as developers but all of this resources that are somehow bibles for coders/software engineers/practitioners are outdated, long and boring (sorry, the style is not one of a great novel that reads well, it's just well structured), then, are we really advancing the field or are we retelling stories from 'once upon a time when the dinosaurs roamed the earth and Fortran was fashionable'?

I would still recommend the book to anyone even remotely connected to computer science and software engineering. We need to know all this and consider how to better.

Taking it for what it tries to do, this book is a must-read for anyone pursuing a career as a software engineer. While not perfect, McConnell builds not a reference but a mind set for responsible, sensible development, not just of software but of people who put it together.