David Bombal invited me for another short chat – this time on what I recommend young networking engineers just starting their career. As I did a bit of a research I stumbled upon some great recommendations on Quora:

• How to identify a good electrical engineer
• What advice would you give young engineers early in their career?
• What are the most important things of working as an engineer that nobody mentioned in college?

I couldn’t save the pages to Internet Archive (looks like it’s not friendly with Quora), so I can only hope they won’t disappear ;)

One of my subscribers trying to figure out how to improve his career choices sent me this question:

I am Sr. Network Engineer with 12+ Years’ experience. I was quit happy with my networking skills but will all the recent changes I’m confused. I am not able to understand what are the key skills I should learn as a network engineer to keep myself demandable.

Before reading the rest of this blog post, please read Cloud and the Three IT Geographies by Massimo Re Ferre.

In one of his recent blog posts Tom Hollingsworth described what I semi-consciously felt about the CCIE lab exam for at least 25 years: it’s full of contrived scenarios that look more like Iron Chef than real life.

I understand they had to make the lab harder and harder to stop cheating (because talking with candidates and flunking the incompetents is obviously not an option), and there’s only so much one can do with a limited set of technologies… but forcing networking engineers to find ever-more-devious ways to solve overly-complex problems is nothing else but fuel for rampant MacGyverism.

Anyway, I don’t think this mess will ever be fixed, so the only thing we can do is to enjoy the rant.

A few weeks ago, I had an interesting video chat with David Bombal in which we covered a wide variety of topics including

• What would you do if you started networking today?
• How do you increase the value of your knowledge?
• Networking hasn’t changed in the last 40 years and whatever you learn about networking will still be valid 20 years from now;
• Why should I learn and implement network automation?
• When should I start learning about network automation?

Note: David posted the whole list of topics with timestamps in the pinned comment under the video.

Got this question from a networking engineer who couldn’t decide whether to go for CCIE Data Center certification or attend my Building Next-Generation Data Center online course:

I am considering pursuing CCIE DC. I found your Next-Generation DC course very interesting. Now I am bit confused trying to decide whether to start with CCIE DC first and then do your course.

You might be in a similar position, so here’s what I told him.

Stumbled upon this paragraph on Russ White’s blog:

I don’t really know how you write a certification that does not allow someone who has memorized the feature guide to do well. How do you test for protocol theory, and still have a broad enough set of test questions that they cannot be photographed and distributed?

As Russ succinctly explained the problem is two-fold:

Got an interesting set of questions from one of my readers. He started with:

I really like networks but I don't know if I am doing enough for this community. Most of my work is involved with technologies which are already discovered by people and I am not really satisfied with it.

Well, first you want to decide whether you want to be (primarily) a researcher (focusing on discovering new stuff), an engineer (mostly figuring out how to build useful things by using existing stuff), or an administrator (configuring stuff).

J Metz published a great article describing six hard truths not taught in school. As all good things should come in 7-tuples, here’s another one I was told ages ago when I was a young hotshot full of myself:

Professions were created for a reason – they enable people to do the work they’re qualified to do.

Needless to say, it took me decades to fully understand its implications.

One of my readers sent me a few questions about the leaf-and-spine fabric architectures webinar because (in his own words)

We have some projects 100% matching these contents and it would be really useful this extra feedback, not just from consultants and manufacturer.

When I explained the details he followed up with:

Now, I expect in one or two weeks to find some days to be able to follow this webinar in a profitable way, not just between phone calls and emails.

That’s not how it works.

I love listening to Scott Lowe’s Full Stack Journey podcast, so I was totally delighted when he asked me to participate. The results: FSJ Episode#8. Enjoy!

Failure to use DNS, IP addresses embedded in the code, ignoring the physical realities (like bandwidth and latency)… the list of mistakes that eventually get dumped into networking engineer’s lap is depressing.

It’s easy to reach the conclusion that the people making those mistakes must be stupid or lazy… but in reality most of them never realized they were causing someone else problems because nobody told them so.

A while ago I answered a few questions that Dan Novak from University of Maryland sent me, and as they might be relevant to someone out there decided to publish the answers.

Dan started with a soft one:

What circumstances led you to choosing network engineering for a career?

It was pure coincidence.

One of the reasons I started creating ipSpace.net webinars was to help networking engineers grasp the basics of adjacent technologies like virtualization and storage. Based on feedback from an attendee of my Introduction to Virtual Networking webinar it works:

I am completely on the Network side of the house and understand what I need to build for Storage/Data replication, but I really never thoroughly understood why. This allowed me to have a coherent discussion with my counterparts in DB and Storage and some of the pitfalls that can occur if we try to cowboy the network design.

Recommendation: if you have a similar problem, start with Introduction to Virtual Networking and continue with Data Center 3.0 webinar.

Every time I’m explaining the intricacies of new technologies to networking engineers, I try to use analogies with older well-known technologies, trying to make it simpler to grasp the architectural constraints of the shiny new stuff.

Unfortunately, most engineers younger than ~35 years have no idea what I’m talking about – all they know are Ethernet, IP and MPLS.

Just to give you an example – here’s a slide from my SDN workshop.

In a recent blog post Tom Hollingsworth made a great point: we should refocus from fighting one fire at a time to preventing fires.

I completely agree with him. However…