Russ

Author Archives: Russ

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.

career-01Anyway, to return to Continue reading

BGP Code Dive (1)

I often tell network engineers they need to learn to code—and they sometimes take my advice and run off to buy a book, or start an online program (which reminds me, I’m way, way behind in my own studies about right now). But learning to code, and being able to use that skill for anything are actually two different things. In fact, my major problem with my coding skills is finding projects I can undertake where I don’t feel like I’m wasting my time. Anyone want to write the world’s 25 millionth implementation of inserting the date and time into a document? No, I didn’t really think so.

code-diveSo what can you do with coding skills? One thing you can do is <em?read the source. Thus, I’m starting an entirely new feature here at ‘net Work. Every now and again (which means I don’t know how often), I’m going to poke at some routing or control plane code or another, and try to figure out what it actually does. Why not just go through a single protocol line by line? Because—honestly—it’s not a useful way to approach a protocol in code. Rather—here is my first bit of advice—you want Continue reading

On differential privacy

Over the past several weeks, there’s been a lot of talk about something called “differential privacy.” What does this mean, how does it work, and… Is it really going to be effective? The basic concept is this: the reason people can identify you, personally, from data collected off your phone, searches, web browser configuration, computer configuration, etc., is you do things just different enough from other people to create a pattern through cyber space (or rather data exhaust). Someone looking hard enough can figure out who “you” are by figuring out patterns you don’t even think about—you always install the same sorts of software/plugins, you always take the same path to work, you always make the same typing mistake, etc.

The idea behind differential security, considered here by Bruce Schneier, here, and here, is that you can inject noise into the data collection process that doesn’t impact the quality of the data for the intended use, while it does prevent any particular individual from being identified. If this nut can be cracked, it would be a major boon for online privacy—and this is a nut that deserves some serious cracking.

But I doubt it can actually be cracked Continue reading

Reaction: Complexity Sells

Over at IPSpace this last week, Ivan pointed to a paper by Dijkstra (and if you don’t know who that is, you need to learn a thing or two about the history of routing protocols—because history makes culture, and culture matters—or, as the tagline on this blog says, culture eats technology for breakfast). In this paper, Dijkstra points out some rather important things about computer science and programming that can be directly applied to the network engineering world. For instance, Ivan says—

People tend to forget that “doing away with the programmer” was COBOL’s major original objective. —Replace “programmer” with “networking engineer” and COBOL with SDN ?

I was fascinated with Ivan’s take on this paper—particularly in that complexity is an area I find interesting and very useful in my everyday life as a designer—that I went and read the original article. You should, too.

I think Ivan’s observations are spot on, but I think it’s worthwhile to actually broaden them. From where I sit, after 25 years building and breaking networks, I agree that complexity sells—but it sells for two particular reasons. The reason, as Dijkstra said all those years ago (in computer terms), is this:

Since the Continue reading