Why you need to learn to code
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.
The opportunity cost of becoming a competent programmer seems massive to me. How do you do it while still having enough networking skills? Don’t you risk just becoming mediocre at both coding and networking?
Fredrik — thanks for stopping by!
I tend to think learning to code has helped me as a network engineer. Yes, I could have learned some new technology, but I invested in a tool instead. There is some point where you can learn how to cook every dish in the cookbook, and still not really know how to cook (if that makes sense). Of course, you can also learn all about stoves, and never learn how to cook. Somehow there needs to be a balance between these two extremes in terms of your “shape of knowledge.”
Ultimately, though, I guess it depends on what you consider the opportunity cost, and your “shape of knowledge” goal. My goal is always breadth first, as I tend to think this is more helpful, especially in the world that is coming for network engineers.
🙂
Russ
I like your cooking analogy, and I think my frustration with this topic boils down to something like this:
1. The people that discuss the importance of coding/improved tools/sdn/etc are often, or always, already skilled in “networking”. They might have spent decade(s) acquiring this knowledge, and this makes this opportunity cost that I’m talking about much lower since there are diminishing marginal returns to studying any one area. In your case for example, spending 100 hours on BGP when you are already in the 99.99th percentile in that topic is most likely a waste of time. However, for entry/mid level people, or a student like myself, 100 hours on coding is 100 hours not learning important networking topics.
Or if we’re using cooking analogies, you guys are experienced chefs that know all about ingredients and dishes and recipes, and are now discussing the importance of certain new techniques and tools. But the audience include people that don’t know even know what a Béarnaise sauce contains, or how to make it using traditional methods. One chef might then say that it doesn’t matter that you don’t know how to make the sauce yourself anymore since you can just buy it. Someone else might say that you should learn how to make it to learn the fundamentals, but then just buy it anyway. A third might say that you always make your own because it will be just right. The student will obviously be confused.
2. The vagueness of the discussion. Most people would probably agree that some degree of coding skills are useful (my understanding of IT history is that there have always been networking people that could also write code) so the real discussion has to be more specific. What coding skills? What kind of software should you be able to write? What concepts are the most important? What are the key books? Examples of code that you should understand. What should you be able to accomplish?
Fredrik —
On point 1, I would agree in general, but point out that it always takes time… The best you can do is to be intentional about learning, picking up skills over time. The biggest mistake I think we make in our learning is to be random, or just choose whatever you have thrown at you right now to the ultimate depth you can. IE, “we need to deploy voice this week, so I’ll learn voice to the deepest level possible,” rather than asking “what is useful for me to know about voice, and how can I learn those things?” And I don’t mean configuration here — that’s another mistake we often get into. I know lots of people who say, “I know how to configure SIP, so I know voice,” or even “I’ve compiled this OS, so I know the architecture.” We need to get out of both habits of thinking. We don’t need to know everything to the bit level, and we do need to learn to ask the right questions.
So — the answer to #1, IMHO, is to be intentional and be measured.
For #2, this is something that’s already on my list to talk about here on ‘net Work. Patience…
🙂
Russ
Fredrik –
I would like to expand on Russ’ statement on learning to ask the right questions. What Russ is saying is that we need to find the questions that will expose the underlying architecture of a technology to a point that we understand its base working components. In particular we need to make sure that we understand the why and the what of a technology. A great example of this is the architecture document for NETCONF/YANG (rfc6244). This document gives us the necessary information about the technologies to understand why and what these technologies are used for and makes it easier for us to dig deeper into the details of each of them without getting lost in the weeds.
Sometimes its possible to combine our goals of finding the right questions with coding and practical application of a networking technology. Consider the OSPF fibbing project. This project uses code to inject OSPF LSA Type 5’s into a network to do traffic engineering. Exploring this project will make it clear that we need to know OSPF LSA types, we need to understand what affect these have on the protocol, we can look at the code and understand how this is implemented. We can go even deeper and consider Dijkstra’s algorithm and see what that would look like in code and help us better understand OSPF and by extension IS-IS.
I hope this was helpful.
Johnny —
Thanks for stopping by… In short — you nailed it.
🙂
Russ
Part 2 – What kind of coding?
Russ,
I work for big Enterprise, I’m one of those people that Greg Ferro describes as giving up on their dreams and embraced complacency by staying in the Enterprise way too long. My point is that I fail to see automation being a big necessity in the Enterprise. I do use tools like HPNA and used to use tools like Cisco LMS to send the same config change to over 2,000 devices. I understand that Network Automation is all the rage today, but in the Enterprise I fail to see the need at the moment. My vendor of course is saying that we need to rip everything out in order to stay ahead of the curve, but when I ask them why, they only respond with more buzzwords and cliches.
I don’t pretend to be at your level or to posses your skillset (not worthy), but at the moment, I fail to see why I need to code in the Enterprise. Also, I run into very few developers that know anything outside of the app that they are currently working on. I am taking a Python course just in case and do know a little bit about scripting being a long time Linux Desktop user.
Regards,
John…
John —
Thanks for stopping by to comment! My thinking is that you need to learn to code not because you’re going to need to a coder, but because it’s a skill set that will help you in your career. I do hope you can make it to retirement where you are, but… If you can’t, knowing how to interact with code — reading it, understanding it, knowing the discipline of coding, knowing the basic algorithms, etc. — will be extremely helpful in finding something someplace else when your company decides they’re not doing so well.
As for the vendors telling you to rip it out and start over — I would listen. I would then carefully listen to their product pitch, and then do some serious research on the alternatives. Then I would rip them out and replace them with something else. 🙂
It might be you can build something new and interesting where you are, help the company’s bottom line, and help keep you in place until you retire.
🙂
Russ
I totally agree with this post. I think one aspect that is sometimes overlooked is recruiting the next generation of Network Engineers and innovators. In my experience, in the Silicon Valley/US, nearly all of the interns that come to Cisco IT arrive with some basic programming skills and expect to be able to code. As Network Engineers, if we can be fluent in coding frameworks, we can not only provide tailored experiences to interns and new hires, but also show the opportunities and value of innovating in the networking space. In my experience, getting a Computer Science degree at a major silicon valley university, the expectation for getting a Comp Sci/Comp Eng. degree is app development. We need to be able to provide an alternative narrative and showcase the exciting opportunities in innovating within IT.
Excellent piece of writing.