I have recently changed jobs and the whole experience has made me take a step back and take a look at where I have come from. What roads did I have to cross to get here. My current position is working with various business units of a large company to adopt a DevOps culture. For the past nine years I have been working as a consultant helping clients to achieve a better DevOps experience around TFS and then Azure DevOps. Today I am in an environment that is not centered around Microsoft tooling, there are some products that they build that are but this is a very minor number compared to the other technology that is going on here. There is a bit of a learning curve for me as far as the technology goes, but the basic concepts of a DevOps culture are the same and that is what I will bring to the table and as far as the different tools go, I am really ready for some new challenges.

A Little History

How did I get here and what makes me qualified to bring a DevOps culture to a large organization. First in case you don’t know I think we should define what DevOps really is. DevOps is really the coming together of Development and Operations to bring value to the end user. I have spent the majority of my time in the tech spectrum on the development side of the house. What’s interesting about this fact is that my training in college was more operations based and specifically more in the area of networks. In order to understand how this came about we need to step back to the late 1980’s where I was working as an accountant in the family owned business and I was looking for software that would make my life easier. The problem with software in the late 80’s was that they were designed by computer scientist’s that were not accountants. Back then you were expected to simulate the work that was done by entering it in the computer. I wanted a cheap system that could capture this data at the moment the transaction occured. Today, that is how computer systems work, but back then they did not as I could not find anything that would work this way.

However, I did find some source code that was written in dBase III and was supposed to be Clipper ready. Clipper was a dbase like language that could compile the dbase code into a self running executable. Sorry to say that the code I purchased just would not compile. I had a CompuServe account and I found a Clipper User Group online where I would explain my errors and they would give me ideas that I could try to get past them. This went on for about 2 months, but I finally got it to work and this really saved me a lot of time and was my initial introduction to programing. I went on to learn a number of other languages through some correspondance courses and eventually went back to college to start a new career in technology.

Now the time is 1992 and I made a prediction that there wasn’t much of a future in programing. This all looked pretty easy and they were talking about building applications without any programming. As we all know now, they have tried to do that since the days of Cobol which was supposed to be a language that even a Business Analysis should be able to write a requirement and it would turn into working code.

In around 1992 people were just becoming aware that there was an internet out there and they were going to want to get connected to it. So I went to a college that specialized in an overall desktop personal computer with a lot of focus on networks, Novell to be specific. At the time Novell was the king in this space and then almost lost it all a few years later.

Business, big help in Development

During my time as a developer one skill that was very useful was the fact that I did not come from technology originally, I came from business. I worked as an accountant for about 13 years before I switched over to technology. When I was in college I realized then already how much of an advantage I had from the younger students because for them this was the next step out of high school. They had no other skills or backgrounds and the thing we all know about computers is that they simulate life. Something I often told my clients as a consultant if you have a bad process or workflow, setting it up onto a computer no matter how clever the tool, your life will get worse. If you process is good, then tooling can make it even better.

I worked in a number of different verticals writing programs and these programs were all line of business applications. It really helped that I understood business and especially the recording of records aspect of it. During all this I realized how wrong I was about the future of programming and often thought if I would have known that I would have made other choices for college that were better for progamming and software development. However, there were moments when even operations people who got to know me understood that I also had some understanding about how networks worked more so than the typical developer.

DevOps in my new Position

DevOps is the bringing together of these two important parts of the application life cycle. Developers are creating the new value for the customers and operations delivers it. Having a foot in each of these areas is helpful and I may not have jumped into a change like this if I did not already feel somewhat comfortable in the operations side of the field. It just shows you that all the choices and experiences that we have along the way help to form us who we are and what we can become. I did go to the right college and I did study the right thing.