In the coming days i will be giving a summary and my own review and thoughts of Code Complete book by Steve McConnell chapter by chapter. I hope you find this book review helpful.

Chapter 1

What Is Software Construction?

In common usage, “construction” refers to
the process of building. The construction process might include some aspects of
planning, designing, and checking your work, but mostly “construction” refers to
the hands-on part of creating something

Construction activities:

• coding and debugging
• detailed design
• unit testing
• integration testing

Tasks involved in construction activities:

• Verifying that the groundwork has been laid so that construction can proceed successfully.
• Determining how your code will be tested.
• Designing and writing classes and routines.
• Creating and naming variables and named constants.
• Selecting control structures and organizing blocks of statements.
• Unit testing, integration testing, and debugging your own code.
• Reviewing other team members’ low-level designs and code and having them review yours.
• Polishing code by carefully formatting and commenting it.
• Integrating software components that were created separately.
• Tuning code to make it smaller and faster.

Nonconstruction activities:

• Management.
• Requirements development.
• Software architecture.
• User-interface design.
• System testing and maintenance

Why Is Software Construction Important?

• Putting construction in its context with other activities helps
  keep the focus on the right tasks during construction and appropriately
  emphasizes important nonconstruction activities.

• Construction is a large part of software development.

• Construction is the central activity in software development.

• individual programmer’s productivity can improve enormously.

My thoughts:

• When tuning code to make it smaller and faster one should be pragmatic about choosing algorithms, the fastest is not always the best for the job
• Design to test, build the tests before you implement the code.build testability into the software from the very beginning.
• Continuous integration and delivery should be part of the construction process to prevent the integration hell, although integrating code frequently does not by itself offer any guarantees about the quality of the new code or functionality.
• Although not mandatory including acceptance testing to be part of the construction process minimizes the amount of bugs that could be realized.
• Well written code should be self documenting and does not need comments.

Chapter 2: Metaphors for a Richer Understanding of Software Development

A software metaphor is more like a searchlight than a roadmap. It doesn’t tell
you where to find the answer; it tells you how to look for it. A metaphor serves
more as a heuristic than it does as an algorithm.

An algorithm is predictable, deterministic, and not subject to chance

A heuristic is a technique that helps you look for an answer. Its results are
subject to chance because a heuristic tells you only how to look, not what to find.
It doesn’t tell you how to get directly from point A to point B; it might not even
know where point A and point B are. In effect, a heuristic is an algorithm in a
clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day
money-back guarantee

The main difference between the two is the level of indirection from the solution.
An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for
yourself, or at least where to look for them.

How to Use Software Metaphors

• Use them to give you insight into your programming problems and processes.
• Use them to help you think about your Programming activities and to help you imagine better ways of doing things.

The Importance of Metaphors

• Metaphors have the virtue of an expected behavior that is understood by all.
• Unnecessary communication and misunderstandings are reduced.
• Learning and education are quicker.
• In effect, metaphors are a way of internalizing and abstracting concepts allowing one’s thinking to be on a higher plane and low-levelmistakes to be avoided.

Common Software Metaphors

1. Software Penmanship: Writing Code

   • “writing code.” The writing metaphor suggests that developing a program is like writing a casual letter—you sit down with pen, ink, and paper and write it from start to finish.

2. Software Farming: Growing a System

   • Creating software as something like planting seeds and growing crops. You design a piece, code a piece, test a piece, and add it to the system a little bit at a time. By taking small steps, you minimize the trouble you can get into at any one time.
   • If you buy into the farming metaphor, you might find yourself talking about fertilizing the system plan, thinning the detailed design, increasing code yields through effective land management, and harvesting the code itself.

3. Software Oyster Farming: System Accretion

• Learn how to add to your software systems a small amount at a time. Other words closely related to accretion are “incremental,” “iterative,” “adaptive,” and “evolutionary.

4.Software Construction: Building Software

• If you’re building a first-class software product, you
  might build your own scientific functions for better speed or accuracy. You
  might build your own container classes, user interface
  classes and database
  classes to give your system a seamless, perfectly consistent
  look and feel.

• Both building construction and software construction both benefit from
  appropriate levels of planning. If you build software in the wrong order, it’s hard
  to code, hard to test, and hard to debug. It can take longer to complete, or the
  project can fall apart because everyone’s work is too complex and therefore too
  confusing when it’s all combined.

• The more experienced you have with the
  kind of software you’re building, the more details you can take for granted. You
  just want to be sure that you plan enough so that lack of planning doesn’t create
  major problems later.

• In software you might generally use flexible,
  lightweight development approaches, but sometimes rigid, heavyweight
  approaches are required to achieve safety goals and other goals.

• Making structural changes in a program costs more than adding or deleting peripheral features.

5.Toolbox Metaphor

• A good craftsman knows the
  right tool for the job and knows how to use it correctly. Programmers do too.
  The more you learn about programming, the more you fill your mental toolbox
  with analytical tools and the knowledge of when to use them and how to use
  them correctly.

• The toolbox metaphor helps to keep all the methods, techniques, and tips in
  perspective—ready for use when appropriate.

To extend the “building a house metaphor” construction workers do not use a single tool — the hammer — to build a house. Instead, they have a complete toolbox full of different implements for the varied tasks involved in construction. Likewise, in software engineering, or data science, the person who only knows one method will not get very far.You should be open to learning from others, respond constructively to feedback, and fill your toolbox with the appropriate techniques.