Knowledge and Complexity

In almost every field of IT lots of people try to do their job relying on uncle Google and his friends (bloggers, forum wizards and other content producers) and cut-and-paste solutions found on the web into their programs, server- or device configurations. Here’s my theory why that might be the case; please feel free to shoot it down in flames.

When a technology starts escaping from the labs and drawing boards, you need to know a lot to get anything done. Remember the old days with Cisco’s software didn’t even have the prompt when you entered the configuration mode, let alone contextual help? You had to understand IP subnetting to build your network (because the routers were managed through IP) even though all you wanted to do was to run IPX or AppleTalk ... and there was nothing on the Internet, because we’ve just started building it. In short, you had to know a lot to get even the simplest of the tasks done.

Compare that to what we have today – (often somewhat useless) GUI tools for people who get scared by the CLI, configuration wizards, and tons of potentially relevant tips and advices on the Internet (some of them inapplicable to your situation, a few of them plain wrong). You can survive for a while without even reading the manual that came with the equipment, and run a reasonably-sized SMB network without ever understanding what you’re doing ... until everything crashes.

I don’t want to start another GUI-versus-CLI debate. GUIs are great in some environments and for some use cases, and graphic representation of complex topics is almost always better than text-only one. They also give you a false sense of simplicity – they hide the complexity of what you’re trying to do, and you think you’re doing just fine until their abstraction layer breaks down.

If you’d plot knowledge needed versus job complexity on a graph, you’d probably get something like this:

Notice I added a third horizontal line: the “I have enough” limit. In the old days, you could give up and return to whatever else they were doing or you could struggle really hard to master the technology, and then understand at least some of what you were doing. The “I have enough” line was really “I give up” one.

To draw a parallel from the non-IT world: 100 years ago everyone was able to fix their own car, because they had to know how to do it (or could get stuck in the middle of nowhere). You either spent time figuring out how to fix your own car or you didn’t drive around in it (or at least not for long).

With a mature technology, you can get quite far and get pretty complex jobs done without ever understanding what you’re doing and why it works. The “I have enough” line becomes “I know enough”. Going back to the car example: I’m positive most drivers today (and quite a few mechanics relying solely on vendor-provided troubleshooting machinery) have no idea how internal combustion engine works, and they don’t need that knowledge to drive around.

That’s OK as long as you’re aware there’s a whole lot you’re missing and you know you need a specialist to fix the problems ... and this is where the IT-is-like-cars analogy breaks down. In IT, everyone (and their dog) tends to have opinions about all other parts of IT (quite often they tend to be wrong, and they usually underestimate the complexity), and we solve the lack-of-knowledge with “wisdoms” like “try to reload the box” and “let’s just reformat the hard drive.” That approach might work to some extent, but it’s somewhat hard (and takes a while) to reformat your network, and reloading a router or a switch doesn’t always work if you messed up the configuration and saved the changes.

How is this relevant?

If you’re a junior engineer just entering the networking you have to be aware that there’s a lot of complexity hidden behind the scenes. It’s up to you to decide whether you want to go the extra mile and invest your time to move from begin acquainted with technology (remaining an average car driver) to excelling in it (becoming a wizard who’s able to fine-tune or even design a racing car engine)... but if you decide to stay below the “I don’t need more” line, don’t be surprised if your job gets automated in a not-too-distant future.

This post probably wouldn't ever get published without constructive feedback from Tony Bourke, Matthew Norwood, Ethan Banks, Jeff Fry and Marko Milivojević. Thanks a million!

8 comments:

  1. This. THIS! Jason Torchinsky at Jalopnik has something to say on this as well:

    http://jalopnik.com/5875751/why-the-check-engine-light-must-be-banned
  2. http://www.quotes-clothing.com/technology-indistinguishable-from-magic-arthur-clarke/

    :)

    To elaborate - I think there are only two directions for a keen learner - it's either depth or breadth. And I suspect that those who claim to cover both, have no personal life. ;)
  3. cargo cult network engineering as in:

    http://en.wikipedia.org/wiki/Cargo_cult_programming
  4. As someone beginning their career in the networking field this is by far the best advice I have been given. And sadly it is completely true in the people I have been in contact with during my quest for knowledge.
  5. This is absolutely correct.

    I think also because it is now easier more then ever for quite young people to be "in the know" with IT. Schools these days? Laptops and ipads.

    Those curious enough will go on google and look at servers and what they do, download timebombed microsoft software and muck around. Then (think)they are now a "server expert" at the age of 16.

    I think also the fact that alot of people doing the interviewing for SMB companies, for the IT jobs, have no idea about IT themselves. This makes it quite easy to say "I know windows real good" without actually knowing anything about windows. They then land a job at a small ad-hoc IT company looking after SMB("sysadmin" or "systems engineer"), and its the exact scenario you listed above.

    The market is flooded with these kinds of people. The reason IT has one of the stereotypes it has.

    note: I am not saying this is a bad thing, or good thing, good and bad are matter of opinion and situation.
  6. Some observations follow.

    There are people who find joy in tinkering with technologies. They are called geeks today, nerds yesterday and when I was in high school, loosers (yes, I am a looser). They are not large in number. They spend a good deal of time tinkering (with the associated deep learning). If the technology is new, this is fine as there is little demand to deploy it in the market, so no time pressure to "just deploy it".

    One implication of a "mature technology" is the adoption rate is growing rapidly. Time to deploy for the newest admins approaches "zero". Thus, the time available to tinker and learn for the newest admins also approaches zero. That said, if they installed it and its running, who among them would call themselves "novies" about the technology?

    I'm in a technical class this week. We all introduced ourselves. 50% of the attendees "suddenly" became responsible for this technology and inherited the design and deployment of the previous admin. They have very little time to dig deep because they still have their original responsibilities along with the new technology. There is so much time in the day.

    Those in IT who have the time to dig deep are most fortunate indeed.
  7. It's very true of your statement.
Add comment
Sidebar