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.
I totally agree with everything here. Hopefully the market forces Network Engineers to be more involved in the automation of their networks, but you still need to understand what you’re trying to automate.
Micahel — thanks for stopping by and commenting! Exactly — you still need to understand what you are automating.
I can only assume you’re either a ghost or that you work by my desk. I’ve been literally telling all of my junior and trainees the very same points you’ve just written down here. Hopefully we will get our guesses right in the future.
Great post, as usual, Russ.
Igor — thanks! Maybe I should come your desk sometime and talk to those junior engineers… 🙂
Learning coding to me no different from learning more about physics or maths per say. No doubt there is always a learning involved with that and you might end up solving problems with those skills at some point hopefully.
Again important thing is learning the concepts and apply them to network engineering to solve different business and technical problems rather just trying to automate everything to prove coding skills.
I have been often asked by few Engineers suggesting they are developing coding skills by learning python or so. But they often couldn’t answer properly when I ask them :
– How python is different from other languages in terms of solving networking problems
– How you think you gonna secure your code
– How you gonna ensure your code is optimized
– Why you gonna track change into your code and maintain versions
– How you gonna do bug scrub on your code
– What typical software/code development cycle looks like
– What measures are in place inside your company to support these efforts
I am certainly not discouraging anyone to learn about how to code, but I guess it’s important to answer all these questions to begin with to bring some value on table instead of end up being a coding kid who tries to automate every possible thing despite that makes sense or not
What do you think ? 🙂
Evil CCIE
Deepak —
Thanks for stopping by! What you’ve brought up is an interesting point very few people consider. It’s easy to code it, it’s harder to maintain it (including all the various processes required, etc.), and even harder to secure. Coding, in other words, isn’t just “coding” — it’s an entire discipline that we should not take likely. It’s often true that looking over the cubicle wall makes things seem a lot simpler. For coders, the network doesn’t seem so hard; for network engineer, coding doesn’t seem so hard.
We would be wise to remember that people spend their entire lives figuring either one of these out. Learning both might only really happen if you have two lifetimes to spend — or maybe if you are okay with only learning half of both (which might actually be an acceptable answer, but it doesn’t get rid of the need for folks who’ve learned either one in more detail).
🙂
Russ
I just agree with you that the base is network engineering for a network engineer,than comes the coding.
Here’s an article that I just wrote on how we did some troubleshooting on an issue that was caused by strange traffic patterns https://www.apextier.com/2016/12/troubleshooting-arpigmprouter-cpu/
It’s one more reason that you’ll continue to need a network administrator/engineer. Understanding how something works rather than how to configure it makes a huge difference. Network engineers should learn about network automation tools, but if any organization wants to thrive, I feel that you’ll still need someone specialized in the field of networking.
And the current Network Protocols will just Survive ?
Rodrigo — thanks for stopping by! I would argue that the problems they solve will still exist, and the solutions used to solve those problems will remain much the same, no matter what we call them, or how we invoke them. Ethan, Jeremy, and I are working on a book based on the problem/solution sets, in fact…
🙂
Russ
Having some scripting skills is always a nice to have, but to be honest, if a company wants to build a proper automation infrastructure, they better hire some experienced programmers rather than send network engineers to “Hello world” courses. A programmer doesn’t really need to know networking to be able to automate a process.