Nowadays, we have many means to learn technical stuff - Stackoverflow, podcasts, Medium, blogs and video tutorials - but reading a good book is still something that you should not miss out on. I personally wish I would have read more in the early days of my career, but oh well, better late than never. I have curated a list of 8 books that I have read and that I think every software engineer should read. Obviously, there are many good reads out there but the following books (in no particular order) will make you a better software engineer. I will write a detailed review about each of them in the upcoming weeks.
Design Patterns: Elements of Reusable Object-Oriented Software
Authors: Erich Gamma, John Vlissides, Richard Helm, and Ralph Johnson
The gang of four does not need any introduction and neither does this book. It starts by explaining what is a design pattern and takes you through the journey of three distinct design pattern categories: creational, structural and behavioural. This book is inspired by Christopher Alexander’s ideas about patterns in buildings and towns and employs them towards object-oriented design patterns. Alexander wrote:
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
In my experience, many of the design patterns described in the book such as singleton, factory, facade, and so on are expected basic knowledge for producing high quality artifacts. Let me know in the comments what are your thoughts if you read the book.
Peopleware: Productive Projects and Teams
Authors: Tom DeMarco, and Timothy Lister
This timeless book was written by two seasoned software consultants sharing their vast experience on managing software development. This is my favourite quote from this book, which reflects what it’s all about:
When software development projects fail, many factors get blamed—from the technology to the hours put into a project. However, the problem often has a deeper cause: Management fails to consider the human element required for effective software development.
This book dives deep into the following subjects: managing human resources, growing productive teams and, my favourite, how to build a team that is actually fun to work for. I can’t emphasize enough the importance of this book for all software engineering managers. Have you read it? What do you think? Let me know in the comments.
The Five Dysfunctions of a Team: A Leadership Fable
Authors: Patrick Lencioni
I was introduced to this book recently (I know!) by my manager at Autodesk. I have to say this is one of the best books I have read. Patrick Lencioni knows the game very well. I personally could relate to almost all the points having experienced each situation during my career in one way or another. These are the five dysfunctions that Lencioni dives deep into:
- Absence of trust
- Fear of conflict
- Lack of commitment
- Avoidance of accountability
- Inattention to results
As you might guess from this list, Lencioni’s takeaway message is,
Indeed, great teamwork does not happen by accident; it requires concerted and deliberate efforts.
This is good advice to remember when things are going south! I will write a detailed review about this book, but I would like to know what are your thoughts?
The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change
Authors: Camille Fournier
As a software engineer, at some point in your career you have to decide if you want to continue the technical path or go managerial. It is a tough decision. The love for the code and technical stuff will make you think twice or more! But, I believe it should be organic, and you know yourself better than anyone else. There are many steps to go through to get there if you are looking at the managerial path and this books covers it all. From engineer to technical lead to engineering manager and director all the way to becoming the CTO. I recommend this book to all software engineers, technical lead and managers out there! If you have read this book, I would love to hear your thoughts!
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Authors: Gene Kim, Kevin Behr, and George Spafford
This “technical novel” aside from being entertaining has lessons to learn from. The book is the story of Bill Palmer who is unwillingly becoming the VP of IT operations at Parts Limited, a car parts company on the verge of financial meltdown. An allegory that covers system thinking, feedback loops and continuous learning culture, The Phoenix Project tackles project-related problems straight on and explains different ways to get everyone on the same page by focusing on what is actually the matter for the business and customers and how we can leverage tools to deliver meaningful results. I recommend this book to all managers and DevOps engineers as it tries to bring a new perspective and mindset to the table. What do you think?
The Mythical Man-Month: Essays on Software Engineering
Authors: Fred Brooks
You can find this book in many curated lists on the web around software engineering and there is a reason to it. This book tries to answer the question, Why is software development different and difficult? It talks about the essential difficulties of complexity, conformity, changeability and invisibility in software development, and about why scheduling and managing software development is difficult. The take away is that software development is not just the coding, in fact it will take coding times six or more. Brooks divides some of this added effort into:
- 1/3 planning
- 1/6 coding
- 1/4 unit testing
- 1/4 integration testing
In the 2005 article Quoted Often, Followed Rarely, Brooks states:
The book is really more about management than about technology. The technology has changed immensely, so some of the old chapters are totally out of sync. On the other hand, people haven’t changed much. That’s why Homer and Shakespeare and the Bible are still relevant, because they’re all dealing with human nature. I think that’s part of the explanation for this book: The problems of managing people in teams have not changed, though the medium in which people are designing and the tools they are using have. Some people have called the book the “bible of software engineering.” I would agree with that in one respect: that is, everybody quotes it, some people read it, and a few people go by it.
It is one of the good reads out there, and I recommend it to all engineering managers and software engineers! Have you read this book?
Clean Code: A Handbook of Agile Software Craftsmanship
Authors: Robert Cecil Martin
Uncle Bob’s masterpiece does not need any introduction and it is a must read for all software engineers out there. I read this book in my early days and I am happy I did. This book talks in detail about well structured code and how it should be like in order to be readable and maintainable. This technical book takes you through details of rules to follow and the reasoning behind each rule with examples. This book looks like a reference book but don’t skim, struggle through it. It’s more than worth your time. I am confident that this book will make you a better software engineer whether you are junior, senior or principal!
The Pragmatic Programmer: From Journeyman to Master
Authors: Andy Hunt, and Dave Thomas
The Pragmatic Programmer is a classic. This timeless piece summarizes the characteristics of a programmer who creates high quality artifacts. This books offers lots of practical tips around estimating, coding, testing, debugging and so on with each topic in a self-contained chapter. The book will educate you on how to be a better and more productive programmer. One of my favourite take ways from this book is the following statement by Andy Hunt:
Learn quickly. More importantly, unlearn quickly. Be willing to let go of “but I’ve always done it this way,” because next week that will change. Let someone/something else do it if it’s cheaper, more reliable, or they have more resources to devote to it.
The emphasis is on how a pragmatic programmer should invest regularly in his/her knowledge and portfolio and make a habit of learning new things. Although, it might feel a bit outdated in certain areas, I believe there are many values and lessons to be learned from this masterpiece. What are your thoughts?
