Excellent book on software development. I read the first version years ago. It was well worth picking up the second version as a refresher. The book covers everything from personal character to how to format a for loop, it's a must read for improving your skills and to help you realize how far you still have to go.

The only problem I have with the book is the formatting. It's a nightmare of little quotes, references and key point icons (with a picture of a key - thanks...) cluttering up each page, with section headlines aligned on the quotes rather than the sections and further reading material listed every few pages rather than at the end. Given the focus the book has on readable code it's a shame the book format is such a dog's breakfast.

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.

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.

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.

Code Complete is a timeless and essential guide for software developers seeking to improve their coding skills and overall software construction process. This classic book provides readers with invaluable insights, practical tips, and best practices for writing high-quality code.

McConnell's writing style is engaging and accessible, making the book a pleasure to read for both seasoned developers and newcomers alike. The book covers a wide range of topics, including planning, design, construction, debugging, refactoring, and testing, providing a comprehensive understanding of the software development lifecycle.

What sets this book apart from other programming books is its focus on the principles of software craftsmanship. McConnell emphasizes the importance of writing clean, maintainable code, and offers pragmatic advice on how to achieve this goal. The book is filled with real-world examples, case studies, and anecdotes that help to illustrate the concepts being discussed.

All in all, this is a must-read for any serious software developer looking to enhance their skills and produce better code. The timeless wisdom and practical advice offered by Steve McConnell make this book an enduring classic in the field of software development.

For me, the main message of this book is: "Bugs in software are introduced because of code complexity."

This idea and many other things were an eyeopener to me. For example, I was not able to explain why I don't feel good about "hacky code" in feature implementation or why sometimes I read code and struggle to understand what is going on. Now I see that both of those things add a lot of complexity.

I think every developer with 3-5 years of experience should read this book. Sure it can be dated at some places and not always applicable to small companies development capabilities but it definitely conveys ideas that all developers should understand and embrace.

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.

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

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

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.

These are rather notes than a review while reading:

1. Use very descriptive names. Be consistent with your names.

2. A function should not do more than one thing.

3. SRP (Single Responsibility Principle): a class or module should have one, and only one, reason to change.

4. Stepdown rule: every function should be followed by those at the next level of abstraction (low, intermediate, advanced).

5. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment.

6. The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification and then shouldn't be used anyway.

7. Flag arguments are ugly. Passing a boolean into a function is loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another one if the flag is false.

8. Write learning test when using third-party cody to make sure it behaves the way you expect it to. And if codebase changes in time, at least you find out early enough.

На удивление простая в понимании (несмотря на объём) книга. Развернуто и по делу. Хвалить можно долго, и разумеется заслуженно. Не зря ее включают во все списки книг для разработчиков ПО.