From:
My desk, just after this morning’s walk

Dear Friend & Network Engineer,

A few months ago, a young man I’ll call Calvin sent me one of the simplest questions you can ask about this field:

“How should I learn networking and start working toward becoming a network engineer?”

Calvin was starting from absolute zero. He didn’t have a networking job, a certification, or a long list of things he’d already tried. He’d decided to change careers, and he wanted to earn his CCNA before the end of this year.

I gave him my answer. This week, he wrote back.

I’ll tell you what happened in a moment. First, I need to warn you about something.

A simple question like Calvin’s can turn into a small disaster when you ask it online. Before dinner, a beginner can collect twenty roadmaps, twelve YouTube playlists, seven books, three certification arguments, and a small civil war over Packet Tracer and EVE-NG.

By bedtime, he has more answers than he can use and no idea what to do Monday morning.

The problem isn’t a shortage of information. The problem is that consuming information lets you feel serious while somebody else keeps making every difficult decision for you.

That trap has a name:
Studying Without Building

Now, before the CCNP and CCIE people on this list decide this letter is for beginners and move on, stay with me.

I regularly hear from perhaps 50 or 60 experienced engineers on this list. They work in telecom, cloud, hosting, government, enterprise networks, and data centers across Europe, the United States, and India. Some are working toward CCNP or CCIE. Some already run networks Calvin can barely picture.

But I also know something their job titles and purchase history don’t tell me. I’ve seen engineers buy nearly every advanced lab package we’ve made and still describe themselves as CCNA-level. I’ve seen people buy CCIE training materials and leave them untouched for a year or two.

So let’s get one thing straight:
A CCIE lab package in your account proves only that you own a CCIE lab package.

No offense intended. The same rule applies to me.

The network doesn’t care what we own. It cares what we can recognize, configure, verify, and troubleshoot when nobody’s standing beside us with the next command.

So, for the next few minutes, forget your title, certifications, and everything you’ve ever purchased. Maybe you’re standing where Calvin stood, at the beginning of networking. Maybe you’ve been doing this for fifteen years and you’re standing at the beginning of your next level. Either way, the first move is the same: ground yourself in the fundamentals.

If you’re truly starting from zero, start with Network+. I recommend Mike Meyers. Pick his Network+ training and work through it from beginning to end.

Don’t spend three weeks comparing him with every other instructor online. You’re choosing a starting point, not a spouse.

Learn the network models. Learn Ethernet, IP addressing, switching, routing, cabling, wireless, security, and the basic logic of troubleshooting. When something doesn’t make sense, go over it again. Then keep moving.

When you reach CCNA, put the current Cisco Press Official Cert Guides on your desk and read them from the first page to the last. After you’ve spent serious time in the lab, read them again. You’ll see things the second time that were invisible the first because now you’ve got somewhere to attach the explanation.

When you move into CCNP, CCIE, or a specific Cisco technology, follow the same rule. Use the current primary books and Cisco documentation. Read with a pen beside you. Mark what you don’t understand, then go back to those pages after you’ve watched the technology behave in a lab.

Now I’m going to annoy a few people. Be very careful with anyone who tells you that you don’t need the primary material. I’ve met people who’ve taught networking for years but have never read the main book they teach from, beginning to end.

Think about that. They’re telling beginners what they can safely skip before they’ve finished the foundation themselves.

A polished video proves that someone can produce a polished video. A large audience proves that someone can attract a large audience.

Neither one proves that person can build a network, track down a fault, or explain why the result changed. They may be able to repeat the command, but they can’t give you experience they never earned.

The beginner’s problem is that he doesn’t know enough yet to spot a confident instructor with a weak foundation. When you don’t know what to question, everything can sound convincing.

That’s why I keep pushing you toward the primary books, official documentation, and the network itself. The network is much harder to fool.

Let me take you back for a moment. When I started learning networking, there was no EVE-NG waiting on my computer.

YouTube wasn’t there. Online training platforms weren’t there. I didn’t have fifty instructors explaining the same protocol in fifty different ways.

If I wanted hands-on practice, I had to spend part of my salary on real routers and switches. I read the books, connected the devices, configured them, got the wrong result, checked what I’d done, and tried again.

