Parallel Post

I wasn’t able to logically fit these topics into a single post. These are more items from the “blog ideas” file.

One of the things that has helped my self-confidence tremendously is working with techs that are below my level. For example, while I work at the data center of my company, we do have about 500 branch offices throughout the country, and when something goes beyond just plugging a cable in, we hire contractors to go to the locations and do the work.

When I first started working for the company I was at before the school system, we acted as a contract provider. I would travel to various sites to fix whatever technical issue needed fixing, and occasionally I would have to work with someone over the phone. Even though to this day I don’t like being on the phone, it gives me a little bit of a chuckle to know that I’ve progressed in my career to where I am now the person on the other end of the phone telling the on-site tech what they need to do. Because I have been on both sides, I am very patient and respectful of the techs.

I’ve encountered a few situations where the techs didn’t quite have the level of knowledge needed to do the job by themselves, and it has given me great pleasure to be able to explain things to them and help them understand.¬†Likewise, with our own in-house help desk team, whenever they have questions for me, I feel great when I get to explain things to them. Maybe part of that great feeling is simply knowing that I’m beyond the help-desk level of my career.

Next topic: the evolution of networking standards that are now taken for granted. I’ve touched on this before about how most books that are directly certification-related often don’t go into the history of various protocols. For example, when I studied for the CCNP, I learned about the OSPF routing protocol and its use of stub areas. Because I was studying in the 2012-2013 timeframe, I just took for granted that stub areas were always a part of the protocol, because their use in network design makes sense, and the book didn’t tell me otherwise.

It was only later during my CCIE studies where you are forced to go deeper into the protocols that I found out that OSPF didn’t always have stub areas. One particular type of stub area (NSSA) was actually not incorporated into OSPF until 2003, but because I wasn’t into networking as a career at that time, I had no way of knowing that and just took for granted that it was always there.

Likewise, there are LOTS of protocols and technologies that were designed to solve particular problems during their time, but they are no longer used, or are no longer used in their original form. I know that people who have been in the field for 20-30+ years have seen lots of things change, and lots of new people entering the field, learning the current technologies, and assuming that that’s the way things have always been.

To go back to the OSPF example, the various additions to the protocol were partially the result of networking equipment not being as powerful at the time as it is now. Many of the optimizations were essentially workarounds for slow equipment, which is much less relevant today. Things like that make me wish that certification textbooks would devote some space to the history of the topics being discussed, because I think it would benefit the industry as a whole if more people could see where things came from, because there are a lot of technologies that get “invented” over and over again. Most of the time, its for the same reason that it was invented in the first place.

When networking started to take hold in the 1980s, it was mostly the end systems that were responsible for the networking intelligence, and everything in the middle was basically just “dumb pipes”. Then in the 1990s-2000s the network became more intelligent and the end systems essentially “just connected” and didn’t have to worry about anything else. We are now in the beginning stages of a hybrid of these two, where the middle is returning back to a “dumb pipe”, the edge devices, such as servers, will be defining the actual networking, and the end devices (laptops, tablets, phones, etc) will still “just connect” and not have to worry about the details.

Next: I¬†have been thinking about Juniper certifications for quite a long time. I passed the bottom-level JNCIA exam a couple of years ago. But I haven’t worked at a company that uses Juniper gear for their infrastructure. Yet, I feel like I know enough that it wouldn’t take me long at all to get up to speed if I was working with the equipment. I don’t feel like I need a certification for that (though, if the company pays for it, I’m all for it). I’m at the point where I feel like my existing base of knowledge and experience would carry me to that point without requiring the certification.

I intend to follow through with the CCIE, because I believe that single certification can open doors for me that others are unable to.

I may also study for and take the certification for VMware NSX before my VCP-DCV expires at the end of next year. There are two reasons for this: I am actually interested in the material (VMware NSX is all about network virtualization), and because I already have the VCP certification, I don’t have to sit for another boring class before taking the exam.

However, while I am interested in the material covered under various other certifications, I don’t see myself actually pursuing certifications themselves outside of the CCIE R&S and the NSX cert.

Things may change, though.

Leave a Reply

Your email address will not be published. Required fields are marked *