This is my attempt at an introduction to a blog…
Readers will be able to use this introduction to get a better understanding of me, where I come from and my take on my career thus far. I will use this blog as an extension of my CV and showcase my professional background, my journey to be a cloud expert, and possibly as a place where I can post my opinion on certain topics that I find interesting.
My journey started as a very inexperienced field technician for a small point of sale company. Yip, point-of-sale… I had to deal with slip printers, machines and networking equipment exposed to terrible kitchen environments and angry restaurant managers. But, I learned a lot. I learned the dynamics of the professional IT world, after-hours support, building a call center, and managing a team. A few months before I started there, I finished a diploma in Information Technologies, where I focussed on computer development and specialising in web and e-commerce. So why did I take a job as an on-the-road support tech? Well, the simple answer, bills needed to be paid, and the point of sale company developed their software in-house. The company had opportunities for a very inexperienced professional like me, which I decided to make use of. With some hard work and determination, I could be on my way to be a programmer, at least that's what I thought at that stage.
Jump forward a couple of months and I have mastered the software packages that the company develops, I'm leading larger projects and getting assigned tasks that are not as straight-forward as your normal cut-and-paste restaurant/hotel/bar installation that we normally do. I have gained the trust of the dev-guys to a point where they asked me to assist with testing new versions of the software. My programming background (at least my qualifications and no professional experience yet) has started to count in my favour. I moved from installation and support technician to in-house software tester and coordinator. Still not a coder, but we're moving forward. I learned a lot about development cycles, integrations to 3rd party systems, version control, refactoring, and all the other cool terms that coders talk about. This was before CI/CD became what it is today. Part of my day-to-day was also infrastructure support, and I found this very interesting. This was the only real hands-on technical and configuration work that was on my list of responsibilities. I decided to expand my skillset and looked at certifications I could complete that might get my foot in the door at another company. After weeks of research, I decided to do my CCNA. I bought the course material, studied at night, built labs, broke the labs, and rebuilt them a few times. I took some personal leave to study a bit more. Five months after deciding to pursue it, I passed my CCNA exam. I started looking for other opportunities, and I moved on. As fun as they were, my days working on point of sale software were over.
Very happy to be moving onto new horizons, I took a job as a Wifi engineer, with opportunities to move into a routing and switching role. My newly acquired networking skills and certification will surely be the skills I use daily right? Just a bit of foreshadowing… I'm still not a specialised network engineer per se. My networking certs definitely help me, even today, but I did not become a network engineer, just like that.
In the Wifi team, we had to perform Wifi surveys of malls, hospitals, airports, and casinos. This basically means, walking around with a floor plan of the building, and mapping out where to place access points to optimise wifi coverage throughout the venue. These were all large sites and resulted in A LOT of documentation. After the second 200 page document that I handed in, I started looking at ways to automate it. I just couldn't understand that this should take up so much of my time. I built a Word template and Excel macro that imported all the photos of the Wifi access points with their coordinate variables (yip the end-customer was sticky about these variables), populated the Word template and exported it as a PDF. This was my first piece of real automation, and how to programmatically take care of mundane tasks. I was hooked… I started sharing my macro with teammates, and due to the nature of the repetitive tasks, this thing spread like wildfire. Managers in the organisation took notice of my scripting skills and, 6 months after joining the Wifi team, I was moved over to the Broadband team. Look out for an upcoming post: “End Result = Automate” where I'll discuss more on why it's important to have the basic knowledge of development.
Just as I found my feet in one department and technology stack, that metaphorical carpet of comfort was ripped from underneath my feet, and I fell face-first into the world of DPI (Deep Packet Inspection), diameter protocols, revenue leakage, mobile networks, and content caching. We worked with mobile providers with a subscriber base of 1.4 million, of which 90% were pre-paid (pay as you go) customers. This brought its own set of headaches. By this time I had come to the conclusion: Throughout my professional career I will be assigned tasks or projects and there's no guarantee that I will know anything about the technology that I have to implement, but I will have to skill up and skill up quickly. The only constant in technology as a profession is, change, and with change comes learning.
The reason for my move from Wifi to Broadband quickly became apparent; the type of work in the Broadband team requires logical and flow-based thinking. Most of the projects were ‘greenfields’, no-one-in-the-company-has-done-this-before type of projects. Without knowing what the diameter protocol is, or having a full understanding of the role of a PCEF (Policy Charging Enforcement Function) solution in a mobile network, and no experience in this field what-so-ever, I was flown to another country to be the so-called subject matter expert of a migration from one OCS (Online Charging System) vendor to another. The project was a massive success, and I am proud to have assisted the customer in launching ‘byte-sized’ bolt-on packages in one of the largest mobile providers in sub-Saharan Africa. I learned that this was the type of company we were; throw the engineer in the deep-end and hope he swims… for me, a young and hungry to learn, engineer… I have found my home.
Up until now, I haven't spoken much about the cloud. That's because, in my opinion, I'm inexperienced in this whole cloud business.
I'm still at the same company but have recently been tasked to get a Cloud Architecture team off the ground. We have targets, and expectations have been set. We have to find customers, we have to solve their problems, and we have to select the right products to do so.
I'm once again starting at the bottom (relatively speaking), in a field that I know very little about. But by writing this post, I've realised how far I've come and I take every little piece of experience with me. I understand software development processes. I understand that being ‘lazy’, and finding shortcuts with code can work in your favour. I have discovered that breaking a lab and trying to fix it is the best way to learn something new, so don't be scared to break things. I can probably write a whole stack of whitepapers on my experience in mobile networks and how subscribers will tirelessly try to circumvent enforcement policies in the data-plane. I know that customers have problems, they want solutions to those problems, and they don't necessarily care about the underlying technology. I understand that the IT world is ever-changing, and expanding, and you have to keep up.