And the device was wonderfully rude about it. It didn’t care how many pages I’d read.

It didn’t care whether I felt confident. The configuration either gave me the result I expected or it didn’t.

At the time, I thought the lack of resources was a disadvantage. Looking back, it may have protected me from the trap engineers face today. I didn’t have enough resources to keep escaping into a new one.

When I got stuck, I couldn’t open another playlist and enjoy the pleasant feeling of starting again. I had to go back to the same pages, the same cables, and the same devices until their behavior made sense.

You don’t have to go through the same hassle I did. If I were starting today, I’d use EVE-NG.

But don’t turn the choice between EVE-NG and Packet Tracer into another month of preparation. I’ve already written the full comparison on the blog.

Choose the tool. Open the topology. Start building.

All right. Let’s say you now have a solid foundation. What comes next?

Simply this:
Master The Technology Already Running In Your Environment

The fundamentals don’t change. Implementations do. Exam blueprints change.

Software releases change. Platforms change. Commands and outputs can change.

A book can teach you why a protocol behaves the way it does. But you still need current documentation and time to see how that technology behaves in the software and on the platforms you actually use in your environment.

Some engineers misunderstand this completely. They call it “staying current.”

Every time a new technology starts making noise, they drop what they were learning, open another playlist, and become beginners all over again.

Why?

Because starting something new feels exciting. Staying with the technology already running in your environment until you can configure, verify, and troubleshoot it feels like work. So the moment the work gets difficult, off they go to the next shiny thing.

Keep doing that and you’ll become an expert in Chapter One.

Master what your environment uses. Stay with it until you understand how it behaves, what to check when it fails, and how to make the next decision without somebody choosing it for you. Then move on.

Use the same rule with your study materials. Use the primary books. Use Cisco documentation. Choose one video program and follow it from beginning to end.

If one point still isn’t clear, use another source to clear up that point. Then go back to your main path.

Don’t rebuild your entire study plan every time somebody on Reddit names a new instructor. Moving files, changing bookmarks, and watching first lessons can feel productive.

It isn’t. You’re practicing how to start over.

Now get yourself a cheap notebook. Paper’s fine.

A simple document’s fine. You don’t need a new productivity system and seventeen colored tags.

After every lab, write down what you were trying to build, what you expected to happen, what actually happened, what you checked, and what finally fixed the problem. Once a week, go back through those notes.

At first, they may look embarrassingly simple. Wrong address. Wrong interface.

Missed command. An assumption you never verified. Keep writing them down.

After a while, patterns start to show up. You see which commands you keep forgetting. You see the concepts that make perfect sense while the instructor is talking and disappear when you sit at the CLI without instructions.

Most importantly, you start connecting technologies that used to live in separate chapters. Let me show you what I mean.

When I first entered a service-provider environment, I was trying to understand a network that mixed Cisco, MikroTik, wireless distribution, PPPoE, RADIUS, VLAN trunks, CAPsMAN, and BGP. I could read the definition of each technology. But that didn’t show me why every piece was there, what depended on it, or what would happen when one piece changed.

So I drew the physical and logical network. Then I rebuilt it at home.

I spent days building it, tearing it down, and building it again. I repeated the process five or six times until I could see how the pieces fit together.

Every time I rebuilt it, I had to answer questions the explanation had answered for me the first time. Why is this component here? What depends on it?

Where does the traffic go next? What changes when this part is missing?

Later, I used that understanding while redesigning three or four ISP networks from scratch. Do you see the difference?

Reading gave me the individual pieces. Rebuilding forced me to understand the system.

And in a real service-provider network, misunderstanding a dependency doesn’t cost you one point on a quiz. It can affect a network people are paying to use. That’s why “I watched the lesson” is a worthless professional standard.

So, the real first steps are:

1. Ground yourself in the fundamentals.

2. Master the technology already running in your environment. Stay current with how it behaves in the software and on the platforms you actually use before you chase the next shiny thing.

3. Record what the network teaches you. Write down your mistakes, what you checked, what fixed the problem, and the questions you still can’t answer. Review those notes at least once a week.

