Published: August 23, 2020
When it comes to DevOps, I believe there is like two books. That proved to be quite beneficial & inspiration that feels like the holy bible level in the DevOps world which is The Phoenix Project & The DevOps Handbook
The first narrates a story about transformation for the IT department. From a traditional cost centre to value creation business unit. Much like how AWS was the brainchild of Amazon's IT infrastructure. Which developers or startups rely on it daily to build products or services on top of AWS.
The other book The DevOps Handbook was talking about the success stories, methodologies, philosophy and case studies. On how various companies or organisations have transformed their companies. By adopting DevOps philosophy or culture as part of their organisation. Which has nothing to do with any new fancy tools.
So if you had read till this portion of the article and you take DevOps seriously. You can get those two books for your library. But wait there's more, if you want to know why I feel it matters for every developer to read it. Please do carry on I would tell you why.
I won't be spoiling you on the book in the nitty-gritty part of it. To be honest, when I was reading the first 20% of the book. I was having memories of what I learnt for IT service managment classes in school. Yes, I was not trained as a developer but as a computer networking professional & IT technician. Who creates computer networks, managing computers & servers as well as repairing these computers.
It even brings back bad memories during my internship. Which I was attached to in a managed services department of a local telecommunications company. Who is handling the IT operations of an Australia bank.
I gain exposure to the world of IT operation and service management on their use cases and terminology for it. For this book, it came with a twist. Which is sending you down to a dumpster fire. Like a typical story that uses the The Hero's Journey. This is important as it lays the foundation for you to apply it.
In the book, it shows the reader about the process of the transformation from traditional IT operations. That is commonly viewed as a cost centre and a means to the end to the business. Which morphs into a value creator besides just covering the bottom line. It covers in detail on the type of value on a strategic level. Through a series of probing questions of the users or people by each character. To figure out the importance of delivering value. Who are using the software to solve their problems or pain point they encounter daily.
Therefore we should frame it in the way, the users can understand how we provide value to solve their problem. Instead of just being a stepping stone. As a means to end in delivering the products or services to the customers. This is hugely neglected by our developers. If there is no established direct feedback channel from the customers.
Unless you are a customer service, who talks to the users or people who uses your products or services. This is the same concept that we should present as developers as a story to solve their painful problem. When we are talking to people. Who would be using our software as a service or product to solve their problem.
As you dive deeper into the book, there won't be much mentioning of the tools being using. Instead, there are scenarios where principles, practices or process has to be established or adopted. So that anyone can operate and solve problems or situations on the spot. By leveraging upon past experiences to improve the effectiveness & efficiency of their operations.
Which hopefully for your case, there will not be a single person hoarding all the information or knowledge. Who is treated as a goto firefighter for all fires without writing down how it is done. So others can learn from the experience. As firefighting is not the person's main job. If it is on a daily basis, there is something seriously wrong with your organisation.
While firefighting can be glorious but highly ineffective in the use of our time. We could have spent more thought in applying infinite game thinking & documenting the firefights we had. To focus on prevention & risk avoidance through practices we adopt. Setting up the processes or writing down the firefighting experience. Which reduces or prevent the repeat of the same situation happening again.
I hope that I could convince you to read the book on The Phoenix Project as it provides you digestible way. For you to understand & apply it to software development. Before you think about adopting tools like Docker, Selenium & Puppet for a smooth deployment & delivery for the users to use it. This allows you to think on a strategical level. Regardless of your job title, within the organisation.
Personally, I had encountered many real-life situations. Which is vaguely similar to what the characters in the book had done. Like an ex-colleague, who does not deploy use shell scripts to deploy on either testing & production server.
AS the person thinks that the person will not remember or how to fix it when problems occur in the deployment process. Which makes me remember a particular character of the book. Who was a firefighter in the book that does not document their situation after each fire has been exhuasted.
Lastly, are you looking to specialise yourself as a developer? If it's a Yes. I'm giving away my free ebook called "Picking Your Specialisation as a Developer" for anyone interested to command a higher salary or do the work that you like.
This post includes affiliate links, I may receive compensation if you purchase products or services from the different links provided in this article.