When I was a college student, I had one favorite question to ask people at social events: if you had to give your younger self one piece of advice, what would it be?

The answers changed from person to person. But one of them kept coming back, from people who had nothing else in common: learn the fundamentals.

It never clicked for me. It sounded like the thing people say when they don’t have a real answer.

Then I spent a morning troubleshooting an isolated site for an angry client.

I went in assuming the worst. A provider issue upstream. A config that went bad overnight and nobody wrote down. Something in the tunnel. I checked the interesting things first, because the interesting things are what I wanted it to be.

It was a cable in the wrong port.

That’s when it clicked.

What “fundamentals” actually means⌗

I used to hear “fundamentals” and think “beginner stuff.” That’s not exactly wrong, but it isn’t true either. Fundamentals are more like the layer underneath everything else.

In networking, it’s the OSI model, how a frame moves, what a MAC address table does, how ARP resolves, what a routing table decides, how DNS answers a query. Not the definitions you memorize for an exam. The mental model that lets you predict what a packet will do before you type a single command.

Once you have that model, troubleshooting stops being guessing. You go bottom to top. Is there link? Is there a MAC? Is there an IP? Can it ARP? Can it route? Can it resolve? Every step tells you where to stop looking.

Without that model, you’re just trying things. Reboot it. Clear the session. I would be lying if I said I never did that, and those random changes sometimes worked. That’s the worst outcome, because I learned nothing and I’m just praying the problem doesn’t come back.

Vendors change. The principles don’t.⌗

This is the advice I’d give myself starting out.

I’ve worked on Cisco, Huawei, Ekinops OneOS, some FortiGate. Different command lines. Different ways to say the same thing. If your knowledge is “the commands,” you’re starting from zero every time a client has a box you’ve never touched.

But a broadcast storm is a broadcast storm on all of them. A duplex mismatch behaves the same way everywhere, no matter whose logo is on the case. Once you know what’s supposed to happen, you just need to find where that vendor hides the output. That’s a documentation problem, and documentation is easy.

Syntax is rented. Principles are owned.

Why I skipped them anyway⌗

If this base knowledge saves so much time and effort, why did I avoid it for so long?

Because fundamentals don’t feel like progress.

Learning a new tool felt like progress. Buying a course felt like progress. Adding a fifth dashboard to my monitoring felt like progress. Subnetting by hand for an hour just felt like homework.

That’s the good news, though. If the boring work is what everyone avoids, then doing the boring work is an actual edge.

The other trap⌗

None of this means you should go bury yourself in theory first.

I’m not writing this as someone who finally became the CLI ninja he wanted to be. I still abuse the “?” on my routers. But looking back at how I actually made progress, I caught myself using one sentence more often than I’d like to admit: “I’m not ready to build the project, I need to finish the theory first.”

Fundamentals aren’t a phase you complete before real work starts. You learn them by doing real things badly and going back to figure out why. Build the lab, break it, then go read about why it broke. Ship the ugly version, watch it fail, then learn the concept that explains the failure.

The goal isn’t mastering the basics before you start. It’s never being too proud to go back down to them when something doesn’t work.