This is my second time reading this book; the first time was maybe 5 years after the book publication date, and it blew my mind at the time. Now the book is 20 years old, and it shows. The comments on formatting and layout, for instance, are useless in the time of linters and formatters.

I think my review is damaged by the fact that I'm not too experienced to read the book, and there's nothing new to learn. It's not that I remember everything from my first read, it's just that the advice - use good names, test your software scientifically instead of randomly - are now commonplace, at least for a person like me that constantly consumes material about programming.

This can be a good overview, though, of writing good code - and for instilling the mindset that although the end product (the software you are building) is the ultimate value, it can only be built consistently if you pay attention to the process of programming.

A lot of useful basic information. Glad I had a chance to handle it. Anyway, too many 'stories' for a tech book.

a must to have and must to read for anyone involved in the software development process

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.

TLDR: I read this book as a very novice programmer with a background in the natural sciences (not computer science). It was very useful for me as a first introduction to Object-Oriented Programming. I now feel more prepared to dive into more specialised books about programming.

I will give you a brief overview of my background, so you understand my context going into this book. I have a master's degree in physics and mathematics and a Ph.d. in experimental physics. During my time at the university, I used MatLab for data analysis and plotting. I was never taught MatLab, but was expected to lean as needed. After finishing the ph.d. I got a job in a small start-up as a machine learning engineer. I had prepared for such a position by taking courses on Coursera and playing around with Python and its modules for Data Science and Machine Learning. Still only focusing on analysis.

So most of my code tended to live in single files and I had never felt the need to create a class.

I started reading this book because I wanted to have a better understanding of the systems that will be using my analyses.

This book is very long. However, I think the author has succeeded in writing a very readable book, which makes it possible to read it from cover to cover in a relatively short time span (I read it in a month). I generally enjoy reading, so this was not a problem for me, but if you are in a hurry, this might not be the book for you.

The book is well structured, so if you are more familiar with the general concepts than I was, you can probably skip quite a lot. If you are not familiar with the concepts, the author has you back and gives several examples and explain the concepts at length. Each chapter contains check-lists at the end, which served as useful summaries, but should also work quite well as a tool for skimming the different chapters.

The code snippets in this book are in C++, Java, and Visual Basic. I knew none of these languages, but this was not a problem because it his points apply to writing object-oriented code in general.

This book focuses on the problems that arise when you work on a software projects with tens or hundreds of programmers. I work on a small team (less than 5 people), so I don't experience most of these problems on a day to day basis, but it was interesting to read about none the less.

After having read this book I feel better prepared to dive into other books about good programming style. I have ordered Clean Code by Robert C. Martin and The Practical Programmer by Andy Hunt and Dave Thomas. It will be interesting to see how these books compare to Code Complete.

Great tips so far, helps provide a solid framework within which to think about your code and architecture

Good in its day

Code Complete is a good collection of advice and insight into the practice of developing software, but even the second edition shows its age and much of the advice seems a little antiquated now. In particular the focus on adhering to a waterfall-like process in early chapters seems thoroughly inappropriate in the modern world - even with the 2nd edition's nods to the new-fangled agile methodologies the kids are using and the suggestion that the appropriate level of detail for the requirements and design phases depend on the type and size of the project (which is fair).

Some of the detailed nuts and bolts advice on construction is sound but in this day and age it seems odd that it needs saying as nobody would consider doing otherwise (would they?). For instance multiple injunctions to consider maybe possibly using source control are hopefully no longer doing useful work on the reader.

The notion that Visual Basic is a credible choice of programming language also seems peculiar now, but I can't remember a time when that wasn't true

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.

It's not bad book. It's good book, a lot of effort was spent to write it. But it's so... old school. Too bloated. Every idea is discussed according to some statistics and based on some computer science article. I don't like this "complete" approach very much. I prefer strong focus on topic and clear opinons based on real experience. If you like reading a dictionary, add another two stars.

An excellent resource for software engineers. This book puts into words I would imagine seasoned programmers intuit over years and years of experience. I wish I actually sat down and read this in one-go, rather than slowly reading over the course of 2 years. I especially enjoyed the section that articulated the impact of a single bug over the course of the project. McConnell shows to you the dollar cost of a bug to the company and how that could compound if not addressed properly with systematic unit testing, code reviews, or integration tests. Thanks to this text, I believe I am a better code reviewer and am able to make informed software decision that I know will help me in the future.

The one caveat here is that the book is written a very long time ago, and the studies he uses to back up his claims are very old (as old as 1970s). The programming world has changed a lot since then and hence, the book is less relevant to those involved in developing modern web apps rather than those in classic software companies with a traditional release cycles. An illuminating read nonetheless.

This is the must read book for every programmer who want to start their very first career. Steve talks about how to write clean and readable code that will distinguish the good and bad programmer.

After working as a professional software engineer for 15 years and coding for 22 years I loved this book. I think that Jeff Atwood called it "The Joy of Cooking" for programmers, I never read that, but I guess he is right. Coding, creating code can be a joy, and this book made me realise that again. I loved that even if I did not agree with something in the book, Mr. McConnell would respect that.

Be warned though, something are very outdated and if you would ask a junior about those kind of things, they would not understand why that could have ever been a problem. Source control? Of course, is there a different way? But somethings will never be solved, like giving a variable a adequate name. At least this book gives some tips about this aspect, but it also learns you to be a humble programmer and be open in your shortcomings.

Also if you are an experienced programmer some stuff will be too obvious: just use your readers rights and skip those parts, be do know that there are golden nuggets in those paragraphs.