I think I should have read this book straight out of my engineering degree. There is so much intricacies in the software development that people I know struggle through their life to learn. A must read for any coder who wants to stay so for the times to come(no matter what tech-tides are).
Its a very objectively written book; ideas explained will make more sense if you have already faced a software version release or have already been part of every step of the product life cycle(complex product the better).
I would suggest this book for every new grad as this fills the gap between what industry needs and what education system produces and the gap between high standard coders and the low standards.
Also I see that in India where people are oblivious to learn new tricks of this new trade(until they are forced to), there would be need to go through the book, we cannot continue to write shitty code and still be paid.
Final words; the words and ideas put in this book are perennial in nature, so it does make sense today(15/11/2017) and so would it in the times to come. Don't pick it up for experimentation. This handbook is only for people who want to know/be part of software development with full devotion.

Purchased this book as a textbook for a Software Engineering class at school. The teacher said he enjoyed it quite a bit and that we weren't going to reference it as much as he'd like (considering the other texts for the class). His comment piqued my interest. Upon finishing the first reading assignment I continued along to the next chapter. Like it so much I began the next and then halted, remembering the other reading I first needed to complete.

So, I finished the other book (Mythical Man Month) and took Code Complete with me on trip. I was enthralled with the style of writing and ideas presented as much as Mythical Man Month. In fact, on the way home from the trip I read almost 400 pages. McConnell really has a knack for presenting his material in a thought provoking and entertaining manner. I kept underlining and scribbling notes. I fully intend re-reading every 18 months or so to check up on myself and evaluate the suggested best-practices.

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

Lots of checklists that theoretically sound good for large teams and projects but the overhead may be too high for smaller projects.

When starting my first job out of college, part of the training was to read selected chapters from this book. The way that Steve McConnell presents the topics in story form made the reading effortless and even entertaining. Although I had initially suspected that the book reading was some useless filler task while they found something for me to do, looking back I probably learned more about programming on a team than I did during the first two years of college programming courses.

The book tackles more than just the technical look at coding, but delves into the deeper thought processes involved in writing software. I would strongly recommend this book to anyone interested in working with software of any kind. In fact, in the time since starting my job I have helped train two new members to my software team, and reading Code Complete was the first things I had them do.

It's a great book for fresher developers, as it contains a lot of practices and hard facts to back them up. I''m already aware of quite of bit that the book advocates so I wouldn't get as much out of it as a new developer. But having said that, I did get to learn bits and pieces here and there of stuff I hadn't thought about, so it's good. I guess the downside about this book is that it can be pretty long-winded in trying to explain why a certain practice is a good practice.

Great for an overview of software development.

An imprescindible book that depending on your actual expertise, you can just skip some chapters.

Known as one of the most loved books of StackOverflow's userbase, my expectations were maybe too high. The worth knowledge of this books decreases linearly with the reader's software-development expertise.

The main point of the book is to understand the importance of "managing complexity" by using the correct code standards, debuging/testing principes, layout design and team management. Optimization will help you do you work better, faster and with less problems.

There are many truths in this book, some of them more bitter than others. Steve McConnell shows true respect of the developer path, explaining the peculiarities of this art where humans create castles in the air, without any more materials than our grey matter. To a wider range than other engineering disciplines, the own developer is whom defines his own limitations and boundaries.

In one hand, if you're a student finishing college, or a junior in his/her first steps in the world of software construction, embrace the tips in this book, it will be an important shortcut in your path to software-development maturity. You will save years!!

In the other hand, if you have some experience developing sofware, you'll find that you know most of what is said in the first half of the book. Don't make the extra effort to re-read everything, you can skip some parts of this chapters.
But as you start the second part of the book, you will found a great recopilation of high level topics (from debuging, to testing, team management, etc) and heuristics to deal with complex decisions, all of them supported by papers and scientifc studies.

An impressive bibliography of each of this topics will help you defend your future decisions as a software-developer (if you follow the tips encourged by Code Complete). When people ask you why you decided one thing or another, you will have resources to point them to.

In summary, read it and skip the parts that you already know. Steve McConnell really makes an effort trying to dismitify a lot of software "common knowledge" with the help of this bibliography.

Most of the reviews here seem to praise this book. Engineers I work with, themselves skeptical of the agile movement, found the book an outdated artifact of the long-deprecated waterfall model of software development. I found the truth somewhere in between: the book is full of important nuggets of wisdom, many of which are under-appreciated in the broader software engineering culture, but these bits are mixed with tons of more dubious advice that's often as bureaucratic as the book itself. That said, this book is quite thoughtful, and nearly all of the topics are important issues to consider, even if I found many of the specific suggestions less useful.

Random examples of ideas that resonated strongly with me:

