DEV Community

Aly Sivji
Aly Sivji

Posted on • Originally published at alysivji.github.io

Book Review: Code Complete

This post was originally published on Siv Scripts

2017 is the year I became deliberate about my approach to programming. Like most newbie developers, I hacked together spaghetti code around chunks of answers I found on StackOverflow (Praise Be).

I didn't care how I solved the problem, only that it was solved enough to cross off my todo list.

By ignoring recommended software development practices such as coding standards, version control, and testing, I ended up making things harder for myself in the long run.

I worried about introducing bugs everytime I touched the codebase. I couldn't reuse code because my functions and modules were tightly coupled. It was difficult to wrap my brain around the complexities of large projects with many moving parts.

Then I discovered Code Complete. Steve McConnell changed the way I thought about code. He made me realize that the process of doing things methodically is a lot more important than simply solving the problem at hand.

If we break down tasks into manageable components, we can build anything we can imagine.

Go read Code Complete. It will change your life the way it changed mine. Doesn't matter if you're a beginner or a seasoned professional, you'll become a better developer just by reading this book.

In this post, I will summarize the themes of Code Complete.


Themes

Reduce Complexity

A primary goal of software design and construction is conquering complexity. The motivation behind many programming practices is to reduce a program’s complexity, and reducing complexity is arguably the most important key to being an effective programmer.

As we increase the number of things we keep track of, we increase our chances of introducing a bug in our program. If our code is readable, we are more likely to find logic errors.

Two ways to reduce complexity:

  • Use helper functions
  • Refactor conditional tests into readable boolean expressions

What's easier to read:

# okay
for employee in all_employees:
    if employee.active == True:
        print(employee)

# better
for employee in all_employees:
    currently_employed = (employee.active == True)

    if currently_employed:
        print(employee)
Enter fullscreen mode Exit fullscreen mode

Process Matters

Observing large processes and small processes means pausing to pay attention to how you create software. It’s time well spent. Saying that “code is what matters; you have to focus on how good the code is, not some abstract process is shortsighted and ignores mountains of experimental and practical evidence to the contrary. Software development is a creative exercise. If you don’t understand the creative process, you’re not getting the most out of the primary tool you use to create software–your brain. A bad process wastes your brain cycles. A good process leverages them to maximum advantage.

It's about doing things in a way we can best guarantee success. Sure we can create a product that works, but it only works now. What if requirements change? How are we going to handle those changes?

We are dealing with a living, breathing product. We need to leverage processes that help us handle changes as they arise.

One of the reasons I love Code Complete is that it introduced me to the concepts of TDD (Test Driven Development). After years of struggling with regression errors, I finally understood why testing is a large component of proper development methodologies. Tests make our lives easier in the long run.


Reability

You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you’d have to do again and again.

Code is read by humans far more than it is written. Your interpreter or compiler doesn't care if it's clean or messy so write for your audience, i.e. you in six month's time.

Both of these blocks of code produce the same output, but which one makes more sense?

# bad
for x in my_list:
  print(x[0])

# good
for employee in company_roster:
  print(employee.name)
Enter fullscreen mode Exit fullscreen mode

Program into Your Language, Not in It

Don’t limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal.

This is a topic I explored when I dug into Context Managers: doing things a certain way in one language doesn't mean that we should follow the same pattern in another language. When I came into Python from C# and JavaScript, I brought all my habits with me. Instead of looking for a Pythonic solution, I looked for the Python syntax to do things the way I've always done them.

Always try to use your language of choice idiomatically.


Conventions for Clarity

The specific way in which ... a question is answered is less important than that it be answered consistently each time. Conventions save programmers the trouble of answering the same questions, making the same arbitrary decisions–again and again.

Programming is hard enough. Use style guides and logical variable names to make it easy for yourself and your team. Doing things in a standard way builds competency. Look for best practices and incorporate them into your process.


Program in Terms of the Problem Domain

Another specific method of dealing with complexity is to work at the highest possible level of abstraction. One way of working at a high level of abstraction is to work in terms of the programming problem rather than the computer science solution.

Keep business logic separate from the underlying implementation. Separate out parts of the project with helper functions, classes, or a REST API.

The This Developer's Life podcast featured an abstraction episode which discussed how we primarily concern ourselves with the layer we are currently working in. We might need to peel a layer or two from the onion when we encounter problems, but that's more on a need to know basis.


