This is probably in the top 5 of every good programmer's list of books that every programmer-to-be should read. I actually keep a copy of this in my bathroom.

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

There's a lot of good stuff in here for new developers, which is why I gave it 3 not 2 stars. I thought some of it was a little dry and I'd already read of many of the practices the book mentions, which is why it didn't score higher with me. That said, it really is a good book for new developers.

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!

A must in a programmer's library!

After 11 years as a professional Software Engineer, I now know that I should have read this book the year I graduated. It is an excellent book, and you will be a better professional after studying it and applying the tips within.

The book is not a dry read, and has a bit a humor here and there, which makes it easier to keep reading in spite of the technical nature of it. It has a lot of code so it is not purely theoretical, but it is also full of academic references, so you know that the tips given are a mix of both real experience and disciplined research.

Before this book I was not aware there was so much organized knowledge surrounding software engineering that dates from so back in time, it has really opened my mind that there is still a lot more for me to continue learning. Knowledge that is beyond latest fads and technology which will be obsolete after 3 or so years, but basic knowledge that will improve my core level professionally and will remain relevant through all the rapid change going on in the tech industry.

It is a long book, probably the longest I've read, and it is really worth it.

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

Even the most recent edition of Code Complete appeared nearly 16 years ago: very old for a programming book; but it does have its own Wikipedia article. The work has serious gaps despite its considerable size, but the underlying principles remain as true as ever.

The broad scope of this book makes it elusive to capture in a review.

In lifecycle management, McConnell advocates a traditional waterfall model, arguing that errors are more expensive the earlier they are committed and the longer they are allowed to proliferate: don't design until know the requirements; don't code until you have a consistent design. This flies in the face of more recent tendencies towards agile development, which considers continuous changes in requirements and in design to be just facts of life.

In coding practices the most important lesson that I am taking away is this: programming (in anything but assembler) is writing for a human readership. When you experience a conflict between writing convenience and reading convenience, always side with the latter. This holds even if you are only "writing a program for yourself": yourself in 2 years will be a different person from yourself now. And I will never use i and j als indexes in a double loop again.

McDonnell likes code reviews but only if they are sufficiently formalized to become inspections. He also encourages pair programming because (and only if) it combines insights of people from different backgrounds.

Despite the considerable size of the work, there are now serious gaps.

The gap that contributes most to the risk of this book becoming outdated, is the total absence of development frameworks. Nobody develops systems from scratch anymore. Quality standards, testing strategies, and especially design are seriously informed by the availability of frameworks. If your team has to spend time re-inventing MVC or similar design patterns, even with the Gang of Four in hand, you are probably bleeding money.

Not entirely unrelated to the absence of frameworks, I find it hard to understand why there is no mention of two-tier or three-tier applications. Business software based on a relational database and offering a web interface is no longer just one of several options (was it, back in 1993?): it is the de facto standard.

Also, dear Steve or editors: please start to include Python and Javascript already. Less and less organizations do C++ anymore, and most of the reasons for that actually follow from your book!

Една от най-добрите книги за софтуерно инженерство, които съм чел (и според мен е задължителна за всеки, който смята да се занимава сериозно с това). Пълна с много полезни принципи за това как да пишеш по-качествен код и да разработваш по-качествен софтуер като цяло.

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.

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.

I should've read this ten years ago

I'm ten, eleven years into my professional career now. Add to that another ten years of coding as a hobby. During this time I've picked up most of what is written in this book naturally or through colleagues, mentors and other sources. However, it has still served as a good reference and reminder of all the non obvious things that are important in program. That it matters not just what we write but how we write it.

It was however, a rather tedious read if I'm to be honest. It's a bit dated and though it's aged fairly well it's simply a very big book making it tough to consume.

I think at this point we may have other sources such as Clean Coder or similar that are easier to get through in smaller bite sizes. Still, I'm happy i read this and I would recommend it to get the full picture.