How to categorize books as a Software Engineer and maximize your knowledge
How to organize your readings efficiently and don't get lost in your bookshelf
Reading books is a crucial part of my life as a Software Engineer.
I still remember buying the first book related to Software Engineering: Clean Code by Robert C. Martin. I read a lot of online content, but I couldn’t imagine living without books. Books offer a different perspective and, often, a deeper view of some topics.
Finding good books is easy; the hard part is deciding what to read.
There are many choices, and searching for “best books software engineering” produces “Top X books…” posts. Sure, some are great, but the problem is that most of them are just the same proposals. How can you structure your reading list? How can you create your path through the books to improve as a software engineer?
Let’s start by dividing books into categories.
Note: links in this post are affiliate links you can use to support my work.
Categorize books by depth
The first categorization is by the depth of the explanation.
Some books focus on a single topic and explore it in depth. Others embrace a broader category and give an overview of many topics. Finally, there is a hybrid category that can go deep into a single topic while also giving an overview of others.
Here are the categories.
1. The Shelf 📚
The shelf is a type of book explaining many topics.
It doesn’t dive deep into any of them. Every chapter is usually related to a single topic. They are typically structured around a single broader topic and explain various aspects.
Some examples of great books in this category are:
Reading these books will reveal that they explore several topics. After reading them, you should have an idea of some topics and a good understanding of others. The main point is that you’ll gain an overview to decide what to study more.
Take notes and use bookmarks to save the topics you want to dive deeper into.
2. The Bible 📖
The Bible is the opposite of the shelf, one very deep topic.
Almost every topic has its Bible. The one book you must read to master the topic. You can get it by the title of the book. Here are some examples with related topics:
Domain-Driven Design and Implementing Domain-Driven Design: Domain-Driven Design
Node.js Design Patterns: Node.js
Accelerating Server Side Development with Fastify: Fastify framework
Monolith to Microservices: migrating from monolith to microservices architecture
This type of book is never finished. You can read it once, but it is very unlikely that you will get all the knowledge in a single time. These are books you always want to read again when you are in doubt.
Keep your bibles where you can easily take a peek as needed.
3. The Pocket 👛
The Pocket is a small book about a single topic.
The Pocket can be compared to a single chapter of The Shelf with more insight. It usually is less than 200 pages. Here are some examples:
Don’t underestimate the Pocket category. Having a few on your shelf can give you a considerable boost. There are topics you don’t need to go too deep on but still want to discuss, and that’s the perfect spot for the Pocket. Also, reading a Pocket can lead you to a related Bible.
Use the Pocket when you need to know the topic without going too deep.
This division is not so strict; some books belong to more than one category.
The categorization aims to help you decide how to structure your reader’s path. Diving into a Bible without any knowledge of the topic might not be the best investment of your time, and reading a Pocket and adding a new voice to your resume might not be the best idea.
Jump between categories to structure your knowledge.
Categorize books by topic
Software Engineering books can easily be divided into topics.
If you reached this point, you should know that this division mostly relates to the Bible and the Pocket categories. Some Shelf books talk mainly about a single topic, so they can still be categorized by topic. The categories of Software Engineering books are:
Programming Languages
Architecture and Design
Process and Infrastructure
Soft Skills
There are clearly different situations in your career where you might want to read about a specific topic. I explore this idea in depth in another post.
The thing is, you cannot exclude any of those categories from your path.
1. Programming Languages
This category of books usually provides a profound explanation of a single programming language.
Almost every programming language has its Bible book. Sometimes more than one. You don’t necessarily need to read it, but it might give you many insights. Sometimes, these books can be replaced by online documentation.
These books become obsolete very fast.
2. Architecture and Design
This category is vast.
It goes from the pure code design to the system architecture. I suggest starting with the low-level code design. As a software engineer, you’ll start by writing and reading a lot of code. Growing in your career, you’ll begin to define and work on higher-level architecture.
Reading the right book in the right career step is essential.
3. Processes and Infrastructure
I put Processes and Infrastructure together because, in my experience, they can’t be split.
Your process depends on your infrastructure and vice versa. These are not DevOps things. As a Software Engineer, you need at least a basic understanding of the infrastructure where your code runs. As you grow in your career, you’ll realize that speaking about the processes you work with is crucial. The process needs to start from you, not from the top of the company, so you need to understand it.
Knowledge of the infrastructure and the processes is essential to growing as a Software Engineer.
4. Soft Skills
Software Engineering is a team work.
Even if you are not a manager or a team lead, you must understand some concepts of people psychology. Understanding how people trust each other is essential. This is probably the book category I find myself reading most. I believe this kind of knowledge needs to be transmitted through a book. Online content is not enough for me.
Being a good team member is part of being a good Engineer.
Did I miss something? Don’t you agree with my categorization? Let me know in the comments.