Today I wanted to talk about 5 books that I think every software engineer should read. These books don’t pertain to any specific technology stack, but to software engineering in general. They are also very easy reads and not technically overwhelming for new software engineers. Some of them do have code samples and practical examples, but they are still very easy to follow, with a low barrier to entry. I did a similar video a few years ago and since then, I’ve read a lot of books and that list has changed a bit. So I thought I would make an updated version.

Clean Code

The first book in this list is Clean Code by Robert C. Martin, lovingly referred to as Uncle Bob. In a fictional world, if there was a law to be passed that mandated every new software engineer to read a book and keep it around for the rest of their careers, it would be this book. This book was there in my last list and will probably continue to be there until something revolutionary happens that makes the ideas in this book obsolete. So far, that’s not the case.

There is so much conversation in the software engineering world about efficiency, optimization, algorithms and many things that are geared towards making great software, but there isn’t much information about how new software engineers can get to the place of being able to write great code. And the simple answer is by building good coding habits. This book is essentially that — a list of coding habits you should start building early in your career and continue to build throughout your career.

Let me give you an example. Chapter 1 talks about the “Boy Scout Principle.” The term itself is very old school and in 2022, not very inclusive of other genders, it should probably be changed to just the “The Scout Principle” because anyone can be a good scout not just boys. But, I digress. The idea of the scout principle is to leave the camp ground cleaner than you found it. Does this have to anything with software engineering? No. But the concept applies. You will be surprised how many times I have encountered software engineers that just want to patch up and move on because it is someone else’s problem. If you follow the scout rule from early on, you will at least raise concern every time you see problems in your code base, even if you don’t have time to fix it. And over time, this attitude morphs into a critical leadership trait where lack of quality in a project that you work on is your problem, regardless who wrote the actual code.

But the book is not limited to just analogies that are linked to software engineering. It has some very good technical information about abstractions, object symmetry, error handling, test driven development, refactoring, concurrency, code smells and much more. These topics together will help you build a set of rock solid habits that are common traits of great software engineers. Remember that 9 out of 10 times, it isn’t your pure genius that makes you a great dev, it’s the small “good” things that you consistently over many years.

Clean Architecture

A natural follow up to Clean Code is Clean Architecture, also by Robert C. Martin. Building software systems or services isn’t just about writing a method here, fixing a bug there, adding a feature in another place ... at some point, you will need to start visualizing the entire picture at a high level to be able to create a sound architecture. This is where things like understanding how various components should work together, how to make pieces modular or how to keep it flexible and extensible, yet free of security concerns come to play.

And this book teaches you exactly that. In chapters 1 through 6, it explores the foundations of structured, object oriented as well as functional programming. Chapter 5 - 11 is dedicated to the SOLID principles, the most important design patterns you will learn and ones that are still relevant today regardless of what type of programming you do. SOLID basically stands for Single Responsibility principle, Open-closed principle, Liskov substitution principle, Interface segregation principle and Dependency inversion principle. I will make a dedicated video about these design patterns soon because they deserve more attention. For the remaining chapters, it goes on to talk about ideas around designing components, cohesion and boundaries, which takes a note from Behavior Driven Design.

This book isn’t for an absolute beginner. But as you start getting familiar with Clean Code and gain a few years of experience, this is a great book to start and keep in your collection.

The DevOps Handbook

The third book I recommend is the DevOps Handbook by Gene Kim, Jez Humble, Patrick Dubois and John Willis. In 2022, as a software engineer, you should be well-versed with DevOps. I know some companies have dedicated DevOps positions and engineers don’t need to deal with it, but I will tell you that this is getting rarer everyday and will continue to do so. So it’s a great idea to start learning about it.

Good DevOps practices in today’s world is critical for producing high quality, constantly evolving and competitive software or services. And this book is a great introduction to the world of DevOps. This book introduces you to the concepts and best practices of agile continuous delivery, things like the foundations of a robust deployment pipeline, automated testing, continuous integration as well as risk-averse releases. It also introduces you to proper ways of collecting telemetry to anticipate issues and also the best security practices to protect your deployment pipeline from potential threats.

As I mentioned before, I think this book should be a part of any software engineer’s resource set in 2022.

Software Engineering at Google

The fourth book I recommend is Software Engineering at Google by Titus Winters, Tom Manshreck and Hyrum Wright. I love this book because it explores how large, monolithic codebases are managed and maintained collaboratively by thousands of software engineers across thousands of projects. This book covers everything: the idea of software engineering vs programming, culture, knowledge sharing, leadership, productivity, engineering best practices, documentation, testing, version control, dev ops, and so much more. And what I like even more about it is that it doesn’t overwhelm you with technical jargon and instead goes over the concepts, anti-patterns and recommendations in a very anecdotal fashion.

An example of something this book talks about that there isn’t much literature about, is code reviews. We either review code, or have our code reviewed on a daily basis. But there is very little training around it. There is more to code reviews than just the act of making sure the code meets a certain bar for quality. From the perspective of new inexperienced software engineers, code reviews can be quite nerve wracking. And from the point of view of experienced engineers, one strongly worded comment can destroy the confidence of a young engineer. So even though it’s all about code, there is some responsibility in terms of communication and mentorship. And I love that this books touches on those things.

And while the information shared in this book is about engineering at Google, the lessons pertain to any large engineering project. So if you are specifically interested in Google, that’s great, but even if you are not, this book is an amazing read.

Understanding Distributed Systems

The fifth and final book I recommend is Understanding Distributed Systems by Roberto Vitillo. You are using myriad of distributed systems on your daily life. Asking a voice assistant to turn your lights on or off, receiving notifications when laundry is done, backing up your files on One Drive, iCloud or Dropbox, a range of cloud-based applications including your email and all your social media, video call to friends and family, starting your car remotely, your Ring door bell, your Nest thermostat ... this list can go on for a long time, and they are all some form of distributed systems. Also, according to Stack Overflow’s 2020 developer survey, the highest-paid software engineering roles require distributed systems experience.

So, whether you work directly on distributed services or not, as a software engineer, it is always great to understand how distributed systems work. And the reason I recommend this book is because it is such a smooth and easy introduction into the world of distributed systems, which is not the case for many other books in the same domain, which tend to be very dense and technical.

But, even though this is a small, easy-to-read book, it does a great job at covering a lot of ground. It first introduces you to the common challenges distributes services face. Things like scalability, consistency, availability and resilience. It then introduces various areas that come together to make a system distributed. Things like how communication works over the internet, which is obviously the foundation of any distributed system, APIs, discovery, replication, transactions, scalability techniques, disaster recovery, testing, monitoring and continuous delivery.

So whether you are starting out with distributed systems or just curious about how day-to-day things you use like your social networks work behind the scenes, this is a great book for you!