"The Phoenix Project" Must Read For Developers
Tags: books, devops, startup, career
Published: 2020-08-23 10:35:29

The original post was on ["The Phoenix Project" Must Read For Developers - Reading Time: 4 Mins](https://www.maxongzb.com/the-phoenix-project-must-read-for-developers-reading-time-4-mins/) and cover image by [Lenny Kuhne on Unsplash](https://unsplash.com/photos/jHZ70nRk7Ns)


# Introduction
![undraw mello otq1](//images.ctfassets.net/ly2f59p4unnn/3dV9leWWQia80Cw31WSlLm/18430b49cb28634b8db664101e19cd61/undraw_mello_otq1.png)

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](https://amzn.to/2Qf7pw3) & [The DevOps Handbook](https://amzn.to/3aTgXpR)

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](https://amzn.to/3aTgXpR) 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. 

# Understanding the Language of IT Operations & Lean Methodology
![undraw dev productivity umsq](//images.ctfassets.net/ly2f59p4unnn/6gNcHp9BcShHkKW3nfOBMg/a9ef11621dd65d94319e30cd10148f48/undraw_dev_productivity_umsq.png)

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](https://freshservice.com/itsm) 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](https://www.bmc.com/blogs/what-is-a-managed-service-managed-services-explained/) 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](https://blog.reedsy.com/heros-journey/). This is important as it lays the foundation for you to apply it.

# Justifying Value for What You Do in the Eyes of The Users
![undraw our solution htvp](//images.ctfassets.net/ly2f59p4unnn/6pOJ5VDBqwxB1IEJddsxsr/b67b90ed44c8dcd5609ec81fdac22096/undraw_our_solution_htvp.png)

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.

# DevOps is Not About Tools but Philosophy, Principles or Practices
![undraw working out 6psf](//images.ctfassets.net/ly2f59p4unnn/3zifaEkSeEjPD5PYNmUui6/ee94cbd3d126aef6bb2ee97d5d61cbef/undraw_working_out_6psf.png)

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](https://amzn.to/3j7eFX0) & [documenting](https://www.mindtools.com/pages/article/newPPM_73.htm) 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.

# Conclusion
![undraw operating system 4lr6](//images.ctfassets.net/ly2f59p4unnn/4ndEVIQwDo56bzaUwYDogZ/c01f5e10b2801c05655eec9dddda0abc/undraw_operating_system_4lr6.png)

I hope that I could convince you to read the book on [The Phoenix Project](https://amzn.to/2Qf7pw3) 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"](https://maxongzb.activehosted.com/f/5) 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.

# Reference
* [The Phoenix Project](https://amzn.to/2Qf7pw3) 
* [The DevOps Handbook](https://amzn.to/3aTgXpR)
* [IT Service managment](https://freshservice.com/itsm)
* [Managed Services](https://www.bmc.com/blogs/what-is-a-managed-service-managed-services-explained/)
* [The Hero's Journey](https://blog.reedsy.com/heros-journey/)
* [The Infinite Game](https://amzn.to/3j7eFX0)
* [After Action Review (AAR)](https://www.mindtools.com/pages/article/newPPM_73.htm)
* [The Toyota Way](https://amzn.to/2Eq6OF2)
* [Undraw](https://undraw.co/illustrations)