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!