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
  • At a previous job we hired a guy who knew one of our bosses from a previous job.  He was supposed to have decades of relevant experience in our industry and I was really glad to have someone coming on who we weren't going to have to train from scratch.  Unfortunately he turned out to be one of those guys who had turned off the part of brain where he learns years ago.  He just didn't seem to know anything outside the very narrow list of duties he had tended for the last few years at his old employer.  Instead of being a useful addition he ended up being a real boat anchor for us because we didn't need someone to do that one thing (and neither did his old employer obviously), we needed someone dynamic and ready to get their hands dirty. 

  • We've gotten several new guys in during the last few years; just about every one brought new points of view that have helped me do my job differently and better.

    We also had one new guy who dragged us down, following a path we couldn't support.  He's no longer with us.

    The moral might be "A great new hire is made with excellent personality, state of the art training in practical applied best practices, and a friendly/easy-going personality." I miss the new guys who were great, but who have gone.

    I learned to hire for personality and train to fit the job, rather than hiring someone with old certifications and experience but who doesn't play nicely with the team.  Here's hoping all administrative types responsible for hiring get on that same wagon.  I love the certs and the skills those new folks can bring--as long as they are fun people to work with.

    But definitely get the new hire in the door when they're nice people.  Spend the money to train them in all things wonderful, and watch your team's synergy advance your productivity. And then reward them with competitive salary and perqs and bonuses equal to or better than the competition; you'll retain them and recoup your training dollars and their learning curve--many times over.

  • That's why you get new guys in...to help you remember that there may be better was to do things or to jog your mind about something you were going to change but forgot about.

  • rschroeder stated  "I've seen this topic discussed and bemoaned by old-school professionals several times." and it got me to thinking.

    Like most people, I tend do things they same way unless there is a compelling reason to change.  So without something or someone bumping me off course I would keep on the same paths.

    Sometimes it is a technology that pushes me forward and other times it is people.

    We hired a new team member about a year ago that has helped me remember to ask, "Why".

    They asked "Why do you do (fill in the blank) in house?"  I said, "Because we have done it that way since 1998, why change?"

    Other then OS upgrades and patches that internal system had changed very little since 1998.

    So in the past few months we moved to a external process.  The new process is much better, easier to manage has the new features we need for 2016.

    All because the new guy said "Why"

    RT

Thwack - Symbolize TM, R, and C