One of the most worthless and dull books I've ever read. Some right ideas and proper approaches are described there indeed but, first, they are obvious and, second, the amount of text one should absorb is 5-10 times greater that needed, in my opinion.

Further, a lot of people recommend this book to beginners which is not worthless but, I would dare to say, dangerous. Many ideas are very controversial, and to yet unformed minds they may be really wrecking.

The idea which I believe can replace the whole book is here: write the code for people to understand. Nothing is beyond that simple truth.

Эта книга должна быть одной из первых у тех кто начинает программировать. Она сразу правильно формирует отношение к разработке и указывает как надо делать и как не стоит.
Я бы выделил эту книгу в TOP10 книг которые стоит прочитать чтобы вырасти до Lead Developer.

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'.

_The_ book about the craft of programming. Not only should every programmer read it, they should reread it every several years. In the detailed view this book is an examination of all aspects of software construction, down as far as the minutia of loops and conditionals. But in the broad view there is a golden thread running through this book that ingrains in your mind: "Code doesn't just happen. You _choose_ how you write code. Strive to choose wisely."

Очень крутая книга, которая поможет заложить основы качественного кода. Поднимаются полезные темы про конструирование, проектирование. Читать лучше одновременно с изучением языка программирования, чтобы раньше выработать привычку писать правильно. Много времени посвящается принципам как писать хороший и понятный код, как правильно выбирать имена переменных, методов и классов, чтобы код был самодокументирующимся. Однозначно "must read" для тех, кто хочет посвятить свою жизнь написанию кода. P.S. Эта книга никак и никогда не сможет устареть. Эта книга о том, как писать хороший код. Практически везде автор воздерживается от упоминания конкретных технологий. Да и как правила написания понятного кода, которым преимущественно и посвящена эта книга, могут устареть?

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

Required reading for those that approach software developer as a craftsman would, as an artisan would.

So it’s a #1 must read programming book according to this poll on StackOverflow. That raises quite some expectations, and if you ask me, the book doesn’t really meet them.

I mean, it doesn’t even feel like a proper programming book - it’s written in some “Easy way to quit smoking for dummies” style. Every idea is explained verbosely, then illustrated with some numeric stats, then with a 3D chart, then with some real-life anecdote, then with a reference to a 1973 paper, and finally reiterated in a checklist in the end of the chapter.

But still, this book makes a lot of good points, it’s easy to read, there’s not much prerequisites (“If you’re rusty on polynomials, they’re the the things that look like Ax² + Bx + C”) – maybe it makes sense to read it in high school.

A must-read for any programmer. Although I don't agree with everything in the book and a few parts feel out of date, it provides an excellent framework for how to think about programming and software engineering. It can help programmers of all experience levels to focus on the right things: that code is harder to read than to write, that managing complexity is the main goal of programming, and so on.

The book is filled with nuggets of wisdom. Some of my favorite quotes, some from McConnell, some from other writers that he includes in the book:

Managing complexity is the most important technical topic in software development. In my view, it's so important that Software's Primary Technical Imperative has to be managing complexity.

A "wicked" problem is one that can be clearly defined only by solving it.

It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it.

Eighty percent of the errors are found in 20 percent of a project's classes or routines.

Don't document bad code - rewrite it.

Jackson's Rules of Optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.

No programmer has ever been able to predict or analyze where performance bottlenecks are without data. No matter where you think it's going, you will be surprised to discover that it is going somewhere else.

The Fundamental Theorem of Formatting says that good visual layout shows the logical structure of a program. Making the code look pretty is worth something, but it's worth less than showing the code's structure.

Build one to throw away; you will, anyhow.

One downside to the book is that it seems to largely focus on OO languages (C++, Java) and even older imperative ones (C, Ada, etc). There is virtually no consideration given to functional programming. This is a shame, as immutable variables, pure functions, and lack of side effects inherently solve or mitigate MANY of the code complexity and readability problems he discusses in the book. I chuckled at a line in the book where he says "Recursion isn't useful often...", which is true in the languages he used, which don't support tail call optimization.

The book also pre-dates the open source explosion, github, cheap/free access to amazing tools and cloud services, and the growth of continuous integration/deployment. These have had some pretty profound impact on software development that are not taken into account in the book.

All the while reading this book, I struggled with how to rate it here. In many ways, this is an extraordinary piece of work; it's extremely comprehensive, and reveals a remarkable level of insight.

This second edition is from 2004, and although obviously some of its content may seem a little dated, most of it still holds up well in 2015. Given that context, I find it difficult to find fault with most of the book. Much of the advice given is good advice, and as a programmer, you should adopt and internalise most of it.

On these grounds, the book deserves 4 or 5 stars, so why do I rate it as I do?

There are two reasons for this.

The first is that, having programmed for some 15-20 years already, I learned little. Although I think this tome could be indispensable for a so-called junior programmer, I only gained little from it.

The second reason is probably an effect of the first, but I was bored to tears most of the way through. Still, I kept reading, a chapter per month or so, since there was an occasional gem here and there.

The rating I've given therefore reflects my experience reading the book, more than the quality of it, which is indisputable.

If you're a seasoned programmer, you may consider skipping it. If you have only a few years of professional experience, you should consider reading it.

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 a clear reference for programming. As a beginner, I found chapter 33 is especially inspiring.
In this chapter, the author brought up 5 characteristics that matter the most:
1. Humility: People who are best at programming are those who realize how small their brains are. For compensating, good programmers reduce the load on their brains by keeping routines short.
2. Curiosity: Always spare a few minutes to be curious about how to do jobs better.
1) Build awareness of the development process: Learn from the job or turning into a dinosaur.
2) Experiment: Write a short program to exercise the feature you're not familiar with and see how it works.
3) Read about problem solving
4) Analyze and plan before you act
5) Learn about successful projects
6) Read documentation: skim the documentation every couple of months
7) Read other books and periodicals
8) Affiliate with other professionals
9) Make a commitment to professional development
3. Intellectual Honesty: Refusing to pretend you're an expert when you're not. And if you make a mistake, admit it quickly and emphatically.
4. Creativity and Discipline: Analyze requirements and design before you begin coding.
5. Enlightened laziness: Deferring an unpleasant task -> Writing a tool to do the unpleasant task
Aside from the characteristics mentioned above, having good habits before you cultivate bad ones without consciously thinking about it. What are good habits? Here are 2 examples:
1. Writing a class in pseudocode before coding it.
2. Carefully reading the code before compiling it.