Watch for Warning Signs

Warning signs in programming alert you to the possibility of problems, but they’re usually not as blatant as a road sign that says “Watch for falling rocks.”

Code smells. Look out for patterns and symptoms that indicate a deeper problem. I'll dig into this more once I read Uncle Bob's Clean Code.


Iterate, Repeatedly, Again and Again

The more you iterate in each development activity, the better the product of that activity will be.

Iterating to a final product is a great way to build software since we can be sure that early versions of the feature are implemented in a manner that will be used.

This is also a good approach to life. Iterate your processes, optimize your workflow as you figure things out.


Don't be Religious about Software

Dogmatic methodologies and high-quality software development don’t mix. Fill your intellectual toolbox with programming alternatives, and improve your skill at choosing the right tool for the job.

Always use the best tool for the job at hand. This might require us to learn a new language, tool, technique, or framework. That's okay. As programmers, we are meant to solve problems. Sometimes this requires us to piece together a solution from many different components.


Conclusion

The first few chapters of Code Complete totally changed the way I look at software development. I've started to approach programming like a craftsman learning a trade. I am but a simple apprentice learning from the masters who have come before me.

I need to stay humble and realize that I don't know everything, but that I have the ability within me to figure out how to solve problems. Stand on the shoulders of giants. Use design patterns, algorithms, techniques, frameworks, or whatever else makes life easy. Just remember to approach development pragmatically.


References

McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction, Second Edition. Microsoft Press. [ISBN: 0790145196705]

Oldest comments (9)

Collapse
 
calebcauthon profile image
Caleb Cauthon

I'm reading this right now too. I am learning on every page. High five.

Collapse
 
alysivji profile image
Aly Sivji

What's been the most useful thing you've learned?

Collapse
 
calebcauthon profile image
Caleb Cauthon • Edited

Definitely the theme of avoiding dogma. Everything is written in a "here's some great guidelines, but almost nothing here can be applied blindly." I realized I had been following some some ideas blindly.

The chapter on design was particularly eye opening.

Collapse
 
eljayadobe profile image
Eljay-Adobe • Edited

+1!

I consider Code Complete one of my core books.

Also Clean Code, Writing Solid Code, Design Patterns, Anti-Patterns, The Design of Everyday Things, Debugging the Development Process, Structure and Interpretation of Computer Programs.

(Also some books that are technology specific: C++ Programming Language, C++ Coding Standards, Design and Evolution of C++, Eloquent JavaScript, JavaScript The Good Parts, The Book of F#, Large-Scale C++ Software Design*, WPF 4.5 Unleashed, Application = Code + Markup, Programming WPF. And methodology and/or process specific: Succeeding with Agile, The Scrum Guide.)

I've NOT read these books, but they've been highly recommended to me as "must read" books by people I respect & they're in my queue: The Pragmatic Programmer, The Clean Coder, Test-Drive Development by Example, Growing Object-Oriented Software Guided by Tests, Domain Driven Design, The Mythical Man-Month, The Cathedral & The Bazaar, Refactoring, Influencer, Getting More, Measuring and Managing Performance in Organizations, The Power of Habit, Drive, Enough Rope to Shoot Yourself in the Foot, The Elements of Programming Style, The Elements of C Programming Style.

I've probably missed a few, I'm writing this off the top of my head. And there are probably many excellent books out there that I haven't been exposed to yet.

* Lakos's book is a bit out of date. Still very appropriate for my project. A second edition is supposed to be coming soon.

Collapse
 
bosepchuk profile image
Blaine Osepchuk

Aly, you stumbled onto a truly excellent book.

I read Code Complete when I was starting out. I was a beginner programmer and I was looking for a way to level-up. McConnell did not disappoint.

Collapse
 
ben profile image
Ben Halpern

Nice review 👍

Collapse
 
hoursgoby profile image
Adam Perry

Anyone else triggered by "== True"?

Collapse
 
nans profile image
Nans Dumortier

Hi! Great article, thank you.
I started reading code complete, and I'm enjoying every single page I read!
After almost a year, have you kept reading the book? Do you have further comments or feedback about it?

Collapse
 
alysivji profile image
Aly Sivji

It's been a year since I finished it and I still think about its lessons all the time. Not a week goes by that I don't reference it in a conversation with another developer.

Life changing book. At least for me.