5 books you should read as a Software Engineer and right time in your career to read each of them
These 5 books impacted immensely my career, some of them because of the specific moment I read them.
Reading is probably the habit that mostly changed my life professionally and personally.
Whether you read posts, newsletters, or books, it is crucial to keep learning new things daily and open your mind. This post is about books because books are a more significant time investment than newsletters and posts. There are excellent resources on the web to find amazing books, but I believe that to get the best out of a book, it is important to read it at the right time.
That’s why I will propose five of the best books I have read and explain the best moment in your career to read.
1. Clean Code
This is a masterpiece.
You can find this book in every Software Engineer’s booklist online. There is a reason why this book is fantastic. The basic principles of software development are explained in clear and concise words.
When should you read it?
This is the first book I bought when I started working as a Software Engineer.
I remember when I pushed my code for the first time, and the CTO of the company left, I believe, more than 20 comments during the review. I addressed all of them, of course. I believe the pattern was the same for the following ten reviews. He was very kind and pointed out the whys so I could improve.
After more than ten reviews, I started thinking, “I am too slow; I need to find a way to understand things before his comments.”
That’s when I bought “Clean Code”.
This book is also excellent if you are a seasoned developer, but it can give you the best when you start your journey. At that moment, you start understanding the principles of programming and, more importantly, re-thinking it years later; I believe thanks to this book, I started developing “the smell” for bad code.
2. Strategic Monolith and Microservices
There are books you read and books you can’t stop reading; this belongs to the second category.
I have this book next to my desk, and now and then, I go through the pages and read some passages. The title is misleading; this is not a book about microservices. This is a book about everything you should know in your career as a developer. I bought this book and didn’t read it for a while, probably a few months, because I thought, “I don’t think I should start thinking about microservices now”.
Very stupid of me; as I said, books are a time investment, and I believed that time wasn’t right for me.
Then I got COVID and, guess what, a lot of time to read. I was fortunate since I had no symptoms, so I felt good enough and started reading the book. While reading it, I realized that microservices are a tool, not a goal, and especially can be a tool to measure your organization.
If migrating to microservices is hard, your organization is not well structured.
I read this book as a Senior Engineer, and it was a great time for me, but I don’t think it’s the only right moment to read it. I later realized the correct time when I gifted it to one of my best friends. He joined a startup and was leaving Italy with his husband, so I gave him this book and told him:
” Don’t read it now. Now enjoy your new experience. But at some point, you’ll feel that something is wrong; you won’t be able to say what, but you’ll know there is something wrong with how you and your team do things. That is when you should read this book.”
I’ll tell you the same: read this book when you feel things can be organized better and more efficiently.
This book inspired a post I wrote about Conway’s law and one about problem-solving.
3. The Phoenix Project
If you think your company is a mess, you have never heard of “Parts Unlimited” (the company the book discusses).
Like many others, I had multiple times the sensation that things will never get better. Processes are so complex I waste so much time following them that I need to work after my working hours to do my job. Reading about Bill Palmer (the book’s main character) made me feel close to his efforts to fix Parts Unlimited processes and organization.
Reading this book, I saw the world through Bill’s eyes and followed his thoughts.
Bill made mistakes trying to realize a good workflow in a desperate situation. I read this book probably in the best situation. I was still a Senior Engineer, but I started having a view of how our organization worked and how we wanted to structure our processes. Reflecting together with Bill Palmer and realizing that maybe your organization has the same issue faced by Parts Unlimited on a different scale gave me a different perspective.
I suggest reading this book when you have at least a basic view of the structure of your company and its processes.
4. Accelerate
“Accelerate” is a book about answers; don’t expect long explanations. Expect facts.
This book explains shortly and clearly what the most efficient companies in the world do to be the best. I read this book because I heard so much talking about it about two years ago. I’m happy I read it but should have read it after “The Phoenix Project”.
“Accelerate” was born from a long research and the report of such research.
I consider it very close to a scientific book. You can’t explain the reasons behind chemistry, which is as it is without reason. Oxygen and Hydrogen bonding make water without explanation; it is just how nature works.
There is a reason why “elite” companies practice Continuous Delivery. Still, the book’s point is not to explain the practice but to assert that if you want to be an elite company, you should try to do Continuous Delivery. I suggest reading this book after “The Phoenix Project”. It should give you enough context to understand some of the things exposed here.
Read this book when you clearly understand your process and possibly know concepts like DORA metrics and Continuous Delivery.
5. Modern Software Engineering
Another book I keep next to my desk, but for a slightly different reason than the number 2.
This book contains the essential concepts you must master at any career level. You will find code, architectural core concepts, and why Software Engineering is “engineering”. I found a great explanation of some of the ideas presented in “Accelerate”.
But I realized the actual value of this book after a while.
At some point in your career, understanding concepts and being able to apply those concepts is not enough. We should always reflect on the best way to provide value to our company. The more you grow in your career path, the more you realize that your value is less in the code you write. I realized the actual value of this book when I started explaining some of its concepts to my teammates. Helping your team grow is not the manager’s job. It’s everybody’s job.
This book will give you the best when explaining those concepts yourself.
I wrote one post about Cohesion and one about Coupling, both inspired by this book.
Here are affiliate links to the books if you are interested and want to support my work: