By Victor Kuarsingh
Introduction – The Shift Beyond Building and Administration
For decades, network was largely anchored to an administrator’s perspective: building, configuring, crafting and maintaining systems with the mindset getting to runtime and keeping the lights on. This approach solved immediate problems effectively, but it also constrained networking to incremental change and reliance on humans for many operations even if some automation was present. Today’s landscape that includes cloud, automation, distributed systems, edge computing and complex security; demands a substantive change in how we build systems. The future of networking is no longer about administering devices; it is about engineering solutions at the software layer, with networking as one of several domains in play.
Lessons From Past Practice – Why the Old Model No Longer Fits
Traditional approaches relied on command-line mastery and vendor-specific skills. These were critical in the 1990s and 2000s, but they locked engineers into reactive modes of work: troubleshooting configurations, responding to outages, or scaling networks by manual effort. Basic building and management of networks can be argued to be a “solved problem” insomuch that there is an abundance of operational techniques and tactics known by our industry to deal with them —protocols, routing methods, and device management frameworks exist that address the common cases. What remains unsolved are the problems of scale, velocity, and flexibility in the face of continuous change. These are not CLI problems; they are systems design problems.
Innovation by Inquiry – The Engineer as an Explorer
To move forward, network engineering needs the same culture of inquiry that drives innovation elsewhere. Extrapolated lessons from my post on Innovation by Inquiry, the emphasis should be on asking questions that reframe the problem space. So questions like – Why is this process manual? How could it be automated? What would a system look like if it were designed as code from the ground up? – are great ways to frame how to apply innovation to a problem. This mindset turns engineers from operators into explorers, willing to experiment, fail, and iterate. Software engineering brings the tooling—automation frameworks, APIs, CI/CD pipelines—but inquiry provides the compass to ensure those tools are used to solve meaningful problems.
The Case for Network Engineers as Software Engineers
The emerging reality is that network engineers must become software engineers who also understand networking. Not the other way around. Writing infrastructure as code, modeling traffic flows as software artifacts, and integrating with service-based architectures are now table stakes. A software-first engineer can scale networking far beyond what was possible with administrator-centric practices. They can build abstractions, enforce policy through automation, and design resilient systems that are tested, versioned, and repeatable—just like any modern application. Networking knowledge remains essential, but it is no longer sufficient on its own.
Shifts We’ve Made Before – Reinvention Is the Norm
This isn’t the first time networking has reinvented itself. In the 1980s, networking often emerged from system administrators wiring together early LANs with technologies like Ethernet (IEEE 802.3), ARCNET, Token Ring, etc – solving the basic problem of how to connect PCs and share resources. By the 1990s, the explosion of the Internet demanded new thinking about the physical and routing layers. Vendors like Cisco and Juniper built high-capacity routers to support the first backbone networks, while advances such as fiber optics and DWDM (Dense Wavelength Division Multiplexing) reshaped how bandwidth could scale displacing early SONET and ATM technoloiges. Entering the 2000s and 2010s, the challenge shifted again: distributing and accelerating content. Content Delivery Networks (Akamai, Limelight), broadband build-outs, and global peering fundamentally changed how information was delivered. Each stage forced a leap away from past practice.
Today, the limiting factor is not physical speed but complexity—interconnected systems, microservices, cloud-native architectures, and global scale. Managing that complexity requires more than manual configuration or incremental improvements. It requires software: abstractions to tame complexity, automation to eliminate toil, and orchestration to ensure resilience. Just as we rethought wiring in the ’80s, backbone scale in the ’90s, and content distribution in the 2000s, we must now rethink networking through a software-first lens.
Forward-Looking Examples – Signs of the Next Shift
The industry is already showing us where this evolution is heading. Hyperscalers such as Google, AWS, and Microsoft have moved to intent-based, API-driven network models, where engineers declare desired outcomes and automation systems translate that into actual network states. Emerging 5G and edge networks rely heavily on network slicing and service orchestration, concepts that cannot exist without a software-first approach. These examples prove that the shift isn’t theoretical—it is already happening, and it rewards those who can think in code while understanding the fabric of connectivity underneath.
The unique challenge
The challenge—one somewhat unique to this space—is how to encourage a larger segment of networking innovators to adopt and excel at software-based approaches to solving problems, while still maintaining deep proficiency in foundational networking concepts. Developing such a polymathic, interdisciplinary skill set is difficult; this transition will be challenging to both foster and sustain. It takes years to become proficient in networking, and likewise to master the craft of building reliable software—yet our industry must rise to meet this dual expectation.
In many ways, this moment feels like a return to our roots. During the mid-to-late 20th century, it was computer scientists who designed many of the the early networks and the protocols that made them function. Perhaps it’s time to rekindle that spirit—to begin again with a software-first mindset.
Structuring the Future Differently
The shift is not optional. If we keep structuring solutions as administrators, we will keep solving yesterday’s problems. To address tomorrow’s, we must structure solutions fundamentally differently—through code, inquiry, and engineering discipline. This is not just about personal skills, but about reshaping the culture of networking teams to value experimentation, automation, and systems thinking. As with any transformation, the leaders who thrive will be those who combine the technical fluency of software with the critical inquiry of innovators, shaping networking into a platform for the next era of digital infrastructure.
Victor K's Stream of consciousness 