As a nerd, I can safely say that Star Trek II: The Wrath of Khan is the best of all the Star Trek films.  It has great character development, and engaging story, and even some fun dialog.  One throwaway line in particular caught my attention recently and made me think about certifications and studying.

In the first big dramatic scene, the bad guy (Khan) has the good guy (Kirk) outgunned and at his mercy.  While scrambling to find a solution to this unwinnable situation, he settles on the gambit of hacking the bad guy’s ship.  When the green lieutenant asks the good guy why he needs the secret code (prefix code) for the bad guy’s ship, the good guy admonishes the lieutenant with the following line:

“You have to learn why things work on a starship.“

In a movie filled with other great quotes and scenes, this one throwaway line goes unnoticed.  I even had to find a copy of the script to be sure I got it right.  But when it comes to certification, that line holds a lot of power.  You might even say that it sums up the totality of the certification process, as well as the reason why some people that pass still have trouble in the real world.

Everything in networking, or IT for that matter, follows a set of rules.  Programs execute based on a set of instructions.  Electrical signals follow the laws of physics.  Unlike the Matrix, these rules are very seldom flexible.  The same inputs almost always produce the same outputs.  There is no magic or mystical explanation for these behaviors.  Everything does what it does because of these rules.

When you take the time to learn why a protocol behaves in a specific way or why a device  exhibits a certain erratic behavior during troubleshooting, you have a more complete understanding of all the factors that go into that behavior.  Just like in the above example, the good guy is the old veteren of many starship voyages.  He knows why ships behave they way they do.  Because he knows why the ships have a prefix code, he knows how to exploit that behavior against someone that doesn’t know in order to escape the situation.  Someone without knowledge of why things are the way they are would miss that as a possibility simply because it doesn’t exist to them.

Far too often, people seeking certification don’t want to know why something behaves in the way that it does.  They simply want to know the answer to the question or they want to learn the trivia facts in order to satisfy the multiple choice part of the exam.  When it comes time to apply that knowledge those students that don’t understand things beyond fact memorization can’t cope.  For example, look at a simple layer 2 bridging loop.  Most people that have experienced this will tell you simply that it takes the entire network down. Easy enough to explain why it’s bad.  But why does it do this?  You have to dig a little deeper to find the answer.  You have to understand that bridges forward unknown unicast frames out of every port except the ingress port.  Then you have to know there isn’t a method for layer 2 Time To Live (TTL) so those unicast frames can eventually age out of the network.  Finally, you have to know that the impact of all those unicast frames being constantly forwarded out of the bridge eventually overwhelms the CPU and causes the bridge to stop forwarding traffic of all kinds because it can’t keep up.  There’s a lot of why in that explanation.  Learning all of it means you know a myriad of ways to prevent the problem from happening in the first place.  Knowing why means when you develop a new protocol down the road you can address those things and fix them (hello L2 TTL!)

If you skip the why, you miss out on a huge part of troubleshooting and configuration.  Every command has a reason for existing.  Every setting has a valid excuse for being included.  Taking the extra time to learn about those things is what separates the good network rock stars from the rest of the pack.  The dedication and time invested in learning something that completely really shows to potential employers and people conducting technical interviews.  But don’t take my word for it.  Instead, listen to CCIE Instructor Marko Milivojevic:

I couldn’t have said it better myself.