I'll post some quotes from 34th chapter that describes the contents of this fundamental book:

"This book is mostly about the details of software construction: high-quality classes, variable names, loops, source-code layout, system integration, and so on. This book has de-emphasized abstract topics in order to emphasize subjects that are more concrete."

"A second major thread in this book is the idea that the process you use to develop software matters a surprising amount. On a small project, the talents of the individual programmer are the biggest influence on the quality of the software. Part of what makes an individual programmer successful is his or her choice of processes. On projects with more than one programmer, organizational characteristics make a bigger difference than the skills of the individuals involved do. Even if you have a great team, its collective ability isn’t simply the sum of the team members’ individual abilities."

"Another theme that runs throughout this book is an emphasis on code readability."

Just finished this huge tome of a book, I think it almost took me about 3 months to finish this book, my overall perspective regarding this book is that it provides some refresher on most practices of software engineering.

I have about 9 years experience working in the software field, and some of the examples in this book are clearly outdated as regards to the software landscape of 2019, we have some very good methodologies and technologies available to us.

I am mostly an MS developer, and Visual Studio has gone from strengths to strength as regards to what an IDE can do, with MS focusing on open source, there are very few things which visual Studio does not support, the book clearly lacks this focus, and has become outdated in terms of when it emphasizes on version control systems and debugging.

For me the first 40% of book was really a crawl because all the basics of software construction are explained here, and for that we have quite good books and resources available with us that how code is to be written by applying principles of SOILD or DRY or how should we code to patterns.

After 40% of the book is over, it actually became interesting to me, because then it focuses on software craftsmanship, how a software can be developed, why unit tests are necessary, and why having unit testing does not mean you don't need testers in your projects, and so on and so forth.

I give this book 3/5 stars.

После повторного прочтения данной книги окончательно убеждаюсь в том, что данная книга должны быть прочитана, как минимум раз, каждым развивающимся разработчиком, менеджером связанным с разработкой, и тем, кто так или иначе связан с областью разработки.

Мое мнение может быть предвзятым, так как на момент написания - это единственная книга по разработке, которую я прочитал, но могу сказать, что автору удалось пролить свет на разработку как таковую, и мне, как начинающему разработчику она очень помогла, не смотря на то, что некоторые главы пока просто не понятны. Также, хотелось бы отметить, что в книге есть главы, которые традиционно являются поводом для многих "религиозных" войн, но автору удалось преподнести предмет спора, в нейтральной манере, благодаря чему, например, выработать хороший стиль кодирования и форматирования, после прочтения книги, не такая уж и большая проблема.

В заключении хочу сказать, что эту книгу я буду стараться перечиывать как можно чаще, по мере получения опыта, так как с каждым чтением, эффект после прочтения все больше и больше.

Not terrible, but not great, this book has a much higher stature among Microsofties than is strictly deserved, and little visibility beyond that group. Says nothing in 960 pages that The Practice of Programming doesn't manage to convey more clearly and succinctly in 267. Ok as a supplement to the latter for those looking for longer justifications for the same recommendations, or those deathly allergic to Unixisms. Pointless otherwise.

A must in a programmer's library!

That book was for me high expectation.
But in real case, for 10 years of professional development and self improvement, that book is just repeating of basic paradigms. But still I found something new. May be not new, but obvious, what most of senior developers ignores by "authority" of experience.



I recommend that book for Mid-Senior developers. It collects a ton of best practices and advices.
For junior devs it will be hard to handle at once. Needs to return back more that once.
At least, once you must read. Later you could return to it, to refresh knowledge about that obvious stuff, what we start to ignore with time.

For me is main idea of that book.
1. Struggle with code complexity
2. Be curious
3. Programming is intellectual work - you must remember it. Work with you head!

I'm keeping this book on my bookshelf. It's a good read and great for developers. I realised as I was reading that I had already learned a lot of the concepts and principles throughout my time in school for a computer science degree and also my internships with Microsoft. But it's important to refresh and consume the topics in a way that helps me put into words what "intuitions" I've built. There were also a lot of bad habits that I have as a programmer that reading this book has helped me to notice and I think in a year or a few I'll read it again to see if I've changed those bad habits.

Code Complete is a highly regarded book in the software engineering industry and I approached it with pretty high expectations - however, the actual reading experience has turned into something of a nightmare for me. It took me almost a year to finish (several times seriously considering abandoning the effort), and I have to say this is probably the driest and the most boring book I've ever read.

Don't get me wrong, it's hard to find fault with the content itself - all of it is excellent advice, focusing mostly on the construction phase of software development. Unfortunately, I cannot imagine a software engineering with any amount of real-world experience who'd learn much new information reading it. Most of the chapters feel like common sense mixed with fluff and it's hard to avoid thinking this shouldn't have been a 900+ pages book.

I'd probably recommend the book to university students or to self-taught developers just starting their careers, but others would likely be wasting their time.

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.

I'm novice in development. Were trying to find some book, which can explain constructing (as author called it) essentials. I've met this book as high rated tutorial for all categories of software engineers.

I gave up the book after I've read about 100 pages. Not because it's hard to understand for me as for beginner, but because it's organized messy enough. Although we have some structure, most part of information is just plain text. Sometimes author tries to show classes interaction or wrong design examples, for instance, without any schemes and diagrams at all, it's just paragraphs of text. But we can see some illustrations for easy (as for me) topics as "Problem-Definition Prerequisite".

This book quotes Albert Einstein on margins: "If you can’t explain something to a six-year-old, you really don’t understand it yourself.", but I think it's not about this book. Dissappointed.

Video review here: https://youtu.be/QlY0EGWp7rw

This is a fantastic book!

I read the first edition. If you can get your hands on the second edition, I'd recommend that but even the first edition is worth reading.

Even though it's 30 years old, I'd say about 80% of the first edition is still relevant. Stuff like the nitty gritty of naming routines, how to comment, etc are evergreen topics. And McConnell did an extensive survey of all the literature, so a lot of the content is backed up with hard data about what works and what doesn't.

Highly recommended.