2020 – My Year in Books 📚

I don’t think there has been a better year than 2020 to read. With most of us confined to our homes at some point during the year due to pandemic, books (and Netflix!) have become more popular than ever.

In this post, I’m reviewing all the books I have read in the year. Hopefully you’ll enjoy these quick reviews, plus I’ve also added a favorite quote from each.

In no particular order- let’s go!

Atomic Habits

Atomic Habits by far is the best book I’ve read in this year (hardcover). Author, James Clear, makes the argument that it’s the systems, not goals, that we should focus. Here’s his explanation “In professional sport both winning and losing teams usually share the same goal (to win!), however it is mostly about the system (routine) that each team follow, that makes the difference between winning and losing”. Here are my key takeaways

  • The concept of improving by 1% every day
  • Four laws of behavior change – make it obvious, make it attractive, make it easy, and make it satisfying
  • There are 3 layers of changing habits – changing outcomes, changing process, changing identity

As for me, I’m a huge believer in philosophy of “making tiny changes, for big results” and James Clear’s ideas made a lot of sense to me. I would 100% recommend this book to almost anyone, who wants to change their life without feeling overwhelmed.

“If you can get 1% better each day for one year, you’ll end up 37 times better by the time you’re done.”

Make Your Bed

Make Your Bed is a book based on General McRaven’s commencement speech in 2014 at University of Texas. While the the rules shared in the book are simple, short, clear, and straight forward, what’s captivating are the stories Admiral shares, including the anecdotes from his Navy Seal training that left me in awe. He narrates some key lessons from his life, learned the “hard-way” during seal trainings that almost anyone can apply to face challenges in their life. Also, if you haven’t seen the YouTube video of the speech, you can watch and listen it here. Overall, great stories on military training, coupled with excellent life lessons.

“Start each day with a task completed. Make your bed.”

Tribal Leadership

Tribal Leadership explains the various ways people function within an organization and teaches you how to lead change and improve your company’s culture. This book has an interesting take on social interactions and relationships. The premise is simple, there are 5 stages in which people exist, as follow:

1. Life sucks
2. My life sucks
3. I’m great
4. We’re great
5. Life is great

Overall, it’s great read on leadership. It’s crazy how accurately the 5 stages given in the book, reflect a lot about the companies I have worked. The author also shares practical tips that one can use to create successful teams and when the time comes you’ll know exactly how to motivate them. A must read.

“You don’t have to be in charge or powerful or pretty or most-connected to be a leader. All you need is to be COMMITTED.”

The Phoenix Project

Some people are lucky to find books that change their life. While I’m yet to find my life-changing novel, I do come across books that make me think, question my beliefs and push me to learn. The Project Phoenix is one such book for me.

Written by Gene Kim, George Spafford, and Kevin Behr, the book is about a large company’s transformation into a DevOps culture. Transformation driven not just to look cool, but as a necessity for the survival of the company. The Phoneix project is a gripping read that captures brilliantly the dilemmas faced by the organizations that depend on IT, and offers real-world solutions. The authors reminds us, ‘It is necessary to change for survival.’

“Improving daily work is even more important than doing daily work.”  

The Unicorn Project

The Unicorn Project is a sequel to The Phoenix Project (actually it’s not). Although, the two books fit together on the premise of digital transformation, they aren’t necessarily to be read together. The story this time dives deep into the developer’s world—Maxine, who’s a talented lead developer and architect, blamed for an outage and exiled on the Phoenix project. Throughout her journey, she partners with a team of corporate rebels, and together they confront their legacy and change-averse processes and apply the five ideals to lead a positive and lasting business, technology and cultural transformation. Not that the book is all about developers, debugging, continuous integration or unit tests, but it is very much the focus, at least for the first good half of the book. In the DevOps age, the core development topics were earlier left to developers are now in the center of discussion up to CIOs and sometimes CEOs. Gene Kim’s relatable writing style keeps the pages turning quite easily.

“Like all engineers, she secretly loves hearing disaster stories … as long as she doesn’t have the starring role.”

I must admit, these two books “The Project Phoenix” and “The Unicorn Project” had a profound impact on me during this year. I picked them while being stuck in abrupt travel ban (clearly the lowest point for me in the year). I read over #1000 pages in a week, that’s averaging 150 pages per/day, way above my usual reading rate. Also, these aren’t typical motivational books either, but for some reason, they just helped to stay focused on my work and reminded me, ‘This too shall pass‘.

Software Developer Life

