Renewed Focus on DevOps

I would say the last couple of years, I haven’t had as much of an interest or focus on DevOps. I discovered the DevOps movement back in 2010, and it quickly developed into a focus and something that captivated me. The idea that building a culture where everyone is looking out for each other and streamlining processes with automation to deliver value quickly seemed revolutionary to me. Now I was early in my career at that point, and that pursuit provided a lot of drive. In 2018, I started to struggle with presentations and conversations on the topic. I think I reached burn out and I was growing frustrated with the same discussions concerning its effectiveness.

After taking a two-year break avoiding presentations and a lot of conversations about the topic, I feel renewed. I am ready to start focusing on it again, helping others build confidence, and finding success in applying the culture and techniques that drive the DevOps mindset’s adoption. It’s interesting to realize that it still isn’t a mainstream concept. Even with all the outstanding research in the area, the resistance to the adoption is astonishing. Many have found it easy to focus on specific tools, not the problems that those tools solve. The issues and the culture around those problems are what DevOps is all about, not the particular tooling. I don’t think anyone says that the tools are not useful or even essential; they are just concrete to the problems being solved.

The State of DevOps Report research has shown that these techniques can be applied regardless of environments and business type. I think what many miss that the solutions will look wildly different because of those two things. I genuinely believe that many DevOps practices can be applied to mainframes, financial industries, medical, etc. The physical solutions will be different since some tools may not be approved in those environments or even available. I feel that we see this all the time in software development too. We think that the design pattern, architecture, framework, or language is the solution and the answer. I don’t really feel any of those are the solutions to the problems we are trying to solve. I am not saying they are not useful tools or things to consider; it just isn’t the end. We are mostly creating software/solutions for users, not for the sake of using a tool, framework, pattern, or language. I personally know that every time I have gone down that sort of path, it ended up causing more issues.

I had realized that when I first started this career, I focused on delivering outcomes for my customers. That is why I even ended up programming; creating a tool for someone that saved them hours a day or just improved their life at work was enough. Somewhere along the way, I started focusing on the things that didn’t really fall into either of those categories. I started looking for silver bullets instead of just using whatever I had at my disposal. That is when I think that I started losing interest. I am glad to say that I am starting to get that feeling back. That we have all of these tools at our fingertips that we can leverage to save time or improve the quality of life for people. I personally think those are the two most important goals when it comes to this field. My focus will be on how to deliver those things, and I will let the rest be an implementation detail. Tools come and go, helping people lasts.

Thanks for reading,

Jamie

If you enjoy the content, then consider buying me a coffee.