* Ch5: Design is "wicked", and you're best off iterating with both top-down and bottom-up approaches and using loose heuristics rather than rigid algorithms.
* Ch9: "One of the biggest differences between hobbyists and professional programmers is the difference that grows out of moving from superstition into understanding." Amen. Similarly, in the debugging chapter, I strongly agreed with the emphasis on truly understanding the root cause of an issue and all of the observed behavior before fixing the problem.
* Ch10: All of the comments on scoping and the reasons to minimize scopes.
* Ch23: Totally agree with the general attitude towards debugging, and the notion that programmers learn a lot from debugging. I've probably learned 2/3 of what I know from my experiences debugging, and those experiences inform every line of code that I write. That said, the notion that one should seriously consider giving up on a bug after less than an hour of debugging is ridiculous.
* Ch24: Parts of this chapter on refactoring and "design-ahead code" are remarkably concise and forceful. I can't tell you how many times I've written code for a feature I was sure we were going to want, but didn't quite flesh out because we weren't sure exactly how it should work, and that code turned out to be poorly exercised, buggy, and ultimately ripped out -- not because of the poor quality, but because we simply didn't need the feature, or the feature needed to work very differently than we initially anticipated. Of course, like all things, there's a balance, and one has to consider each case individually.
* Ch32: Bad idea to refer to bugids and other historical artifacts in code. The source should represent the current state of the system, and the bug tracker and source control document what changes were made when, by whom, and why.

By contrast, there's lots I took issue with:

* Ch5: Many of the examples, particularly in the design section and with respect to OOP, are highly simplistic.
* Ch6: Encapsulation as typically lauded in OOP texts is often a sham, in my experience. Realistic problems rarely lend themselves to simple, clean abstractions. Even traditionally successful abstractions, like Unix file descriptors and POSIX open/read/write/close, reveal a lot about the underlying implementation, and one cannot use them successfully in complex programs without understanding details about the implementation.
* Ch7: The Bjarne Stroustrup quote about macros (that each macro demonstrate a flaw in the programming language) is exactly the kind of dogmatic lunacy that gave us C++[11].
* Ch8: The discussion of error handling misses what I consider the most important question in determining what a component should do in handling an error, which is: can the current layer be *sure* it knows what the caller wants to do? If not, it should either propagate the error to the caller so that it can decide what to do with it, or else provide options so that the caller can indicate ahead of time what it wants to do (e.g., ignore, retry N times, or fail). If there's more than one consumer, err on the side of providing rich information to the caller so it can decide what it wants to do. There's nothing more infuriating than library functions that retry operatons after errors that you know aren't transient or which try to deal with a fatal error by papering over it. It's much worse than having to retry something the library should have known should be retried.
* Ch9: The pseudocode-writing technique suggests thinking both implementation-agnostic and low-level enough that code generation is automatic. These two are always competing, and (in my experience) usually exclusive.
* Ch13: There's an over-emphasis on a superficial notion of "safety", and the suggestion that things like void pointers in C lead to serious runtime bugs. Despite the arguments for "proper" generics in higher-level languages, in my experience, improper use of void*'s in data structures is not even remotely an important category of runtime bugs. One of the "C" examples in this chapter isn't even valid C.
* Ch16 is full of small errors and some braindead code (e.g., "if (...) { assert(false); }").

The book is divided into several sections:

* The first few chapters on metaphors and the notion of construction are thoughtful and unusually self-aware for this kind of "advice" book.
* The next several chapters on requirements and design are a microcosm of much of the rest of the book, containing a smattering of useful ideas in a sea of more dubious, often bureaucratic advice.
* The middle chapters on actual writing and structuring of code are probably the best.
* Some of the later chapters on debugging, refactoring, style, and so on, are pretty thoughtful. Some of the others (like collaborative construction and tools) feel like useless catalogs of techniques and software packages: they're not immediately useful to the reader, nor are they a particularly good reference, but they seem to be there to flesh out an exhaustive description of software construction.

One nice thing about the book is that the text itself is organized with useful headings and bolded main ideas, and each major section ends with main idea bullet points and a complete checklist, making it relatively easy to skim. This could help an experienced engineer pick out good parts that are worth reading more about. Unfortunately, the kinds of things that are most useful to learn are typically the things you wouldn't necessarily realize are important from a bullet point.

As I mentioned, the book is very thoughtful, and the issues raised are all important and relevant for practicing engineers. I found about 30% of the advice strongly resonated with me, at least 50% was highly suspect, and the rest was pretty thought-provoking. For less experienced engineers who are good at picking things up from books like this, it might be a useful text. For experienced engineers, or the majority of us who learn subtle lessons much better by making the mistakes (or at least seeing real-life, personally meaningful examples), you may be better off learning by doing.

I was given a copy of Code Complete when I was developing the kernel for the technology I patented. I didn't really know how to code, I did know some mathematics, formal (symbolic) logic and had a good helping of philosophy to draw on. I never met Steve McConnell (that I know of) and did find his philosophy of coding almost parallel to mind, hence his book was an enjoyable read at the time.

Very good! I should have read it 5 years ago!

This is one of those books that every programmer must read.

If there's one problem with this book, it's that it is too long, at 900+ pages. But, I wouldn't hold that against it. This book has tons of good information. I should have read this years ago. A lot of what I learnt over the years could have been done so earlier. Also, there were a few points that I didn't completely agree with, but I guess that's ok. Like it is said here, creating software is a craft.

The top 3 biggest takeaways from this book are
* Design is a heuristic process
* Software's primary technical imperative is managing complexity
* Code for humans first, and computers second