Software Developer Life  is a refreshingly honest and personal book – pretty simple and to the point. This book offers good advice on how to be a good engineer in the real world. Author (David) shared technical and non-technical stories that his friends and he encountered in the past, and through these stories he proves that that only acquiring technical skill is not enough. One also needs to work on non-technical skills, such as collaboration, communication and empathy. He also shares real world tips on learning fundamentals, avoid arrogance, choosing your workplace, handling mid-career crisis and managing your boss. Overall, fun easy read and worth it if you’re considering a field as a software engineer.

“For any field, the people at the highest level are the ones who deeply understand FOUNDATION; that’s why they can break it sometimes.”

the Self-taught programmer

the self-taught programmer is the ideal book for anyone new to programming. I’ve read a few books on self-learn programming including Java & Python, even through with a decade long experience in technology, I would sometimes struggle to wrap my head around the code samples and exercises. Cory (the author) went above and beyond in providing examples throughout all the lessons and their real world application to complement the reading. His technique in breaking down complex technical topics in simple terms that anyone can understand, is what really makes this book shine. I highly recommend this book to anyone wanting to learn to code or looking for a great starter to Python.

“Life is too short to have insecurities about where we got our education. Your passion, curiosity and hard-work is all you need to be successful.”

If you made it this far, bravo! Thanks for reading through my reviews and I can’t wait to see you share what you’ve read. Leave a comment for your favorite books, podcasts, and reading goals for 2021.

So long 2020 😷

The Unicorn Project – Book Review

A Novel about Developers, Digital Disruption, and Thriving in the Age of Data

Over a month ago, I read the book “The Phoenix Project” and published a review on my blog. The book was certainly amazing as it touched on so many important aspects of software development, DevOps and my own IT career. To my surprise, I found that the book also has a sequel The Unicorn Project.

So is it really a Sequel?

Although as per the author, there is absolutely no need to read The Phoenix Project prior reading The Unicorn Project, however based on my understanding of the books characters plot, I would totally recommend reading The Phoenix Project. There’s the same company – Parts Unlimited – same urge to change to survive, same challenges and same project – The Phoenix Project – on which the company is betting its future.


While in The Phoenix Project, the story revolves around Bill Palmer – VP of IT operations, The Unicorn Project, a brand new protagonist, Maxine Chambers – Developer Lead and Architect. Yes, you got it! the story this time deep dives into the developer’s world.

Maxine, is a talented lead developer and architect blamed for an outage and exiled on the Phoenix project. Throughout her journey, she partners with a team of corporate rebels, and together they confront their legacy and change-averse processes and apply the five ideals to lead a positive and lasting business, technology and cultural transformation.

Not that the book is all about developers, debugging, continuous integration or unit tests, but it is very much the focus, at least for the first good half of the book. In the DevOps age, the core development topics were earlier left to developers are now in the center of discussion up to CIOs and sometimes CEOs.

The Five Ideals

While author in The Phoenix Project  came up with “The Three Ways”, in this book he introduces “The Five Ideals” as follows:

  1. First Ideal: Locality and Simplicity

We need to design things so that we have locality in our systems and the organizations that build them. We need simplicity in everything we do, in our code, in our organization or in our processes. E.g. when you need to make a simple change and you need to change 15 files instead of 1, then you are probably violating this ideal. This is also known as the Single Responsibility principle.

  1. Second Ideal: Focus, Flow, and Joy

How does our daily work feel? This means not waiting for other people in order to get things done, get fast and continuous feedback. Also consider the lunch factor (similar to the truck factor): how many people do you have to pay lunch in order to execute a deployment?

  1. Third Ideal: Improvement of Daily Work

The Toyota Andon cord is a good example of this ideal. Sometimes, processes are improved by adding an extra step to the process every time something went wrong. This way a bloated process is created which negatively impacts flow. Often, when suggestions for improvement are made in a team working on a legacy application, the suggestion is killed by saying ‘We have always done it this way’. Of course, this is a non-argument, you must judge the suggested improvement and not express your feelings against change. This ideal is also about reducing technical debt which we discussed already. E.g. The Nokia Symbian builds lasted 48 hours when the iPhone was on the rise (somewhere around 2010). This way it is impossible to have fast feedback and it can have a devastating result for your company.

  1. Fourth Ideal: Psychological Safety

There should be no blaming culture, it should be safe to talk about problems and how to solve them. A culture of fear will make people hiding their mistakes, while a culture of safety will ensure that things will improve.

  1. Fifth Ideal: Customer Focus

Are we working on something the customer is willing to pay for or is this a feature which only will satisfy a functional silo? In other words, we need to focus on customer value.

