Rehashing Certifications

While at Cisco Live in Barcelona this week, I had a chat with someone—I don’t remember who—about certifications. The main point that came out of the conversation was this:

One of the big dangers with chasing a certification is you will end up chasing knowledge about using a particular vendor feature set, rather than chasing knowledge about a technology.

At some point I’m going to edit a post a video short on engineering versus meta-engineering (no, it won’t be next week), but the danger is real. For instance, in an article I’ve had in my bookmarks pile for a long while, the author says—

My boss advised me that getting my WPCE (WordPerfect Certified Resource) cert would accomplish two things: 1. It would establish my credibility as a trainer; and 2. If I didn’t know a feature before the test, I sure as heck would afterward.

I’m not going to name the author, because this is his description of thinking through a certification many years ago, rather than his current thinking on certifications—but the example is telling. I know a lot of folks studying for certifications. They mostly spend their time labbing up various protocols and… features. The temptation to focus on features is real because—

  • The test is going to test you on features
  • Learning the features is the fastest way to pass the test

This might sound like a replication, but many certification tests place the candidate on a very tight time leash, which means fast is important. When fast is important, you don’t have time to look up features, or study your options.

So what should we do about all of this?

First, not much can be done. I don’t really know how you write a certification that does not allow someone who has memorized the feature guide to do well. How do you test for protocol theory, and still have a broad enough set of test questions that they cannot be photographed and distributed? The problems here are not as simple as they first seem. The CCDE, I think, comes as close as any test I’ve been involved in to testing theory and concepts, rather than features.

Second, this is why I argue you should get a few certifications, and then go get a college degree. The degree might teach you things you don’t ever think you will need—but this fails to understand the point of a degree. Degree programs should not be designed like a vocational school. They should not be about learning the latest language, but rather about writing skills, thinking skills, and programming skills (in general). A good argument can still be made for a Masters Degree in Computer Science.

Finally, you will get out of certifications what you put into them. If you focus on the features, then you are going to learn the features just fine. If you do this, though, each time a new box comes out your certification will lose a little more value.

Certifications are good, when used right. They can also be “bad,” when used poorly. It’s worth thinking about.

Master of None

Should you be a johnny do-it-all, or so deep that no-one understands what you are saying? It’s time to talk about the shape of knowledge—and how important it is to be intentional about the shape of your knowledge.

Overvaluing Experience

“Sure, great candidate—so long as you just look at the paper. They don’t have any experience.

I wonder how many times I’ve heard this in my networking career—I wonder how many times this has been said about me, in fact, after I’ve walked out of an interview room. We all know the tale of the paper tigers. And we all know how hard it is to land a position without experience, and how hard it is to get experience without landing a job (I have a friend in just this position right now, in fact). But let me tell you a story…

I don’t fish any longer, but I used to fish quite a bit—with my Grandfather. Now, like most Grandfathers, mine was not ordinary. He was, in fact, a County Agent, working for the US Forestry Service. This meant he spent his time blasting ponds, helping farmers figure out how to increase yield on their fields, and growing all sort of odd new types of things on his small plot of land. He also had mules (I’ll tell you about the mules some time later, I’m certain), and an old Forestry Green pickup truck.

Anyway, to return to fishing… He was absolutely no fun to fish with. He would sit down in the chair, cast in, and catch his limit before you could get your first fish on the line. I spent years trying to figure this out. All anyone in my family would tell me was he was a really, really, experience fisherman. I never quite believed this. He would say, “cast in just over there,” and you’d have a hook. Cast anyplace else, and you’d sit there for hours, waiting. I know a lot of experienced fishermen, but his “experience” was something else. In fact, if you ever go out on a lake with a professional or semi-professional fisher-person, you’re going to feel the same way. There’s not just “luck,” and there’s not just “you can case faster and farther than I can.”

Finally, one day I broke down and asked him directly about his fishing abilities. As it turns out, my Grandfather either knew the lay of the land under every lake in the area because he was there before the lake was dammed, or he had actually had a hand in blasting and damming it. In other words, he knew the bottom, the currents, the structure, and all the rest. In the same way, a modern fisher-person will spend hours looking over a map, running around a lake looking at the water temperature in various places, and recording sonar charts to figure out the structure that lays on the bottom of the lake.

