Knowing vs Understanding

In IT, we search the Web constantly. Everything we need is literally at our fingertips, just an Internet query away.

This is interesting because IT professionals tend to make a big deal of knowing things by heart. Can you calculate subnets off the top of your head? Do you know these OS commands (and all of their sub-commands)? Can you set up this or that without referring to the manual?

Back in high school, one of my best friends was on the path to what would become a very fulfilling career as a microbiologist. I vividly recall sitting in the hallway before school quizzing her on the periodic table of elements for her chemistry exams.

I reconnected with her several years after graduation. One of my first calls to her started off with me demanding to know the atomic weight of germanium. She knew immediately what I was asking, but responded with, “I couldn’t care less.”

I was surprised, and asked if it was an example of things you learn in school that turn out not to be important later on.

“Nope. I use that kind of thing every day,” she said.

“Then how come you don’t know it?”

“Because,” she replied. “I don’t have to know it. I simply have to know where to find it. What is actually important to know,” she explained, “is what to do with the information once I have it.”

I think that’s what differentiates experienced IT professionals from newbies. The newcomers focus on (and stress out about) specific factoids, the atomic elements that make up a particular technology. The veterans know that it’s not the specific commands or verbs that are important. What’s important are the larger patterns and use-cases. Those things can actually make or break you, professionally speaking.

Let’s take this a bit further and discuss the difference between knowing and understanding. Information Technology is one of the few places I can think of where people who call themselves professionals can be successful even while they don’t understand huge swaths of the technology they use.

I have met entire teams of server administrators who can’t explain the first thing about IP addresses, or networking in general. Similarly, I have met network engineers who don’t know and don’t care how operating systems communicate.

This is partially by design, and partially by convenience. DBAs don’t need to understand how packets are built up and broken down as they traverse switches and routers. In a handful of situations, they may be able to more effectively troubleshoot an issue if they did know, but most of the time it’s not important. The network is a big black box where their data goes (and, if you ask them, the network is the reason their data is delivered so slowly. But they’re wrong. IT’S NEVER THE NETWORK!)

However, there is a difference between not understanding and not caring to understand. One is due to a lack of opportunity but not curiosity. The other is a willing abdication of responsibility to know.

I think the second is extremely unhealthy.

IT pros need to be committed to lifelong (or at least career-long) learning and growth. No area of IT is too esoteric to want to know about. We may not have time right now, or we may not be able to utilize the knowledge immediately, but rest assured that understanding how and why something works the way it does is always better than the alternative.

Anonymous
Parents
  • Good article.  

    A good example of why a willing abdication of responsibility to know is a bad thing that directly relates to networking is that of programmers who write apps or applications that query a database.   Quite often those programmers are sitting in the same datacenter as their database resides.  I've seen countless times where the application works fine in their testing environments,but once it goes out to a remote site it runs amazingly slow even though there is sufficient bandwidth to handle it.  Trying to teach them about latency and how doing lots of little queries one after the other is a killer once the app moves to a remote site can be an uphill battle.   Its a big shift in how they program to optimize their applications for a WAN vs. a LAN, but one that is critical to their application succeeding.   There is only so much we can do on the network side to help with that sort of thing.

    I think it also shows how Cisco products are so well received by us network engineers vs. some other brands.   With Cisco products, I don't need to know every command that a device has, or how to do absolutely everything on them.  I need to know approximately what I'm looking for and how to get there.   With a Cisco product if I need to show either a MAC address or a ARP entry, I know that I'm going to start with a "show" command and probably move to either "mac" or "arp" as the next keyword.   Being able to hit the "?" key is a HUGE benefit to figuring out what your next step was.   I don't know how often I've wanted to debug something on a Cisco product and I do a "debug ?" or something similar.   I can't for the life of me figure out how other vendors coming up in the world have not learned from this example and structured their command lines similarly.  

    My latest nemesis is Fortinet products for example.   Our company wants to move to them, thinking Cisco is too expensive, and some of the higher ups just don't understand why I can't stand working with them.   But, at a point in the recent past I was working on redoing our TACACs environment and had to reprogram both our Cisco products and get the Fortinet products working.   The Cisco products were quite simple both in configuration and diagnostics.   For debugging on Cisco its  just a matter of doing "debug tacacs ?" or "debug aaa ?" to get me on the right path.  After probably a week long discussion with Fortinet as to why things weren't working, I finally got them to disclose the debugging commands for TACACS on a Fortinet:

    diagnose debug application fnbamd -1

    diagnose debug enable

    WTH!?  Where did that come from?   Not only can't I remember that, but there is no way I would ever figure it out!!!   Luckily for me the output it spews is totally unintelligible, so knowing it doesn't matter all that much!!   emoticons_laugh.pngemoticons_wink.png

    Using the "arp" or "mac" example above, once again for Fortinet its quite confusing.    You might think to show the arp table from the command line might be the "show system arp-table" command?   But sorry, I've never seen that command produce anything.   Instead its "get system arp", not to be confused with "get system arp-table".   While "get system arp" will return what you probably want, "get system arp-table" also returns you nothing.  Huh? 

    And yes, Fortinet does have a web-based GUI that you can use, but neither of the examples given above are accessible via the GUI either!!

    So all you up and coming Vendors out there, learn from this!!  If you want us to like your products, make it SIMPLE for us to learn your product!  Don't make us memorize tons of commands and have to figure out what works and what doesn't.   Make your products work the way we want and expect them to.  Now, that doesn't mean you have to make your devices run IOS, but learn from the good things that other companies have done already.   Make it so that we can easily adapt to your product, not have to learn something totally new and force us to memorie things!!

