CONTENT TYPE
Hedge 208: The Internet of Things

The Internet of Things (IoT) has been brewing for many years–but how do all these new devices impact your network? Are there new concepts and architectures you need to learn to get a handle on IoT? Jasbir Singh, author of a new book on IoT architecture, joins Tom and Russ for this episode of the Hedge.
Making Networking Cool Again? (1)
Is network engineering still cool?
It certainly doesn’t seem like it, does it? College admissions seem to be down in the network engineering programs I know of, and networking certifications seem to be down, too. Maybe we’ve just passed the top of the curve, and computer networking skills are just going the way of coopering. Let’s see if we can sort out the nature of this malaise and possible solutions. Fair warning—this is going to take more than one post.
Let’s start here: It could be that computer networking is a solved problem, and we just don’t need network engineers any longer.
I’ve certainly heard people say these kinds of things—for instance, one rather well-known network engineer said, just a few years back, that network engineers would no longer be needed in five years. According to this view, the entire network should be like a car. You get in, turn the key, and it “just works.” There shouldn’t be any excitement or concern about a commodity like transporting packets. Another illustration I’ve heard used is “network bandwidth should just be like computer memory—if you need more, add it.”
Does this really hold, though? Even if we accept the car and computer memory illustrations and individual routers like these things, is an entire network system like a car? A closer analogy for a network in the world of cars would be an entire transportation system.
You have different kinds of physical transport (rail, over-the-road trucks, air travel, ships, etc.), each with its characteristics, and all of which must be connected to move physical objects from one place to another. There must be some kind of “control plane” that coordinates, shared addressing, formatting rules, etc.
While a single car might, in some sense, be a commodity at this point (and I’ll bet there aren’t many car owners who would wholly agree with that characterization), I don’t see how we could call an entire transportation system a commodity—especially if we want to say “the skills needed to build a transportation system just aren’t needed any longer, there’s nothing more to learn, this is so … boring …”
Let’s dispense with this idea that networks just aren’t needed any longer. We must still build networks that carry traffic between servers, cities, countries, and continents. Building these networks is still a hard problem. Even if there is less room to improve these things than ten or twenty years ago, the problems are still hard. Even if many problems are solved at a broad level, not every problem is solved in every network in the universe.
A more reasonable take on this perspective is that networking skills are diffusing into a larger information technology (IT) skill set. Perhaps IT, in its relative “youth,” divided too sharply and finely—we created too many career fields. What is happening right now, then, is just a kind of right sizing in the market.
Network engineering skills, in fact, do seem to be dispersing to one degree or another. But let’s put this in perspective.
The first point is I’m not convinced there are fewer network engineers. Instead, it’s more likely there are just as many network engineers as there ever have been, if not more. Perhaps, though, “real” network engineering has been growing linearly while all the other IT fields have been growing at a rate faster than linear (I don’t want to say exponential, just something more than linear).
In a world that counts lack of growth as a failure, networking growing at a slower pace than, say, programming seems like a failure from the outside. People like to follow winners; growing is winning; network engineering is not growing as fast as other things, so network engineering is failing.
I dislike the modern progressive mindset—but while I’m working on something in this area, this isn’t the time or place to dive into this topic. Let’s agree that we must let go of the idea: “Growing slower is a failure.”
Returning to the idea of transportation—I will just about bet automobile designers built entire departments in the early days of car manufacturing. Today, there might be just as many automobile designers as ever. They’re just buried in large car manufacturing, servicing, etc., companies, so it feels like there are a lot fewer than there were.
Just because most new engineers must learn many different things, and network engineering skills are diffusing into many different areas of IT, does not mean network engineering is dying, regardless of what it might look like from the outside.
Second, there is nothing wrong with network engineering skills diffusing into the larger IT skill set. Has anyone reading this ever really been a “pure” network engineer? If so, I don’t know whether to envy or feel sorry for you.
When building networks in the military, I had to deal with all the politics of customer relationships and understanding mission needs. When taking cases in technical support, I had to deal with time management and customer-facing skills—and I needed to learn or use coding skills to be an effective network engineer. Today, I do network engineering, like I always have, but I work on security, privacy, DNS, coding, and all sorts of other things.
I cannot think of a time in my career when I would have considered myself a “pure network engineer.” I’ve always had to find and build adjacent skills to design, build, and maintain networks. I would say this is truer today than ever, but I do not believe my skills as a network engineer are any less useful than they have ever been.
Where does all of this leave us?
Let’s continue the discussion in part 2 next week.
Hedge 207: Being a Network Engineer with Phil Grevasi

What does it mean to be a network engineer in today’s world of information technology? Phil Gervasi joins Tom and Russ to discuss the ins and outs of network engineering, and what it’s really like to be in this small corner of information technology today.
download
Hedge 206: Taking Care of Yourself with Ethan Banks
As we reach the end of what has been a hard two-year stretch for what seems like the entire world, Ethan Banks joins Tom, Eyvonne, and Russ to talk about the importance of taking care of yourself. In the midst of radical changes, you can apply self-discipline to make your little part of the world a better place by keeping yourself sane, fit, and well-rested.
Hedge 205: Old Engineering Books (2)
For this month’s roundtable, Eyvonne, Tom, and I return to Addresses to Engineering Students by Harrington and Waddell. This book, published in 1912, is a “product of its time,” and hence deserves some trigger warnings. But it is also interesting to see how advice given to engineering students over 100 years ago holds up for today. Have engineering challenges, and the engineering life, changed all that much? What kinds of advice stand the test of time, what kinds do not?
Hedge 204: Terry Slattery on Network Automation
Terry Slattery joins Tom and Russ to continue the conversation on network automation—and why networks are not as automated as they should be. This is part one of a two-part series; the first part of this conversation was posted as episode 203.
Hedge 203: Terry Slattery on Network Automation

Terry Slattery joins Tom and Russ to continue the conversation on network automation—and why networks are not as automated as they should be. This is part one of a two-part series; the second part will be published in two weeks as Hedge episode 204.
