dasseclab.net

Network engineering with security in mind.

View on GitHub
6 June 2026

So You Wanna Be A Network Engineer in 2025 (And Beyond)

by dasseclab

I noted in an earlier post that I spend a lot of time on Reddit’s IT Career Questions subreddit (forum). One of the frequent questions there is about the viability of a career in network engineering, usually sparked by some think-piece about how The Cloud is going to decimate the field and make network engineers redundant (2026 update: Clouds couldn’t kill us, AI will, allegedly). I figured I would write up something to show that networking, as a discipline with in Information Technology, is not going away and solid network engineering roles are still going to be around but that there are changes that folks will need to make to pivot into or continue on the path. Admittedly, this is based a lot on personal experience from places I’ve worked, other engineers I have interacted with, places I have interviewed and other things I have read but this is hardly a scientific study by any stretch.

So let’s get that bias out of the way. I’ve worked for the last decade in a couple of high tech companies (see CV), the last bit as network engineers but also touching various network segments in the last couple of roles and many previous roles. Until joining my current company, I was, intermittently, interviewing over the last several years at other high tech companies - some are names you may know, some you might have to remember who they are - but I am also very interested in Internet-level networking, so some places I’ve been looking at and talking to are in the service provider space and range from global to regional. Individual milage may vary but this is general advice based on what I’ve seen and experienced.

I also started drafting this in very late 2024 or early 2025. It’s now the middle of 2026 and rather than completely re-edit the whole thing, I’m leaving a bunch as-is and adding, subtracting and editing where needed. It will hopefully, come out clear.

What Do People Think Network Engineers Do?

Most people, if they can conjure up an idea of what these often cranky, caffeine addled, wizards actually do, may think they are arms deep in rats nest of cabling, plugging and pulling, an eye always cast sideways to monitor the blinkenlights. For some reason, these weirdos are doing this in the middle of the night. After futzing around with the cables and assuring the lights are lit, they turn to their laptop and they clack away at the keyboard to show the interfaces or stat the net or confirm the commit of what they were working on.

Actually, sometimes, that’s not too far from the truth.

But the fact of the matter is that a network engineering role isn’t just what takes place in a rack full of equipment. There are designs to consider - both proposals and review for commentary. There are configurations and change management to review and approve. There’s maintnenance to plan, software to upgrade, incident reports to write or contribute to and oh, the SWE fresh out of undergrad thinks they’ve solved some problem while simultaneously ignoring network constraints and expecting the network’s support.

Cloudy Forecasting

The biggest change coming is how workers interact with their company’s data. Reports of the prevalence of remote work possibilities are mixed at their overall prevalence and what impact remote work will play over the next five or ten years. Though it is, I think, safe to say that it is more prevalent after the COVID-19 pandemic of the early 2020s than it was before. Before, the workforce would report to an office, which would have network connectivity for devices and then connected to some data center, either their own in that building, a separate colocation facility or even, a third party cloud provider. With folks not working from an office outisde their home, connections into the corporate network may change from concentrating into a traditional VPN endpoint and migrate to a cloud-based Zero Trust network intermediary. Just these two scenarios show how network engineering roles are changing. Initially, folks were noting that there will be fewer office campus networks to deploy and maintain, and what office and campus networks remain will probably be smaller in scope. Not relying on hardware VPN concentrators and outsourcing to third party clouds, the network becomes more abstracted and locked in another vendor. But here is the beauty of networking - the rules of interoperability mean that the underlying principles are still the same as a traditional network. All that remains is that you need to cut the marketing wheat from the chaff. Return to Office (RTO) mandates starting in 2024 is a notable shift back to centralizing to an office location outside of one’s home but not wanting to spend the cash on traditional network hardware, we’ll see a network-specific hybrid solution as offices will have higher capacity direct Internet access connections but workers connecting to SASE and Zero Trust SaaS products to access data.

Indeed, The Cloud is changing the career outlook of network engineering. All of that abstraction of lower layers of the networking stack as a part of the cloud service has quite a few talking about how cloud is going to kill network engineering, which is maybe a little oversimplistic. After all, SREs and SWEs can do all of the network planning, security consideration and operation as a part of all their other tasks. Depending on the size of the shop, this might be best for business. After all, single-individual systems administrators operating everything in a traditional on-premise environment is a tale as old as time. Scale brings problems - those could be rapid growth pushes towards IP exhaustion (an IPv4 problem but definitely top of mind because these cases never push IPv6 adoption to further kill network engineers), multi-cloud tennancy, or mutli-cloud-region effects on IP prefix announcements. Arguably, Meta and Google have already done it, managing large global networks with a code-first mentality that has all network engineering candidates doing the same coding exercises as software engineering candidates. And while those of us outside those realms can look to them as one way of doing things, there are other, large global networks that haven’t followed an identical path.

Automate All The Things

Network Automation has been a buzz for a couple of years now. It’s also in an odd state of flux - does automation mean customized, internal software? Is it using vendor-specific gimmicks like Cisco DNA or Juniper Mist? Are you doing device configuration with Ansible or Terraform? There are few differeneces, operationally, between Ansible, Terraform or Jinja. Custom internal software is now well defined object oriented python but 25 years ago, it was perl. How network engineers use and write code to manage their devices is changing in so far as what tools are in vogue but needs remain the same. There have always been low-code network engineers and I think we’ll see them but instead of entering lines of syntax into a device directly they’ll move towards SaaS solutions and ClickOps tactics.

