Archive for 2016

The argument around learning to code, it seems, always runs something like this:

We don’t need network engineers any longer, or we won’t in five years. Everything is going to be automated. All we’ll really need is coders who can write a python script to make it all work. Forget those expert level certifications. Just go to a coding boot camp, or get a good solid degree in coding, and you’ll be set for the rest of your life!

It certainly seems plausible on the surface. The market is pretty clearly splitting into definite camps—cloud, disaggregated, and hyperconverged—and this split is certainly going to drive a lot of change in what network engineers do every day. But is this idea of abandoning network engineering skills and replacing them wholesale with coding skills really viable?

To think this question through, it’s best to start with another one. Assume everyone in the world decides to become a coder tomorrow. Every automotive engineer and mechanic, every civil engineer and architect, every chef, and every grocer moves into coding. The question that should rise just at this moment is: what is it that’s being coded? Back end coders code database systems and business logic. Front end coders code user interfaces. Graphics coders code ray tracing systems, artificial surfaces, and other such things. There is no way to do any of these things successfully if you don’t know the goal of the project. There’s no point in coding a GUI if you don’t understand user interface design. There’s no point in coding a back end system if you don’t understand accounting, or database design, or data analytics.

Given all of this, what piece of knowledge is lacking the path we are being urged to go down?

Network engineering.

If you want to code databases, you need to learn database theory. If you want to code accounting systems, you need to learn accounting. If you want to code networks, you need to learn network engineering.

But what do we mean when we say “network engineering?” Isn’t network engineering just buying some vendor gear, stringing it together, and the configuring it based on some set of arcane rules no-one really understands anyway? Isn’t network engineering much like building a castle out of plastic play blocks, just fitting them together in a way that makes sense, and ignoring or smoothing over the rough edges where things don’t quite fit right?

In short, no.

I’m not going to discourage you from learning to code—and I don’t just mean throwing around some python scripts to automate some odds and ends, or to complete a challenge on some web site. I truly believe that coding, real coding, is a good skill to have. But to believe we are going to eliminate network engineering through automation is to trade a skill set that has always been of rather limited value—purchasing, installing, and configuring vendor built appliances—with another one that is probably of less value—automating the configuration of vendor built devices. I fail to see how this is a good idea. If we all become coders, there will be no networks to code—because there will be no network engineers to build them.

Yes, silo’d engineers are going to be in less demand in the future than they are today—but this is old news, at least as old as my time administering a Netware Network at BASF, and even older. The market always wants specific skills right now, and engineers always need to build skills for the long term.

If you want to learn something now—if you want to learn something that will stand the test of time—if you want to learn something that will outlast vendors and appliances and white box and disaggregation and…

Learn network engineering.

Not how to configure devices—the skill that has stood in for real network engineering knowledge for far too long. Not how to automate the configuration of network devices—the skill that we are increasingly turning to, to replace our knowledge of the CLI.

Learn how the protocols really work, from theory to implementation, rather than how to configure them. Learn how devices switch packets, and why they work this way, rather than the available bandwidth on the latest gear. Learn how to design a network, rather than how to deploy vendor gear. Learn how to troubleshoot a network, rather than how to issue commands and look for responses.

It’s time we stopped spreading the “if you just learn to code, you’ll be in demand in five years” hype. If you have network engineering skills, then learning to code is a good thing. But I know plenty of really good coders who are not employed because they don’t have any skill other than coding (and to them, I say, learn network engineering). Learning to code is not a magic carpet that will take you to a field of dreams.

There is still hard work to do, there are still hard things to learn, there are still problems to be solved.

It’s fine—in fact crucial—to be an engineer who knows how to code. But you need to be an engineer, before learning to code is all that useful.