Reaction: The Future is…

Reaction: The Future is…

This week, I ran across two posts that follow down a path I’ve gone down before—but it is well worth bringing this point up again. Once more into the breach. Tom, over at the Networking Nerd, has this to say on the topic of the future of network engineering—

The syntaxes that power these new APIs aren’t the copyrighted CLIs that networking professionals spend their waking hours memorizing in excruciating detail. JUNOS and Cisco’s “standard” CLI are as much relics of the past as CatOS. At least, that’s the refrain that comes from both sides of the discussion. The traditional networking professionals hold tight to the access methods they have experience with and can tune like a fine instrument. More progressive networkers argue that standardizing around programming languages is the way to go. Why learn a propriety access method when Python can do it for you?

The point Tom makes is this: programming is not the future of network engineering. But, but… there is so much pressure, and so many people saying “if you do not know how to program, you are going to be out of a job in five years.” I think there are negative and positive things you can learn from this ongoing argument.

First, programming is important. Second, coding is not important. Did I just contradict myself? Perhaps, or perhaps not. To understand, let me back up a little. Engineers, as a species of technical people, tend to focus on what is “real” at this moment. For network engineers, what is “real” is the vendor product you just unboxed, the rack it fits in to, the CLI that appears on the screen when you boot the box (if you buy into the “programming is a fad” camp), or the scripts you write to configure the box and get it up and running on the network (if you buy into the “programming is the future” camp).

But I want to make a simple point here: neither the CLI, nor the programming interface, is what is real. To use an overused phrase, we are arguing over the placement of the deck chairs on a quickly shifting deck. I do not believe the ship is sinking—far from it—but I do believe the ship is in rough seas, and we’re spending far too much time figuring out how to nail down the things that move, and not enough in understanding the nature of the storm, nor where the ship is headed.

Now, to answer the question, I want to move to an adjacent world, the world of coding. As it turns out, many different worlds are moving through the same process as network engineering, from graphic design to coding. Hackernoon, another blog I follow, addressed this same problem from a coder’s perspective this last week; the point made there is that there is a difference between algorithms and code. Specifically—

Algorithms: A sequence of steps that describes an idea for solving a problem meeting the criteria of correctness and terminability. An abstract recipe for the calculation independent of implementation. Code: A set of instructions for a computer. A concrete implementation of the calculation on a specific platform in a specific programming language.

This differentiation is extremely important for the network engineer as much as for the coder. Programming is important because it encompasses the algorithms and processes, the mindset of a coder. Coding is not important because the deck chairs are always going to change.

So should you learn to code? Yes, if you are going to be a meta-coder, someone who understands what process, and what algorithm, to use where. Should you learn to code? No, if you are going to treat the code like another CLI to learn.

The bottom line is this: engineers—real engineers, who understand the problems, solutions, and processes—have nothing to fear from any shift in the network engineering world. Those who have always focused on the CLI, API, and other access methods, will always be chasing chairs.