82 Books Like Code Complete

In my consulting gigs, I come across plenty of clueless remarks. Here's a classic one: “We're falling behind schedule, so let's hire more coders.” Or a more recent gem: “We'll be ten times more productive if we generate code with AI.”

When I encounter such nonsense, I don't facepalm or cringe. Instead, I put on my poker face and drop a quote from The Mythical Man-Month.

In an industry where last year’s book is already outdated, Fred Brooks' collection of essays has been a guiding light for nearly half a century. His aphorisms have become legendary. “The bearing of a child takes nine months, no matter how many women are assigned.” “Adding manpower to a late software project makes it later.” “There is no silver bullet.” The list goes on and on.

John Carmack, one of the greatest programmers of our times, used to revisit this book every year or… show more.

I’ve found in this book many useful topics about low-level design which connected with my first recommendation (Code Complete). For instance, about creating functions not only as a tactic for reusing code, but more as a way to give clear meaning to parts of the code, and make it more readable. I was happy to find in these authors ideas I have been agreeing with for a long time.

Then there’s also the fact that this book provides several examples with code on how to make the design simpler to maintain, and clearly illustrates the S.O.L.I.D. principles.

Yes, it’s a textbook, albeit a particularly well-written one. You may already have it on your shelf, if you’ve taken a programming class or two.

I’m way too old to have used CLRS as a textbook, though! For me, it’s an effectively bottomless collection of neat little ideas—an easy-to-describe problem, then a series of increasingly clever ways to solve that problem. How often do I end up using one of those algorithms? Not very often! But every time I read the description of an algorithm, I get a nugget of pure joy from the “aha” moment when I first understand how it works.

When people think about software engineering they mostly think about programming, but that’s not where a project starts. It starts with requirements.

(Really it sometimes starts with company politics, bickering, excuses, and backstabbing, but requirements gathering is often the official start.)

A good set of requirements keeps developers pulling in the same direction; a bad one can make the team inefficient, cause endless arguments, set developers against each other, and make the project feel like Lord of the Flies. I’ve seen projects scrapped and restarted from scratch or even canceled due to poor documentation.

Every software developer should know at least a little about writing so they can produce clear requirements and documentation.

This book isn’t specifically about writing documentation (which is something of an art in itself), but it can help you learn how to make your business writing more effective. This book won’t turn you into Shakespeare,… show more.

I have to be honest here: when I was reading this book on a trip to New York, I found myself quite surprised because I had seen so many praises for this book, yet I did not particularly agree with most of the topics I was reading about. In particular, I found several points that contradicted those in Clean Code and Code Complete.

I know there’s a debate going on between the authors on a distribution list, but besides some of these points on which I respectfully disagree with the author, I can see is a book of immense value, and there are tons of other great points made about great software design (for example, ”modules should be deep”). And the explanations are crystal clear.

A final reason for recommending this book is that it’s always enriching to expose oneself to a different viewpoint.

The marvel of this book is that it's a rare one: most of the books focus on the construction part of software, all the design and preparation. But what happens once the system is out there, launched? Release It! focuses on the software architecture aspects that entail designing a platform to make it reliable once it’s been released.

It touches on concepts like logging, locking, circuit breakers, and it’s written from the author’s experience with real-life examples (and even code snippets). As someone who has worked on several different types of software products (and been on-call), I’ve enjoyed reading the author tell us about things that went wrong in the past, and what lessons were learnt from them.

I've found this book to be instrumental in my career as a software engineer, especially because it's full of useful and practical advice on how to be effective and productive on a day-to-day basis, but it also includes actionable advice, and helped me a lot on thinking about my career long-term.

Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. The descriptions of each principle are concise, whereas my 60 lessons in Software Development Pearls go into a great deal more detail and offer many practical techniques.

There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.

A thoroughly fascinating (and fascinatingly thorough) look at engineering practices at Google.

It’s an encyclopedia written by a bunch of authors, so some of the chapters are a little dry, but for those of us who aren’t on teams with 25,000 engineers it’s spell-binding to see what programming at that sort of scale looks like. Some of the chapters prompted us to think really hard about the way we do things at Sucker Punch.

I was lucky enough to read an early draft of this book and it’s simply the best analysis of the open-source software ecosystem around today.

The writing style is friendly and not formal despite the academic-level research that went into this book. It made me think differently about the open-source projects I maintain and how I interact and chose those I use.