Exaggerating the End of Neteng

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.

Post navigation

3 comments

I think that what matters to most people is the actual supply and demand of network engineers, of average skill level, in 5 to 10 years time, not whether the profession itself will be gone. If, due to technological advancements, there will be say 50% less such engineers working in 10 years, it doesn’t make that much sense to bet your career on this field, if there are other fields that you can get into instead. Unless of course you are already highly skilled and experienced, in which case a decrease in demand won’t affect you as much.

The problem I see with a lot of career advice is that it’s highly idealized and not very practical. I don’t doubt that you guys have great insight into how to become the ideal network engineer of the future, but most people that strive for this ideal will likely fall short and just become a reasonably competent person that won’t stand out among the other reasonably competent people that do the same thing. That’s just a fact of life, and at that point, the realities of the market will be the biggest concern.

Despite perhaps coming off as critical of this post, I actually really like reading Russ White’s articles. It’s the most well written articles you’ll find in the networking community, but I would still trade them for data on the attitudes of IT hiring managers and what hiring decisions they have made in the last six months. If hiring managers think that “SDN” and “coding” are the most important things, it doesn’t really matter If I’ve studied the BGP RFCs in-depth.

There's a lot to cover here and I'll ping Russ to give him your opinion as well.

Firstly, should one form their profile to be employable or to be a good network engineer? The two may not completely align. Much of the advice we give to people is based on forming someone into what we would consider to be a good network engineer or architect. Someone that will have long lasting skills and is not just chasing the latest fad. Someone that understands protocols, algorithms and the underlying logic of networking. This will ensure that when the next new thing comes out you'll be able to understand it and your skills will be "time less". For someone that is new to the field they will of course in the beginning be more of "CLI jockeys" and do a lot of implementation. That is natural but this person should still understand what it is that they are configuring.

We all need to put food on the table so we must also be employable. One way of being employable is by having certifications. Having them makes you stand out if you acquired them in the right way since most people don't have them. Another way to stand out can be to have one of the newer skills like within automation or so since that makes you stand out even more before the market catches up. Keep in mind though that hiring managers rarely know a lot about the market or technology in general. They mostly use buzz words in describing the jobs without really knowing what they mean. Sometimes they have help from engineers to describe what is necessary in the job role.

Data is always good but difficult to find, especially accurate data. The problem is also that it would have to be very local data. Data about the US would likely do you no good since you are based in Sweden. Data about city x maybe won't help you much if you are in city y and so on. Based on what I'm seeing in the market there's still ways to go before a lot of the organizations do automation here. Some are but it's still a minority of the market. It's very difficult to find people that are good netengs. It's even more difficult to find those that also know automation. For example I know a SP that has been looking for a network architect with a "SDN" profile for a very long time now…

Just to be clear. Many of my posts are based on that I want to balance all of the "SDN is here, networking is dead!" FUD that gets spread. That doesn't believe that I don't believe in network automation or that a person should not learn about it. I'm learning Python myself. What I'm saying is that Ansible and Python aren't likely the only tools that will be used in the time to come and tooling always changes. If your only skill is the tool of the day then you'll have to reskill a lot, which is normal but if you don't have the fundamental knowledge then everything new that comes out is like starting from scratch. A person that has the fundamental knowledge and programmatic and algorithmic thinking will be able to pick up something new much faster.

Thanks for stopping by and commenting! I started typing out a long reply, and then realized — this is a long enough reply to be a separate post. What I’m going to do, instead of replying here, is to actually reply in a video over the next 2 to 3 weeks. Look for the video to be posted here and at rule11.tech in a few weeks.

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

This will be displayed in a monospaced font. The first four
spaces will be stripped off, but all other whitespace
will be preserved.
Markdown is turned off in code blocks:
[This is not a link](http://example.com)