Data is new currency 💲

Data in The Unicorn Project book, like in real life, takes the front seat. It’s with data that Parts Unlimited can now customize its marketing campaigns, optimize revenues and manage stocks like never before. It’s also with data that the teams operate their applications, make informed decisions on what to focus on and are able to react quickly when things go wrong. We often read that data is largely unused and can unlock immense value. The Unicorn Project gives practical examples of using this data effectively to generate favorable business outcome. Impressive!


Overall the book touches on a lot of different complex topics that are central to any engineering organization. For example, focusing on psychological safety of employees and the positive impact it can have on both a team and organization.

I love Gene’s style of writing that makes the entertaining to read about the struggles of a developer and how she (Maxine) overcomes those. It’s easy to relate to the frustration that comes from a company that wants to but is unable to change.

After reading through the book, I count myself lucky to work for a company that values its team members, their safety and follows a culture of openness & blameless post-mortems (believe me they do!). All in all the book made me reflect in a lot of ways, the same experience as the one I had with The Phoenix Project.

If you’re interested in DevOps, I highly recommend The Unicorn Project

🦄 Let your inner Unicorn shine!

My journey from DBA to DevOps

I’ve been working as a database engineer for over a decade, engineering enterprise data platforms. During the beginning of my career in early 2000, I chose the ‘safe’ path of being a DBA believing that relational systems being universal containers for storing critical data will never change. I started learning relational technologies like Oracle, MS-SQL, and eventually also learned Open Source systems including PostgreSQL & MySQL.

However contrary to my belief, enterprise technology did change a lot. Some things however remained constant like developers swinging by my cube to request a new database, performing DB refresh or tuning  a slow running query (my favorite). Sometimes these teams were frustrated with me when their app went down or when they couldn’t access their database. At times, my Dev and QA friends would come by my desk to learn what I was doing and even after my attempt to explain them how I am solving their production issue, they would walk away puzzled. I have grown up in this role realizing that a when things go wrong, the first one to be blamed is DBA (i.e. Default Blame Acceptor)

This was my life for long and as you might have guessed, it wasn’t very satisfying; professionally 😉

It was a vicious cycle of configuring environments, routine data refreshes, resolving outages, and late-night upgrades. The work which once gave meaning to my career, lately made me ask myself, “Is this it for a DBA?” , “Is it the time to change?”

The journey ahead…

I then started having discussions with my leaders, determined to find an answer to “What’s the future of my role?”.

During these discussions, I heard terms like Agile, Scrum, Continuous Delivery and DevOps. Since the last one was repeated more often than others, I started researching on “Skillset for DevOps”.

Initially I was all excited to learn a new skill set, maybe a new tool, however after multiple days of googling, I couldn’t find any specific Skill Set definition. During a follow-up discussion with my mentor, I learned something interesting,

“Think of DevOps as not a specific skill set, instead it’s a way of doing something.”

Wait, so all it means is Dev and Ops working together, that’s sounds weird! So now I have to learn all languages used by developers…C++, Java, Python…ugh? While I’ve been coding on PowerShell & SQL for infra automation, I never considered myself as a developer. Hmm…maybe that’s what needed to change.

Fast forward – Learning Go

In the past couple of years, there is a rise of a new programming language Go lang (or simply GO). Most developers in their code will have to interact with the database at some point in their project, and often that means working with PostgreSQL. I particularly got interested in learning Go’s integration with PostgreSQL. There are multiple Go libraries that allow Go PostgreSQL integration productive and fun. Excited about my journey and want to share whatever I’ve learned recently…so in the next few posts I’ll blog about PostgreSQL integration with Go.

Disclaimer: By NO means I claim to be a Go expert and I am not going to teach Go lang. There’s a lot of great online courses and material for that. I am only going to share my learnings on Postgres integration with Go.

The Phoenix Project – Book Review

A Novel about IT, DevOps, and Helping Your Business Win

Some people are lucky to find books that changes their life. While I’m yet to find my life-changing novel, I do come across books that make me think, question my beliefs and push me to learn. The Project Phoenix is that book for me.

Written by Gene Kim, George Spafford, and Kevin Behr, the book is about a large company’s transformation into a DevOps culture. Transformation driven not just to look cool, but as a necessity for the survival of the company.

The synopsis is simple. Bill, the protagonist, is the Director of Midrange Operations at Parts Unlimited, a US-based $4 billion per year manufacturing and retail company. Bill is swiftly pulled into the spotlight by the CEO and persuaded hoodwinked into taking up the post as VP of IT Operations. It soon becomes clear that among standard responsibilities, Bill and his team are responsible for making the launch of the risky doomed Project Phoenix a success. Project Phoenix not only seems to be hugely overscoped for its ambitious – and imminent – timelines, but it also faces enormous pressure elsewhere.

