81 Books Like Clean Code

Every "computer person" should read GEB at least once. Preferably in high school, when you still have the free time to dive deep into all the recreational math exercises. If you're already working 40-hour weeks and wonder who has time for Hofstadter's 750-page "metaphorical fugue on minds and machines," all I can say is: Better late than never!

This popular book takes a broad perspective that surveys the main physical and logical layers from which all digital devices are made.

I like the accessible writing style, aimed at lay readers, and the book’s companion website, where one can experiment interactively with many of the artifacts described in the book. The second edition includes a new section that focuses on a functional subset of Intel 8080, the microprocessor that ushered the personal computing revolution, and the instruction set used by many PCs and servers today.

Even though this book is a bit older, I had a ton of fun doing the programming problems in this book. This book really makes you think outside the box as a programmer and try to solve various problems in different ways depending on what you are trying to optimize for.

I really learned a lot about not just solving a problem, but solving a problem for a specific set of goals. Overall it made me a better programmer and made me think more deeply about programming problems.

If you want to improve your problem-solving skills and have fun doing it, I would definitely recommend this book.

Wow! This book is exactly what every programmer has always wanted to know or even felt guilty about not knowing and it’s all presented in an extremely simplified and fun way. 

This is one of those books where you get excited in the morning when you wake up because you know you are going to be able to read more in the book and you are hoping the book will never end.

It’s rare to find a big book that I enjoyed reading so much and felt so short. This book covers almost everything you ever wondered about computer science. After reading this book, I felt like I finally understood everything a programmer was supposed to know and I no longer felt that nagging feeling of being an imposter.

I've found this book enlightening in many key areas of software development, and as I was reading it, I felt connected with the author (even though I've never met him, I could imagine us having a conversation about software engineering, and agreeing on pretty much everything).

It was a revealing book for me, in the sense that it gave a formal framework to several ideas I've noticed as a practitioner over the years. In that regard, I wish I'd come across this work way earlier in my career.

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.

During the early years of my career as a software developer, I regularly developed very small programs that would exercise parts of the system that I was working on back then. I realized very quickly that those small programs would save me a lot of time figuring out whether the changes that I made would actually work or not. Until at some point a colleague mentioned the concept of Test-Driven Development. I first did some experimentation, dipping a toe into the water to feel the temperature. It wasn’t until the first time I picked up this book that I jumped right in. From then moment on, it all made sense. Although this book was published back in 2002, for me it still is the book when it comes to the subject of Test-Driven Development.      

This book helped me set my initial approach to software development and I still periodically return to it for grounding.

An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.