Scripting the Network | I build things

I didn’t originally learn Python because I wanted to be a software developer. I learned it because I was tired of doing the same thing over and over again.

Working in network engineering, there’s a point where scale starts to hurt. Making a change to one device is straightforward. Making that same change across fifty, or a hundred, or more — consistently, safely, and within a change window — is something else entirely.

You can do it manually. But you probably shouldn’t. Python became the way out of that.

Running from a Linux host — the same place I was hosting Nagios — I started building scripts that could connect to network devices using SNMP and CLI access, apply changes, and move on to the next. Anything I could do in a terminal on a Cisco device, I could script. It just took a bit of patience and lots of practice. Luckily, at this stage of my networking career, I had been collecting discarded, but working, network devices along the way, so I had a pretty big fleet of my own to test these scripts on. Of course, no amount of testing, trying and lab work is the same as a real live production network. So my first scripted changes were small by design.

Some of the changes were simple. Small configuration tweaks, repeated across an estate. Others were more involved — coordinated updates that needed to be applied cleanly, in order, and without drift between devices. The scripts didn’t make the changes smaller. They made them consistent.

The CAB

There was an unexpected side-effect. Change Advisory Board (CAB) approvals got easier. Normally, a large network change would be presented as a sprawling set of device-specific configurations. Spreadsheets, tabs, walls of text — technically correct, but difficult to follow unless you already understood what you were looking at.

With Python, the same change became a single script. One file. One flow. One representation of intent. I still documented every affected device, but the shape of the change was different. For a non-technical audience, that mattered.

The risk hadn’t changed.
The scope hadn’t changed.
But the perception had.

It was easier to explain, easier to reason about, easier to approve.

From my side, it was also easier to execute.

No tabbing between sessions.
No copy-paste drift.
No wondering if I’d missed something halfway through a long list.

Just a controlled, repeatable process. Looking back, this wasn’t really about automation in the modern sense. There were no pipelines, no frameworks, no orchestration layers. Just scripts and some of those early scripts were pretty terrible. But those scripts changed how I worked.