Comment
  • Good article.  

    A good example of why a willing abdication of responsibility to know is a bad thing that directly relates to networking is that of programmers who write apps or applications that query a database.   Quite often those programmers are sitting in the same datacenter as their database resides.  I've seen countless times where the application works fine in their testing environments,but once it goes out to a remote site it runs amazingly slow even though there is sufficient bandwidth to handle it.  Trying to teach them about latency and how doing lots of little queries one after the other is a killer once the app moves to a remote site can be an uphill battle.   Its a big shift in how they program to optimize their applications for a WAN vs. a LAN, but one that is critical to their application succeeding.   There is only so much we can do on the network side to help with that sort of thing.

    I think it also shows how Cisco products are so well received by us network engineers vs. some other brands.   With Cisco products, I don't need to know every command that a device has, or how to do absolutely everything on them.  I need to know approximately what I'm looking for and how to get there.   With a Cisco product if I need to show either a MAC address or a ARP entry, I know that I'm going to start with a "show" command and probably move to either "mac" or "arp" as the next keyword.   Being able to hit the "?" key is a HUGE benefit to figuring out what your next step was.   I don't know how often I've wanted to debug something on a Cisco product and I do a "debug ?" or something similar.   I can't for the life of me figure out how other vendors coming up in the world have not learned from this example and structured their command lines similarly.  

    My latest nemesis is Fortinet products for example.   Our company wants to move to them, thinking Cisco is too expensive, and some of the higher ups just don't understand why I can't stand working with them.   But, at a point in the recent past I was working on redoing our TACACs environment and had to reprogram both our Cisco products and get the Fortinet products working.   The Cisco products were quite simple both in configuration and diagnostics.   For debugging on Cisco its  just a matter of doing "debug tacacs ?" or "debug aaa ?" to get me on the right path.  After probably a week long discussion with Fortinet as to why things weren't working, I finally got them to disclose the debugging commands for TACACS on a Fortinet:

    diagnose debug application fnbamd -1

    diagnose debug enable

    WTH!?  Where did that come from?   Not only can't I remember that, but there is no way I would ever figure it out!!!   Luckily for me the output it spews is totally unintelligible, so knowing it doesn't matter all that much!!   emoticons_laugh.pngemoticons_wink.png

    Using the "arp" or "mac" example above, once again for Fortinet its quite confusing.    You might think to show the arp table from the command line might be the "show system arp-table" command?   But sorry, I've never seen that command produce anything.   Instead its "get system arp", not to be confused with "get system arp-table".   While "get system arp" will return what you probably want, "get system arp-table" also returns you nothing.  Huh? 

    And yes, Fortinet does have a web-based GUI that you can use, but neither of the examples given above are accessible via the GUI either!!

    So all you up and coming Vendors out there, learn from this!!  If you want us to like your products, make it SIMPLE for us to learn your product!  Don't make us memorize tons of commands and have to figure out what works and what doesn't.   Make your products work the way we want and expect them to.  Now, that doesn't mean you have to make your devices run IOS, but learn from the good things that other companies have done already.   Make it so that we can easily adapt to your product, not have to learn something totally new and force us to memorie things!!

Children
No Data
Thwack - Symbolize TM, R, and C