Automation, with regards to the management of networks, has been a buzzing around for the last decade. However, truth be told, network operators have been using code to manage networks for longer - often random shell or perl scripts, written one-off by engineers and technicians, purpose built for tasks. What has come in the times between 1990s Internet booms and busts and the second decade of the 2000s is that network automation started being standardized along recognizable frameworks with many general purpose tools implemented: Python being a generally agreed upon language, modules like Napalm for device interfacing, Jinja templates or Ansible to deploy devices, and software management through git. Or, if you are operating a network without vendor diversity, your vendor of choice will sell you (or force you into) their homegrown product of choice. The fact of the matter is, in 2026, some degree of network automation is expected and while there are frameworks that can help you it is still a little Wild West with the mix of tools if you move company to company, network to network.

AI, Networks and You

AI is certainly going to be the thing that kills us all. At least, unless you’re on the hypetrain (or a scummy, parasitic, ‘evangelist-stroke-thoughtleader’), that is how you sound if you have any sort of nuance towards the technology. If you can read the nuance - it is a technology that shows promise, is already showing negataive effects in some industries and requires significant guardrails (both of the software and of the societal varieties). And I personally have a lot more nuance beyond that but that has less to do with network engineering so I’ll spare you that treatise. Specifically on the positive and personal, while trying to automate all the things, I’ve been able to leveage AI for debugging code I’ve written reducing debugging time by a factor of 10. Now, before you shout “look at the efficiencies!”, I’m not a great programmer/coder. I understand some very basic coding logic and have a bit of experience building on existing code or using existing code as a template but only now do I feel anywhere confident starting a project from an idea and being able to make significant progress quickly. It is almost vibe-coding. But so many considerations go into software engineering, that I don’t think experienced professionals are actually ready to be full on replaced with a bunch of interns and unlimited Claude tokens, especially when where we still live in a world of AI agents deleting production databases.

Likewise with software engineers, AI driven or agentic networks are still very much a work in progress. Network engineers can make use of AI tools to help with configurations and automation to build and manage networks but the idea that you can basically set and forget a network and leave it up to AI agents to manage (and thus lessening the need for skilled and experienced network operators) is still a little bit science fiction. Will we get there? Maybe. The Internet and Web has been burned by charlatans and their Internet of Things, bitcoins, blockchains, NFTs and I am sure more before so I am absolutely skeptical. This may be as good as it gets, folks.

What’s Changing and Becoming a Network Engineer Now

One place that AI can affect network engineering, and leaning towards the positive, is that this magic technology is propping up a spurn of data center construction in the United States. This of course leads to a lot more nuance but if the construction projects go through, there will be a crop of new network engineering positions opening. It may not be a ton but as I said, agentic network management isn’t really a thing yet, which means there will be some growth in headcount and has not decimated the entire field.

AI is a useful tool that can help experienced operators close the automation gap quicker than before, coupled with learning best practices of established frameworks. The current landscape is Partly Cloudy and has been for long enough, I don’t think it is going to change. Some enterprises will be built entitrely in public (read: third party) cloud compute that, if they get big enough for dedicated network engineer(s), it will be a skill set, akin to asking for Cisco or Juniper experience in your job descriptions. But in the past five or so years, there has been a reversal of the trends of putting everything into the clouds, so more “on-premise” (also read: owned and operated) infrastructure and thus what you could call more traditional network engineering still has not died out like the dinosaurs we are.

If ever there was a point to where I’ve thought something and was wrong, Return to Office (RTO) schemes are ticking up the needs of network engineers to manage office campuses. A few years ago, I was meeting with some former colleagues (we’d previously worked together but since moved to other companies) at a conference and we were discussing the health and future of the industry. One of our group noted that he was considering moving out of his current networking gig as the workload had been affected by cloud migrations and pandemic related Work From Home. It looks like he’s still there, so it looked like some things may have reversed course. We also noted the ages of us in the room: mid thirties and up. This isn’t an ageist thing but more that there doesn’t seem to be a backfill of younger engineers coming up now. It is, perhaps, a bad example. Taking a cross section at a social event at a conference in an industry that doesn’t require conference attendance to maintain professional credentials, and a conference that is targeted towards Network Operators, is a heavily skewed sample size. I don’t know if, we looked at attrition of just a pillar of network engineering, what we’d see more of: people who moved out of networking for management, moved out due to boredom/job hazard (listen, even if on-call and off-peaks are required, they still suck and can drive people out or away), moved out specifically due to job availability or outright retired. And does the attrition rate account for raising an alarm bell that we need younger people moving into networking? The “STEM OR BUST” mentality of the 2010s has helped with the current glut of folks trying to break into technology careers and having a real hard time so while I am welcoming to anyone who wants to join our professional ranks, I’m hesitant to tell folks already not committed that they should do it.

So, if you’re committed to technology and think network engineering may be right for you, here’s what I would recommend:

tags: