A short introduction
I started my career in IT in 2008 on a service desk. Back then, networking felt very tangible. You logged in, made a change, verified it, moved on to the next ticket. It was manual, repetitive, and for a long time, that was simply how things were done.
Over the years, the scale changed. Networks grew larger, more complex, and more critical. The number of changes increased, but the time and attention available did not. That was the moment when doing things “the old way” stopped being sustainable.
The launch of my automation journey
At the time, I was working for a large telecom provider. My days were filled with changes: firewall rules, security updates, and network adjustments, all running in parallel and all expected to be flawless. In practice, I was wearing two hats at once. Part IT administrator, part IT engineer. Designing and troubleshooting on one side, while drowning in repetitive administrative work on the other.
Every change followed the same pattern. Open an Excel sheet, look up a ticket number, copy data from one portal into another, fill in mandatory fields, write an update, and finally paste IP addresses into a CLI or click through a GUI. It’s manageable for a few days, maybe even a week. But when you’re doing twenty or more of these changes every single day, the work stops being engineering and turns into a game of avoiding mistakes.
That was the moment something felt off. I started asking myself a simple question: why am I spending so much time on work that a computer is far better suited to do?
I already knew a bit of Bash and Python, so I started experimenting. Small scripts at first. No AI assistants, no auto-complete magic. Just trial, error, reading documentation, breaking things, and fixing them again. Slow at times, sometimes frustrating, but very real learning.
And it worked!
Changes became faster, errors dropped, and most importantly, I got time back. Time to focus on real projects, design, and thinking instead of copying and pasting. That was the point where automation stopped being an experiment and started becoming a necessity.
Why I’m writing this blog
There are a few reasons why I decided to start this blog. First, I want to document my journey over the coming years, both for myself and for anyone who might find value in reading along. Writing helps me slow down, reflect, and make sense of what I’m learning as I go.
During my career, someone once told me “you learn best when you teach.” That idea stuck with me. Explaining concepts to others forces you to truly understand them, not just make them work once.
Through this blog, I’ll explore topics related to network infrastructure and automation, such as Network as Code, vendor-agnostic design, tooling, and real-world lessons learned, including the mistakes. Nothing polished, nothing perfect, just practical experience shared along the way.
An ongoing journey
I don’t see automation as a destination. It’s an ongoing process of refinement, learning, and sometimes unlearning.
If something I write here helps you think differently, avoid a mistake, or feel less alone in your own journey, then this blog has already done its job.
More to come soon ⚡