What “Old” Network Engineers Need to Remember

By Leon Adato, Head Geek SolarWinds

Not long ago, I read “Five Things Old Programmers Should Remember” by Gary Wisniewski. In it, Gary recounts watching Star Trek one evening and how something the late, great Leonard Nimoy as Mr. Spock said to James T. Kirk in response to the good captain’s lamenting about getting too old and worn out:

“If I may be so bold, it was a mistake for you to accept promotion. Commanding a starship is your first, best destiny; anything else is a waste of material.”

Gary then commented on how this applied to him, having gotten sidetracked, if you will, and departing from his first, best destiny as a software engineer—never mind the fact that his sidetrack was starting his own company and raising bucket loads of venture capital money. He then goes on to list five things old programmers should remember.

I loved his perspective and, as I head into my third decade in IT, the reminder that the things that pushed me into a career in technology remain the things that not only keep me here, but are also the things that make me great at what I do. So, I thought it a worthy endeavor to list out the things that have always been true for me as an IT professional; more specifically, as a network administrator.

To help me, I've engaged with friends, colleagues, and fellow Head Geeks over at SolarWinds - Patrick Hubbard, Kong Yang, and Thomas LaRock - to get a perspective from each of their respective areas of specialization. In the coming weeks, you'll hear what is important to remember if you are and old SysAdmin, Virtualization admin, or DBA.

As for me, I'm going to keep this focused on (almost) nothing but net. So what is it that an old network engineer needs to remember?

1.) First, I can't say it better than Tom will in his essay, so I'm going to give you a preview here: Always assume good intentions. "Just because someone is yelling at you because the server is down doesn't mean they hate you. If an end-user suggests that SQL replication is the answer to all their problems, take the time to learn more about what problem they are trying to solve. A little empathy will go a long way in your career." If an end-user suggests that “adding some QoS” is the answer to all their problems, take the time to learn more about what problem they are trying to solve.

2.) Tightly related to number one is the fact that “they” are never going to understand the network (or networks in general) like we do. Never. Shouting into the void, rolling your eyes, muttering under your breath and generally holding “them” in some form of contempt is not going to change this. Commit to the idea that you will educate when and where the opportunity presents itself, but otherwise you may as well wear a pointed hat and beard.

And no, numbers one and two are not contradictory. True, they don’t understand. Yes, they will make suggestions that border on insane, not to mention inane. But you are still best served by assuming good intentions.

3.) This one’s all about us: Just because “they” won’t understand doesn’t mean nobody will ever understand. Just “them.” Find the ones who are “us.” The ones who share your passion and interest. Bring them close. Learn how to be a mentor. How to challenge without overwhelming How to teach. Learn how to share the load, and even delegate. In the beginning, you may only be able to offload 10 percent or even less of your tasks, but believe me, even that is worth your time.

4.) “Reload in” has been and always shall be your very good friend.

5.) I invoke good old RFC1925, also known as “The Twelve Networking Truths,” which is just as true today as it was in 1996: If your network doesn’t actually work, then all the fancy hardware is for naught. Anything that impacts the ability of your network to work should be suspect. And you must know that your network is working and how well it is working. This is only accomplished through proper monitoring and management. For more on that, check out this ebook on monitoring as a discipline.

6.) You should always focus on what you are able to accomplish. As network engineers, we frequently get caught up in how we can get the job done—being a CLI jockey, an ACL guru or a Wireshark wizard. Even though we take pride in the hundreds of hours we spend building a specific skillset with a particular tool, the reality is that our value is far more than the commands we’ve memorized.

In closing, this more than anything else, is what we “old” Network Engineers (and all IT professionals, really) who have been around the block a time or four need to remember: We are more than the sum of our skills—we’re the sum of our experiences, ideas, and passions. That is what got us here in the first place, what has kept us here all this time and what will keep us here as wave after wave of new blood and fresh young faces come to join us on this journey.

Look for more thoughts on what "old" IT Pro's need to remember in the coming weeks!

  • The origin of the common phrase "Always check the cables!"? emoticons_happy.png

  • Years ago when I was a mainframe engineer, back when Noah was designing his ark, I got pulled into a mainframe replacement. Yes, the entire mainframe was being swapped out. The machine room had three separate mainframes from separate manufacturers complete with their own strings of disks, tapes and printers. Ours had been causing intermittent problems for a few years and since installation and after flying in numerous specialists from the development plant it had been decided to swap the entire complex out. Ouch, that was an expensive decision.

    While I was de-installing the system’s console, a huge collection of teleprinters, keyboards and new-fangled VDUs all built into a couple of massive walk-up desks, I found the console’s earth connection had not been bolted down. It was placed over its earth pin, but there was no nut to secure it. When I pointed this out to my boss he told me not to tell anyone because this was most likely the root cause of the intermittent system crashes resulting in the customer having to do 36 hour recoveries. Oops.

    The bottom line is to always start with the basics. It’s no good fixing the fancy stuff when the power (or in this case the grounding) is flaky.

  • Thanks Mr Adato, fine essay, very nice for me to read as I'm midway through my second decade in IT.  Had I read this even a few years ago not that much would've made sense.  Now it ALL rings true!!

  • Thank you for RFC 1925.   That made my day that all that wisdom exists in a single place.

Thwack - Symbolize TM, R, and C