We’ve all heard it by now: you’d better learn to code, or your network engineering career is going to die a quick (and potentially painful) death. Maybe you could still act as a briefcase carrier, and call yourself a consultant, but without coding skills, you’re open ended job is going to become a dead end, and you’ll be a has been. While just about everyone has weighed in on this topic recently, I don’t know if anyone has, IMHO, really dug down to the bottom of the question. Permit me to give it a try (and feel free to disagree in the comments).
To get to the point, allow me to summarize both sides of the argument (hopefully without building and straw men along the way). On one side are folks who say that the Command Line Interface (CLI) is dead, and that we must learn to automate everything. Part of the argument here seems to be that without automation, we won’t be able to keep the operational costs (OPEX) down; as networks are primarily a cost center (rather than a strategic asset), driving costs down is one of the most important tasks a network engineer can take on. That, and reducing costs will make you look like a hero, and automation will help you stop focusing on the small stuff, and…
The “other side” seems to be saying something like this: you don’t need to learn to code, but rather just to use the tools that are inevitably coming along to replace the CLI at some point in the future. These tools (and/or interfaces) will necessarily be more dynamic, as they will tie applications and the network together into one system. But, overall, they will still be tools that require no more configuration than current day CLIs. And—after all—if you really need to have something coded, there will always be coders around to help with that particular part of the problem.
Let’s assume, for the moment, that we won’t be able to answer the question, “how many network engineering jobs without coding skills will be available in the future,” so we can leave both of the options above out of the discussion. Is there any other reason to develop coding skills?
There are, in fact.
First, coding isn’t just a set of skills; it’s also a set of tools, processes, and mindset. For instance, coders often need to interact with document management systems beyond the simplicity of a cloud based file sharing system, and with tools that lay out the differences between two files in a quick and straightforward way. Coders also need to learn a set of algorithms and ways to structure data for easy processing, which also means some basic math in areas outside “everyday life.” Finally, coders need to learn design and problem solving patterns that are different from, but related to, the ones network engineers learn, as well as a set of disciplines around feature, code, and defect management.
All of these skills are easier to learn through coding than any other way—and they might even be impossible to learn in any other way. And each of these skills are invaluable for the network engineer—in fact, for any engineer—to have. Managing configurations through something like git makes a lot more sense than through something like a set of word processing documents. Understanding the algorithms behind a protocol (or some part of a protocol) is very helpful when troubleshooting and designing a network.
Second, it’s pretty obvious that network engineers need to interact with business folks to gather requirements and evaluate results. But what about coders? We tend to be protected from coders by account teams today, but in a more automated version of the network, will this continue to be true? It doesn’t seem like it—it seems like every network engineer is going to need to directly interact with coders who are actually doing the automation for the networks we work on. There may be some set of small networks where the automation is all “commercialized,” in that you’re buying vendor based solutions with a GUI, but companies moving in that direction are actually moving away from having anyone who might be called an “engineer” on staff anyway.
So, to return to the question at hand—should you learn to code?
My answer is yes. Even if your job doesn’t require it. Even if your job won’t ever require it, and you don’t ever see yourself writing one piece of code that ever makes it into production anyplace in the world. Coding isn’t (just) about getting that next pay raise, nor it is just about keeping your job. It’s also a set of skills, a body of knowledge, and a way of thinking that will help you in dealing with a wide array of network engineering problems.