Of course, experience matters in fishing. But so does knowledge. And, come to that, so does theory. It’s fine if you have experience fishing, if you don’t know the lake, then you’re not going to get anything on your hook. It’s fine if you know the structure of the lake, but if you don’t understand the way fish act, then you’re still not going to get anything on your hook.

The truth is that it takes all three—experience, knowledge, and theory—to hook a fish. And what’s true of hooking a fish is also true of building a network, or troubleshooting a network, or just about anything else in life. As W. Edwards Deming said—

Experience by itself teaches nothing…Without theory, experience has no meaning. Without theory, one has no questions to ask. Hence without theory there is no learning.

Learn theory, and ask about theory. All the experience in the world isn’t going to teach you anything unless you have a framework from within to ask questions.

What Language Should You Learn?

So you’ve decided, for all the reasons given in my last post on this topic, that you want to learn to code. The next, obvious, question is: what language should you learn? Remember the goal isn’t just to learn to code, but to learn the mindset, tools, and structure of coding; to dog past the simple ability to kick off scripts, and actually pick up an overview of the ground level “stuff” necessary, the “stuff” that is going to transfer from being able to code to being a good engineer. You don’t want to waste your time just learning a new skill, you want to what you learn to intersect with what your main learning goals are in a way that ultimately supports them.

If you’re a bit confused by all this mumbo-jumbo, go back and take a look at one of the first posts on this blog: Jack of All Trades.

To answer the question—which languages should I learn—I need to look beyond what’s “easiest to learn,” or “most popular right now,” or any of the “standard” ways people make this sort of decision. To relate this back to network engineering terms, I want to learn routing, not how to configure it. If I had to choose two languages to learn today to learn, I’d learn C and Python. I’m not choosing those two randomly, or just because those are the two I happen to know pretty well (actually, I’ve coded in Smalltalk, xBase, BASIC, Java, VB, C, Python, and a few others through the years). I have a specific set of reasons for these two languages.

First, this is one compiled language, and on scripting language. The difference between these two is this: a compiled language must be compiled from the base language into assembly to be run. A scripting language, on the other hand (there are other terms here, I’m playing fast and loose with the meaning of the words just to make this simple), runs in a virtual machine, or a virtual environment. Scripting languages must have some sort of environment installed on the machine to run, while compiled languages, when compiled, generate a .exe (or similar) that you can execute from within the operating system.

Why would I choose one of each? Because coding is a different process, and at a different level, in compiled and scripting languages. To code effectively in a compiled language, you actually have to learn something about the way memory is structured in the operating system, how to do the compile, how to step through code that’s been compiled, etc. Scripting tends to hide most of these details from the user, and also works with a much tighter development process. Coding and testing can be less distinct, and the process of building something new is much faster.

Second these do happen to be very popular languages over time. There are a lot of compiled languages out there, but if you look at most of the routing code written and maintained today, you’re going to find most of the commercial, and efficient, code in this area is written in C. It’s invaluable to understand C well enough to be able to read this code base—I keep a copy of the Quagga routing suite on my laptop so I can quickly answer questions about protocol operation from at least one implementation. The scripting world is broad enough there’s much less of a consensus on a single scripting language. On the other hand, Python is a language that has stood the test of time, is useful in a wide variety of situations, and will serve as a solid introduction to other scripting languages. If you can read Python, and you have a fair understanding of C, you can probably make out what a script written in just about any other scripting language is doing.

You should feel free to choose some other set of languages, or perhaps only one. Remember, though, the point here is not to be a great coder, but to simply learn enough to be able to interact with coders, to gain tools you can use in network engineering for automation and other immediate needs, and to gain background knowledge and mental discipline that is going to make you a better network engineer. Given these constraints, you can take your time with learning to code. It might take months or years, or you might just tinker with coding from time to time. You should be perfectly comfortable just learning the tools enough to read through some interesting piece of code, and never even bothering to write anything until something crops up that makes writing new stuff worthwhile.

Coding, as a skill adjacent to network engineering, is worth learning to at least some level.

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.