Network Automation Optimism Ages Into Lighthouse Keeper Despair

Level 1: The Robot Toothbrush

Imagine deciding to build a robot to brush your teeth, because brushing is boring. Brushing takes two minutes. Building the robot takes months: the arm misses your mouth, the toothpaste squirts the mirror, and every toothbrush you buy is a slightly different shape, so the robot keeps breaking. The happy person on the left just decided to build the robot. The exhausted sea captain on the right has been building it so long he's grown a beard — and he still says "almost done!" It's funny because we all keep choosing the robot.

Level 2: Why "Just One Command" Isn't

A switch is the box that connects computers in a network; engineers manage it through a CLI (command-line interface) over SSH, a secure remote-terminal protocol. A show command (like show version or show interface) just displays information — it changes nothing, which makes it the natural first target for automation.

Network automation means writing code (usually Python or Ansible playbooks) that talks to devices for you, so checking 200 switches doesn't mean 200 manual logins. The catch is parsing: the device replies with formatted text meant for human eyes, and your program has to slice that text apart to extract values. That's where the hundreds of lines go — handling every weird variation the device might print.

The early-career arc is exactly the meme's arc. Week one: you write ten lines, they work on the lab switch, you feel like a wizard. Week three: production has four vendors, six firmware versions, and one switch that answers in a slightly different column layout, and you're now maintaining a small software project to avoid typing one command. This is yak shaving — solving nested sub-problems so you can solve the original one — and every infrastructure engineer goes through it.

Level 3: Screen-Scraping the Kraken

The two Willem Dafoes tell the entire lifecycle of a NetDevOps initiative. On the left, sunlit and color-graded, the tracksuit-and-red-beanie Dafoe crouches by the harbor: "I love network automation!" On the right, the salt-crusted lighthouse keeper from The Lighthouse stares through you in black and white: "Just three hundred more lines of code and this show command for one switch will be fully automated." The transformation isn't a career; it's one ticket.

Anyone who has actually tried to automate network gear knows why the timeline between panels is so brutal. Network devices were designed for humans typing at terminals, not programs. The classic workflow is CLI screen-scraping: open an SSH session with a library like netmiko or paramiko, send show interface status, and then parse the response — a wall of whitespace-aligned text whose format the vendor never promised to keep stable. So you write regexes. Then you discover the output differs between IOS and NX-OS, between firmware 15.2 and 17.3, between a 24-port and 48-port chassis. Then pagination kicks in (--More--), the terminal width truncates a column, a port description contains the delimiter character, and your "quick script" sprouts retry logic, timeouts, credential handling, and a TextFSM template library. Three hundred more lines. Always three hundred more.

The deeper satire is the automation paradox: the meme's task is a read-only show command on one switch — the single safest, most trivial operation in networking — and it still spirals. The industry's answer (model-driven APIs like NETCONF/RESTCONF and YANG, vendor SDKs, Ansible network modules) exists precisely because of this pain, yet the install base of legacy gear guarantees screen-scraping for another decade. Meanwhile the engineer can't justify the time to management, because the manual version takes eleven seconds. The XKCD-style math never closes — but that was never really the point. The point is the principle, the learning, and the slow metamorphosis into a bearded keeper of one eternally flickering light: the cron job that runs the script that no one else dares touch.