If you’re a Software Engineer it can be a challenge to find good, high quality books that focus on technical topics. As avid reader myself, I’ve compiled a list of what I would consider my top 10 books that I think are some of the most well-written and concise books that focus on building great software.
Not all of these recommendations will be for everyone and I recommend starting with what interests you first, then branching out and exploring from there!
This book probably isn’t a surprise for anyone who’s been in the software development industry for very long. It’s arguably one of the most recommended books that you hear about when you’re first starting out as a Junior Developer.
That being said, it’s absolutely for good reason. Pragmatic Programmer is one of those quintessential read that is packed from beginning to end with the sage wisdom and lessons learned from years of building software.
Some of the stand-out takeaways that I personally learned from this book are:
While Pragmatic Programmer takes the approach of focusing on what makes you a great developer, the Timeless Laws of Software Development focuses on what makes the software itself great.
It first starts with focusing on the thing we (hopefully) all do before any code at all even gets written: planning! It then goes on to the code itself, giving practical advise on things like naming, readability, and how to mitigate bugs and errors.
A particular point that the author makes is on premature optimization. We as developers tend to suffer from perfectionism, which can lead us to wanting to make the most hyper-efficient software from the beginning. You could spend weeks on performance tuning and making everything as fast as possible, or you can spend more time building features that users with find more valuable than a 5 millisecond decrease in response times.
At some point or another, you’ll need to really get into the nitty-gritty details of how your code is doing. This can be from the objective perspective of “does my code accomplish what the business needs it to”, to the more subjective “is my code reliable and performant enough for what should be expected of it?”
These can be tricky questions to answer, and Seriously Good Software can help give you qualitative metrics to help you answer the question “is my code good enough?”
From time and space complexity to maintainability, correctness, and testability, this book is a guide for how to write clean code. One aspect of this book that I particularly enjoyed was the authors approach of taking a real world example and then going through several refactors, explaining each step of the way on how we were improving the code at hand!
One of the best things you can do to improve your code problem solving skills is to look for ways to approach problems from a different perspective. Grokking Simplicity does just that by breaking down how we can develop systems to be simpler and more manageable through the lens of Functional Programming.
Though most of us don’t work in a pure functional language for our day jobs, we can still use the principles of FP such as immutability, first-class functions as abstractions, and isolated side effects to build better software. I personally don’t subscribe to the school of thought that Functional Programming is the one-stop-shop solution to all our problems, but I do strongly believe that is solves certain problems extremely well (the success of the front-end React library for UIs which is based on FP ideas tells us as much).
If you’re completely new to the school of Functional Programming, this book also can act as a good introduction to the subject, helping answer a lot of those “Why would I do it this way?” questions that many ask when first learning about FP.
If you work at a company that has more than a dozen developers, there’s a good chance you’ll be working in a Microservice-driven environment. Building systems that use Microservices is a large and complex area that has many facets such as service-to-service communication, coupling, interacting with external systems, data persistence, and deployment just to name a few.
One of the things I love about this book in particular is that the author Sam Newman first starts off with the argument that the Monolithic-style architecture should be the default, not a Microservice-based one. Some fledgling startups make the mistake of jumping right to Microservices, not realizing the amount of work that is needed to make Microservices successful.
Building Microservices will take you through how to build a system that leverages Microservices the right way. It will teach you the different types of coupling (and how to mitigate coupling overall), how to apply the right amount of Domain-Driven Design, how to decompose an existing Monolith, the different types of service communication and which one to pick, concrete approaches for handling distributed data transactions using Data Sagas, strategies for deployment, how to test services effectively, and much more!
Software Applications today are really driven by their customers data and how effectively those systems can use that data to deliver meaningful features. This has caused the recent rise of the field of Data Science as well as creating a new path for developers: the Data Engineer.
The nuances of what a Data Scientist does vs what a Data Engineer does and who has what title are dependent on the organization. But all of us can agree that the challenge of building large systems of scale that need to be able to store, process, and analyze vast amounts of data are becoming critical to just about every business that want’s to reach as many customers as it is able to.
Designing Data-Intensive Applications explores just that, focusing on the key components that make data-driven applications successful: reliability, security, scalability, and maintainability. Starting with a fantastic overview of the various ways to model the data of your problem domain, then exploring the internals of data storage systems and the relevant encoding and serialization processes, the book then dives into key practices of maintaining a system of data including replication, partitioning, data transactions, distributed networking and fault tolerance, to data consistency and consensus algorithms. And finally, the book takes a detailed look at two fundamental ways of processing large scale data: Batch and Stream processing.
In 2008, Google decided that the current way it (and the rest of the software industry) was managing its internal systems simply was not working anymore. They then began to approach the operational aspect of software applications in a new way, which they dubbed Site Reliability Engineering. Fundamentally this approach was all about applying the practices of software engineering to solve the problems and headaches being experienced by IT operations at the time.
These fundamental practices have largely been distilled into the book, Building Secure and Reliable Systems. The book begins by putting the word “reliability” under the microscope to really understand what it means to say that the systems we’re building are indeed reliable. From there we connect reliability to the concerns of security, then take a look at how to actually design our systems in a way that is not only reliable, but also secure and maintainable.
The book explores key topics such as defensive in depth, managing a sub-systems “blast radius”, building processes of recovery (it’s not if a system fails, but when it will fail), common security vectors malicious attackers will look to exploit and what to do about them, effective code testing, best practices for creating strong deployment processes, incident response, and finally how to really build a culture of reliability.
Knowing how to write Infrastructure-as-code (or IaC) is increasingly becoming a more and more in-demand skill that companies are looking for as more organizations are adopting modern DevOps practices. The ability to manage a software system end-to-end using code follows the practices of SRE to apply key software engineering principles to operations, and all of the benefits that doing so entails.
In his book, Infrastructure as Code, Kief Morris takes a deep dive into the hows and whys of the subject. As someone who has worked previously as a Platform Engineering writing almost nothing but IaC, I don’t think I’ve seen a more in-depth explanation of both the benefits that IaC provides, as well as practical guide on how to really write IaC at scale.
Morris begins with a direct explanation of what IaC is, and gives guidance on what the benefits of IaC are so that you might be able to convince an organization to adopt it. From there, he explores the different aspects of an infrastructure platform in depth, including the three main pillars of software systems: Compute, Storage, and Networking. From there, the rest of the book is about the core organizational unit in IaC, the “stack” (not to be confused with tech stack), and the best practices of how to write build, organize, test, manage, and deploy these stacks.
The term “Senior” is given to an Engineer who has been working the software development industry for some period of time, and who is able to consistently deliver features again and again. But the qualities that define a Senior Engineer can vary from company to company, and it can be difficult to know what areas you need to focus on as you look to make the transition from mid-level to senior!
This book will guide you through practical things you can start doing right now as a developer that will take you to the next level in your career. The key topics of the book are:
This book isn’t a technical book. However, mastering the art of effective communication is so critical to being a great developer that I personally believe this book is worth mentioning. Developers sometimes get a bad rap as the shy, awkward nerd who never says anything, and when he does, he ends up fumbling all his words.
But being a developer is 50% problem solving and 50% communicating about problems and solutions with other people. Be it other developers, product managers, stakeholders, designers, business people, and even sometimes the users themselves, we all could use some practical advice on how to be a better speaker.
Carol Fleming, Ph.D. is the author of It’s the Way You Say It and is a personal communication coach and founder of The Sound of Your Voice. In her book, she breaks down how to identify issues in the way you speak, and what to do to resolve those issues so that you can be a better communicator.
I’ve never had an interest in becoming a manager. And for a while I assumed that once I reached the level of Senior Engineer, that would be it and I would have no choice but to go into management if I wanted to progress my career.
But Tech companies have also realized that not every developer is interested in becoming a manager, and so have created a path for Individual Contributors who are still looking to evolve their career: the path of the Staff Engineer (and beyond).
Will Larson really dives into what makes a Staff Engineer in his book, from the different “archetypes” that these types of Engineers tend to fall into, to the problems they look to solve for their organization. The second half of this book is simply stories from all manor of Staff Engineers from companies including Uber, Slack, and Stripe!