The characters and situations in the book are stereotypical, however that’s not a criticism. The intent is clearly for us to identify with the characters and events, to relate your workplace with the story . So here are my key learnings “spoiler-free

DevOps is a collaborative working relationship between Development and IT Operations 🤝

Outcome of this collaboration is fast flow of planned work, while increasing the reliability, stability of the production environment.

3️ Ways principle 📜

The First way – focuses on maximizing flow of work from left-to-right starting from business to development to IT operations to the end user.

The Second way – focuses on increasing the feedback loop from right to left. The focus is not only on getting feedback but also on how fast we can get the feedback in order to make necessary corrections/improvement quickly.

The Third way – The third way is all about developing and fostering a culture of continuous experimentation and learning.

Speed to Deliver is the key 🚀

Technology is life blood of all business today. It’s imperative that all business should strive to bring their applications to market more quickly so they don’t miss any opportunities and easily adjust to the market standards. To achieve these objectives, organizations must adopt the right DevOps practices in their software development processes to reduce time to market.

Overall, book does a great job at explaining all these ideas with examples and linking them together. It’s a super fun and easy read, and I would definitely recommend you.

Site Reliability Engineering: How Google Runs Production Systems – Book Review

Essential Read for anyone managing highly available distributed systems at scale

First off – It’s worth let you know that Google lets you read this “entire” book online for free on their website. Yes you read it right, you don’t need to buy the book, just click on below link – https://landing.google.com/sre/sre-book/toc/index.html and start reading!

The book starts with a story about a time Margaret Hamilton brought her young daughter with her to NASA, back in the days of the Apollo program. During a simulation mission, her daughter caused the mission to crash by pressing some keys accidentally. Hamilton noticed this defect and proactively submitted a change to add error checking code to prevent this from happening again, however the change was rejected because program leadership believed that error should never happen. On the next mission, Apollo 8, that exact error condition occurred and a potentially fatal problem that could have been prevented with a trivial check took NASA’s engineers 9 hours to resolve. Hence early learning from book

“Embrace the idea that systems failures are inevitable, and therefore teams should work to optimize to recover quickly through using SRE principles.”

The book is divided into four parts, each comprised of several sections. Each section is authored by a Google engineer.

In Part I, Introduction, the authors introduce Google’s Site Reliability Engineering (SRE) approach to managing global-scale IT services running in datacenters spread across the entire world. (Google approach is truly extraordinary) After a discussion about how SRE is different from DevOps (another hot term of the day), this part introduces the core elements and requirements of SRE, which include the traditional Service Level Objectives (SLOs) and Service Level Agreements (SLAs), management of changing services and requirements, demand forecasting and capacity, provisioning and allocation, etc. Through a sample service, Shakespeare, the authors introduce the core concepts of running a workflow, which is essentially a collection of IT tasks that have inter-dependencies, in the datacenter.

In Part II, Principles, the book focuses on operational and reliability risks, SLO and SLA management, the notion of toil (mundane work that scales linearly, and can be automated) and the need to eliminate it (through automation), how to monitor the complex system that is a datacenter, a process for automation as seen at Google, the notion of engineering releases, and, last, an essay on the need for simplicity . This rather disparate collection of notions is very useful, explained for the laymen but still with enough technical content to be interesting even for the expert (practitioner or academic).

In Parts III and IV, Practices and Management, respectively, the book discusses a variety of topics, from time-series analysis for anomaly detection, to the practice and management of people on-call, to various ways to prevent and address incidents occurring in the datacenter, to postmortems and root-cause analysis that could help prevent future disasters, to testing for reliability (a notoriously difficult issue), to software engineering the SRE team, to load-balancing and overload management (resource management and scheduling 101), communication between SRE engineers, etc. etc. etc., until the predictable call for everyone to use SRE as early as possible and as often as possible. This is where I started getting a much better sense of practical SRE (a.ha!)

Overall it’s a great read, however it isn’t perfect. The two big downsides for me are 1.) this is one of those books that’s a collection of chapters by different people, so there’s a fair amount of redundancy and 2.) the book takes a sided approach on “Build Vs Buy” dilemma of engineering. I mean at Google scale, it will always be better to build, however that is rarely true in the real world. But even including the downsides, I’d say that this is the most valuable technical book I’ve read in the year. If you really like these notes, you’ll probably want to read the full book.