And there’s more. What I’m about to give you is the most important advice in this entire letter.

After you’ve read the chapter, watched the lesson, and written your notes, close all of it and build the network yourself.

You do it.

The instructor doesn’t choose the next device. The workbook doesn’t choose the next interface. The answer file doesn’t choose the next command. You make the decision, check the result, and live with the feedback.

What? Shouldn’t you finish Network+ first? Shouldn’t you finish all the CCNA videos? Shouldn’t you read the whole book twice before you risk getting stuck in a lab?

No. That delay sounds responsible. It’s still avoidance.

While the video’s open, the instructor has already chosen the topology, the device, the interface, the command, and the verification step. All the uncertainty has been taken out before it ever reaches you.

Of course it looks clear. Close the video. Open the topology. Try to build it.

Now the real questions show up: Which device comes first? Which interface should have this address?

What result should you expect? What do you check when that result never appears?

That uncomfortable moment tells you exactly where the learning begins.

Skill begins when you have to make the next decision yourself.

You can study networking for months and still sit in an interview while someone puts a topology in front of you and asks, “Where would you start?” You can explain a routing protocol beautifully and still freeze when the routes show up in the table but the traffic doesn’t pass.

The missing skill isn’t another definition. You haven’t made enough decisions without help.

I’ve worked in enterprise, service-provider, and data-center environments for about 25 years. After all that time, I still go back to the same unglamorous habits.

I draw the network before I rush to the CLI. I figure out how it’s built. I find out who owns each part. I reproduce the problem before I change anything.

Experience hasn’t made those fundamentals any less necessary. It’s shown me how expensive skipping them can become.

The inexperienced engineer often searches for an advanced command that’ll make him feel advanced. The experienced engineer keeps checking the basic path until the evidence tells him where to go next.

Do not wait for confidence.

Confidence is late.

It usually arrives after you’ve done the work enough times to stop needing it.

Now, back to Calvin. This week, his message began like this:

“It’s been a crazy week since I fully committed to this career shift into networking.”

He told me he was treating the change like a full-time job and putting in more than 30 hours a week studying and practicing. He’d started with Network+ and worked through network models, the OSI model, MAC addresses, IP addressing, physical cabling, Ethernet frames, switches, and the basics of installing a physical network. Then he wrote:

“Today I want to install EVE-NG and start hands-on practice alongside the video training.”

And he finished with this:

“There is still a massive amount to learn, but the momentum is there. Back to the lab!”

Good.

Calvin hasn’t reached his goal yet. He knows that.

But he’s stopped collecting possible starting points. He’s started doing the work that gives him real feedback.

Every lab will now tell him what he understands, what he merely recognizes, and what he still can’t do without help. That’s a beginning worth having.

Before I finish, I want you to reply to this email.

If you’re already working at a professional level, tell me how you really got there. I don’t want your list of certifications. Tell me what you built, what you had to repeat, what you broke, and which mistake changed the way you troubleshoot.

If you’re closer to Calvin, send me the exact question that’s stopping you. Tell me where the path gets unclear.

From January 2025 through the beginning of August 2026, we received about 11,000 support emails. When my technical team gave me that number, I told them it couldn’t be right.

It was.

The team answered many of those emails. I answered many myself, either privately or through the Tuesday newsletter. Some never got a direct answer. I won’t pretend otherwise.

But a missing reply doesn’t mean I didn’t read the message. Every morning, after my 5:00 a.m. walk, the first thing I do when I sit down to work is read every email that arrived the day before.

When I can’t answer somebody privately, I often answer the question for everyone in the Tuesday newsletter, the daily emails, or these question-and-answer letters. So tell me where you are.

If you’ve already traveled the road, tell me what actually moved you forward. If you’re at the beginning, ask the question that’s keeping you there.

Then close your inbox and do what Calvin did.

Go back to the lab.

Ali Mansouri
Founder, Dynamips®
Build. Test. Break. Repeat.

P.S. If you’re experienced, don’t send me the polished version of your story. Send me the difficult part. The network you had to rebuild, the fault you missed, or the skill that took far more repetition than you expected. That’s the part Calvin, and thousands of engineers like him, need to hear.