Showing results for 
Search instead for 
Did you mean: 
Create Post

What “Old” Network Engineers Need to Remember

Level 18

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!


Well said Leon...just thought it was a little strange that everything is "#1". The joys of modern software that likes to "help you" !

Maybe they are all equally important

Well said Leon,  and thanks for sticking with the binaries in the numbering.  "1's" or "0's" is how geeks count.


similar to

Just because someone is yelling at you because the server is down doesn't mean they hate you.

I once had someone tell me after a manager got purple faced with me that I should not lose the value of what he was trying to teach me because his delivery was poor and unprofessional.

Level 14

Number one - In general, people are not malicious, they just want their stuff to work.  They want to go home on time, too.

Number two - If they understood networks as well as us, they would be chasing packets with us.  They have their niche, and we have ours.  Ours is to support theirs.

Number three - Many of us started in Desktop support and/or system administration.  We developed an interest in the network administration and pursued it.  Perhaps the sysadmin you are talking to now has that same interest?

Number four - Must agree for any remote work.

Number five - New to me.  Love it, thank you.  Operational trumps security.

Number six - Well said.


Ugh, this reminded me of an incident a few years ago when I was much lower in the totem pole and the business I worked at was undergoing a major upgrade of our core business application.  We had flown in a team of 6 from the vendor to assist with the cut over to the new version and it was estimated it would take something around 6-8 hours of down time in an otherwise 24/7 kind of operation.  Myself and a coworker were going department to department helping them get their workstations configured because this software was the kind of ugly thing that required tailored manual interventions on every machine.  Around the corner comes the general manager of the location and he is basically foaming at the mouth about how screwed up everything was.  We let him know that we are working to get the systems back online and we go back to working as fast as we can as he storms off.  About an hour later we had most of the systems back up and running and we were feeling pretty good as we were on track to have the project complete well inside of the scheduled window.  We were heading back into the ad hoc "command center" and here comes the GM again and this time he has completely lost it.  He starts screaming at us in the hall about how incompetent we each are and how nobody is treating this with the seriousness it deserves.  He really let loose on us telling us what a clown show IT was and some other rather personal remarks but we were pretty confused because we had been under the impression the upgrade went well, considering the scale of it.  We apologized halfheartedly and personally it was a bit of a struggle to contain myself as I am not used to be talked down to like that.  So then we bring him in to talk to our supervisor who is leading the project, and the GM blows some more steam for a few more minutes before we all finally realize at once that he had never read any of the 8 notices we had been emailing out for over 2 months notifying the business unit that the system was going to be upgraded and what that was going to involve.  He had attended meetings months prior where they discussed this project and knew it was in the pipe but somehow never realized that this was that event.  He had no idea why everything was down and he had been running around all morning like a maniac thinking that the sky was falling and that IT had no idea what was going on.  At that point for me the new struggle was not to laugh at how ridiculous he had been acting because he couldn't be bothered to read any emails from IT.  He apologized once he realized the error and left, but from that time until I left the company a few months later I never quite did forgive that guy for the way he spoke to us. 

I guess no real lesson in that story, except to say you should probably try to read your emails and maybe try not be a jerk to people in a crisis.

Level 12

Thanks adatole​, it is always good to be reminded of why we are really here. After a few long weeks with one crisis after another, it is easy to forget that we do this because we love it and if we don't do it right, no one else can do what they are here to do either.

Level 14

Love #3 -- be a mentor.  If you are a good mentor, then you will already be doing 1 and 2.

Level 14

Very good read Leon!  You are spot on.  Share your knowledge.  It will only help in the end.  But Network people are always hated.  It is always a network problem.  It is up to up to prove it overwise and get them to like us again.  Of fix it and admit it.  We don't point the blame away.  lol

I enjoy it when Trek applies to real life.

I also enjoy when IT Professionals understand the limitations of the OSI model at Layers 8-10 (Budget, Politics, Religion--a.k.a.: Apple vs. Windows vs. Linux etc.).

It's too true that we're continually tasked to prove negatives; thank goodness for Solarwinds so we can back up our statements with statistics.


Great list! I started in this game in Feb 89 and I've learned heaps along the way

Level 11

One thing I've learned over the years is the best network engineers started as a sysad first.  Which goes right along with your point that we are the sum of our experiences.  When you get the experience as a sysad before getting into networking you bring a totally different mind set to troubleshooting and relating to your customers.  You see the same thing in many professions, like prior enlisted make the best officers.  Walking in the shoes of someone else gives you a totally different perspective and outlook in your approach to resolving whatever is before you.

Level 14

Well put Leon. Knowledge is currency and spreading that knowledge buys a lot.

Beautiful, adatole​.

All salient points that resonate with this old engineer.

Level 8

Well said!

Level 11

Well said Leon.

I recall being on a team building exercise and being asked who are my customers are. As I was the IT dept at the time my answer was everyone in the room and since then, anyone I work with, still is. There was not a dept in the company that I didn't have a 'super' user in and they were invaluable as they would be the first port of call for that dept.



One and two are spot on. Nice read. Thanks

Level 7


Sometimes I have to remind myself that BOFH is not something to aspire to.

Level 10

I agree with mikegale​, one and two are right on the money.

Level 14

Nice post Leon.

I guess a lot of it is down to  - Are you comfortable & confident with what YOU do? -

If not, it seems quite common to try to beat everyone else down to show how great you are, but with a combination age, experience, knowledge, variety & confidence it becomes easier to relate to others, to teach where appropriate & to nod wisely & say "leave it with me" when needed.

Level 8

#4..."Reload in..."  this may be my favorite CLI command. This command has saved me more times than I care to think about!

Level 8

Nice post Leon!  Thank you.


Yeah very handy when working remotely on a device and all of the sudden you loose contact to it due to a bad command.

Level 9

Truth #3 is fantastic, and very true...

Level 9

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

Level 8

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!!

Level 14

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.

The origin of the common phrase "Always check the cables!"?

Level 14

It is so easy to overlook those things.

About the Author
In my sordid career, I have been an actor, bug exterminator and wild-animal remover (nothing crazy like pumas or wildebeasts. Just skunks and raccoons.), electrician, carpenter, stage-combat instructor, American Sign Language interpreter, and Sunday school teacher. Oh, and I work with computers. Since 1989 (when you got a free copy of Windows 286 on twelve 5¼” floppies when you bought a copy of Excel 1.0) I have worked as a classroom instructor, courseware designer, desktop support tech, server support engineer, and software distribution expert. Then about 14 years ago I got involved with systems monitoring. I've worked with a wide range of tools: Tivoli, Nagios, Patrol, ZenOss, OpenView, SiteScope, and of course SolarWinds. I've designed solutions for companies that were extremely modest (~10 systems) to those that were mind-bogglingly large (250,000 systems in 5,000 locations). During that time, I've had to chance to learn about monitoring all types of systems – routers, switches, load-balancers, and SAN fabric as well as windows, linux, and unix servers running on physical and virtual platforms.