Advice to New Network Engineers

In my shift from the world of voice back into the world of all things networking, I’ve found my new role includes a significant amount of mentoring others new to the networking field. This got me to thinking: What is the best advice I could give someone green and trying to get hands-on experience in networking? I've narrowed it down to two essentials. Feel free to disagree with me, although I will warn you that I am a redhead, and it's entirely at your own risk.

No. 1: Think before you do As engineers we face a constant stream of devices, setups, requests, and technologies, and we are rarely given enough time to truly dig deep into a technology before some manager says, "Make it work, and make it now." With the landscape constantly changing, it's imperative that before you change anything on a production network, you ask yourself three questions:

•Does this make sense?

•What will I impact?

•How will I back out the change?

Does this make sense? This question requires you to analyze the change or implementation request, even if you are analyzing it with a beginner's set of eyes. For example, I've had users request to delete extensions from one IP phone and put them on another when it made more sense to swap where the phones were plugged in. Asking the change initiator "What is your end goal?" rather than complicity agreeing to a manager- or user-defined plan often keeps you from spinning your wheels. Do your best to avoid rushing into actions that will cost you down the road by clarifying objectives versus agreeing to heat-of-the-moment configuration demands.

What will I impact? At some level, you need to know the basics of the technology you are working with; there's no shortcut for that. You have to understand at some fundamental level what's physically/logically connected to what and how one change here impacts systems over there. If you aren't sure, find out first: Research, phone a friend, ask Google. Don't assume any change can be made in isolation without investigating first. I've had customers break their entire inbound call routing because they didn't consider how one change might affect other dependencies in the system. It's a must to keep sight of the bigger picture; systems work with other systems, and rarely is any one piece of technology an island.

[As Cisco expanded beyond routing and switching, network engineers had to put up with buggy code. Read how recent moves by Cisco indicate that it hasn't forgotten network engineers in, "Cisco Renews Focus On Network Engineers."]

How will I back out the change? We all make mistakes. We all get asked to do things that we are immediately asked to undo, usually with management hovering over and demanding we undo faster. A good back-out plan will save your hide and make you a hero at the same time. For simple changes, maybe it's just a copy of the config in a text file, a screen shot or a reload in 10 command. For larger cutovers, maybe it's a contingency plan, including options like restoring from backup or re-routing traffic to other devices. Whatever the task, before you go unplugging, re-configuring or clicking that "save" button, give a moment's thought to how you would set the universe right should things not go quite as planned.

No. 2: Document, document, document

I don't want you on my team if you cannot document what you're doing. There, I said it.You could be the greatest engineer in the civilized world, but if you don't leave yourself or your team a trail of bread crumbs to follow, you are a menace to the department. For new network engineers, developing this habit is crucial to success and longevity in the field. You won't always remember what you did a year ago or two years ago, but if you write it down, your chances of successfully resolving a similar or related issue down the road go up exponentially.

The method and level of documentation may vary; small changes might just be an email to the team or a post on a wiki. All installations and major configuration changes, however, should come standard with a Visio diagram and some verbiage that describes the project, and, for heaven's sake, label/document the physical ports and gear. I cannot tell you the number of unlabeled fiber trays or copper cross-connects I’ve run into where no one knows where they go or what might possibly be connected on the other side. Good documentation takes discipline, just like good engineering.

Having been in the field awhile, I know these skills don't develop overnight. But the most successful engineers I have met invested in developing these essentials early in their networking careers and only got better over time. If you’re looking for a way to go from green to golden in network engineering, I’d advise you to do the same.