I Didn’t Leave Software Engineering Behind. I Found the Layer Beneath It.

Four years after working as an IP Engineer, I returned to networking — this time with years of software engineering behind me. It changed what I saw.

Four years ago, I worked with a broadband company as an IP Engineer. At the time, that world wasn’t particularly foreign to me. I was an undergraduate studying Telecommunications Engineering, I had taken courses around Cisco CCNA, and I was already accustomed to the language of routers, IP addresses, protocols and network services. I understood that devices needed addresses. I understood that routers connected networks. I understood that protocols established the rules that allowed those devices to communicate.

What I didn’t understand yet was how far my curiosity would take me beyond them. Because after a while, knowing that packets could move through a network stopped being enough. I became interested in what those packets were carrying. If a user entered a URL and data travelled across a network, what happened at the other end? How was the application built? What logic determined the response? How did the browser turn that response into something useful? Those questions pulled me toward software engineering.

Frontend development became the first door I opened. I started learning how the applications I had previously thought of mainly as destinations on a network were actually constructed. Eventually, curiosity pushed me beyond the interface. I wanted to understand APIs, databases, authentication, application logic and the architecture connecting everything together. Frontend gradually became full-stack development.

I interned at a startup, worked on real solutions and spent the next couple of years getting increasingly comfortable thinking about applications as systems rather than just interfaces. At the same time, I furthered my education in Communication and Information Engineering in England.

And somewhere in the middle of all of this, my career began to look strangely fragmented.

Telecommunications.

IP networking.

Software engineering.

Communication systems.

For a while, I thought I had wandered too far from where I started.

It took me some time to realise that I hadn’t.

The questions had simply changed.

The Further I Went Into Software, the More I Wanted to Know What Was Underneath It

Building applications gave me answers, but it also created better questions.

You can build a web application and know that an API call works. But where exactly is that request going?

You can connect an application to a database. But what infrastructure is keeping that database available?

You can deploy an application and receive a URL. But what happens between someone typing that URL and your application receiving the request?

What resolves the domain name?

How does the client know where to send the packet?

What happens when the destination isn’t on the local network?

Which device moves it elsewhere?

How does a private IP address communicate beyond its network?

What happens when one component in that chain fails?

And eventually, an even bigger question emerged:

Who builds and maintains the environment that allows all of this software to work reliably in the first place?

That question brought me to Cloud and Infrastructure Engineering.

For the first time, my background didn’t feel scattered.

It felt cumulative.

Telecommunications had introduced me to communication systems. Networking had shown me how devices exchanged information. Software engineering had shown me what we build on top of those networks. Cloud and infrastructure engineering seemed to sit at the intersection of all three.

So six weeks ago, I made the decision to stop treating that interest as something I would explore “eventually.”

I built a roadmap and started again from networking.

Not because networking was completely new to me.

Because this time, I wanted to understand it differently.

Six Weeks of Going Back to the Foundation

My roadmap doesn’t begin with AWS or Azure.

It doesn’t begin with Kubernetes either.

It begins with networking.

From there, I intend to move through Linux and systems administration, enterprise infrastructure, cloud platforms, containerisation with Docker, Kubernetes, Infrastructure as Code, CI/CD and automation, and eventually monitoring and observability — with increasingly realistic projects connecting those layers together.

But I didn’t want to race toward the technologies that have “cloud” written on them while carrying a shallow understanding of what happens underneath them.

So the first six weeks became about one question:

When one machine communicates with another, what is actually happening?

Revisiting Cisco Networking Academy’s Networking Basics course allowed me to see familiar concepts differently, especially after years of building software. IPv4 became more than an address, DHCP more than automatic configuration, and DNS more than the invisible service behind a domain name. Routing, NAT, TCP and HTTP gradually stopped feeling like isolated concepts and became parts of the same journey a request takes from a client to a server. For the first time, I wasn’t just building what appeared in the browser; I was following the request beneath the browser. But I didn’t want completing the course and earning the Cisco badge to be the strongest evidence of what I had learned. After weeks of personalising and documenting Packet Tracer labs on GitHub, I removed the instructions, started with an empty workspace, imagined a business with real requirements, and built its network from the ground up. That became Project Atlas.

Project Atlas: Could I Build the Whole Thing Myself?

Project Atlas became the practical test of everything I had learned: I designed a branch network with structured IPv4 addressing, centralized DHCP, static routing, PAT, DNS, HTTP, wired and wireless access. What mattered most was seeing how those individual services depended on one another to make something as simple as loading www.atlassolutions.com actually work. I also deliberately broke a Finance workstation by shutting down its switch port, then traced the fault from connectivity symptoms to the access layer and restored service with no shutdown. That troubleshooting exercise reinforced a lesson I want to carry forward: good engineering is not just making systems work, but understanding why they fail and proving that the real cause has been fixed.

Six weeks ago, I started this roadmap with networking, and today that first chapter closes with a Cisco Networking Academy credential, documented Packet Tracer labs, and Project Atlas as my first complete enterprise networking capstone. The labs are available in my Enterprise Networking Labs repository, while the full capstone is documented in the Project Atlas repository. Next, I move into Linux and systems administration before progressing toward cloud, containers, automation, Infrastructure as Code, monitoring, and observability. I’ll keep documenting the journey here — not just what works, but what fails, why it fails, and what I learn fixing it. I’m beginning to understand that you don’t need a perfect starting point; sometimes you just need to keep following the questions that refuse to leave you alone.