It’s time to wrap up my thoughts on the question raised in this series of posts. If you haven’t already ready them, please do go back and check out what came before now:
- The original post: Grumpy Old Man – Youngsters Today
- Are Younger Engineers Dumb? Part 1
- Are Younger Engineers Dumb? Part 2
So to the crux of the matter; are these younger engineers stupid or what?
No, they’re not, but they bring something different to the table.
If I decide to define stupidity as somebody not knowing what I know, then many of the younger engineers I speak to are indeed stupid; but that’s not really a fair way to look at it. What they bring is a different skill set. While I would argue that my knowledge is superior in many ways to the generation that came before me, I suspect that the next generation feels exactly the same way. Neither of us is right or wrong, because each of us has a different, if overlapping skill set:
In fact, it could be argued that the knowledge held by the Whipper Snappers is in fact entirely a subset of the Old Folks with Sandals. There may be a bit of both going on, depending on the person and the specific knowledge.
Window of Knowledge
I figure that there’s what I’ll call a “Window of Knowledge” that can realistically be sustained in a typical network engineering department. The Window of Knowledge (which I’ll abbreviate to WoK at times) represents, at the lower end, the oldest information that’s currently understood by somebody, and the upper end represents the cutting edge knowledge that’s being looked into. Somewhere in the middle are the currently-deployed networking technologies; those that are active on the supported network.
Predictably, a Tier 3 engineer would have a wider WoK than somebody who just started in networking, because they’ve been around longer. If we take a snapshot in time, we might expect the Windows of Knowledge of the three engineer tiers to look something like this:
However, time does not stay still. The currently deployed technologies keep on advancing, older engineers keep retiring, and new folks keep on coming in. So if we look at the typical WoK of a Tier 3 engineer at different times, we might see thing changing along these lines (with the x-axis now representing time):
What this means is that as time goes on, we will lose the oldest knowledge from our teams. Newer team members will mostly likely never learn the older technologies and, let’s face it, why should they? Things have moved on in the marketplace, haven’t they?
The Important Things
What all this means is that we can’t expect somebody new to the industry to know old information – their Window of Knowledge simply doesn’t allow it. So if we can’t simply judge an engineer on that “old” knowledge, then what’s important? What I’m looking for is the ability to interpret information. Perhaps if I explain how something works, the candidate will be able to make inferences from that and perhaps predict behavior as a result? In fact throughout an interview I’ll try and see how the candidate can take the information we’re discussing and extend it (even if that information is wrong – I love it when a candidate says “Wait, that can’t be right…” because it means they are able to process information and realize that something’s wrong! That skill is worth as much as the knowledge itself.
The Impact of SDN
So what happens to these Windows of Knowledge when Software Designed Networking (SDN) comes into the picture? Now things are more confused because you can hide a lifetime of technical knowledge behind a script that’s provided for you. Tier 1 engineers in an SDN environment run the risk of being reliant on the automation provided and having little real understanding of the underlying network. When it’s relatively easy to master controlling the network at Tier 1 what’s the differentiator for Tier 2? In 10 years’ time, will Tier 3 have any underlying knowledge at all, if the network was obscured from them when they were Tier 1 engineers? Naturally, I’m playing devil’s advocate here and assuming that we move to a 100% SDN world, but this isn’t entirely unrealistic.
While I make these points, note that I’m carefully ignoring the world of DevOps. Somebody has to develop the code that makes the network function, right? Somebody writes that GUI for you; somebody programs the network equipment. Without question, networking skills will be needed, but it may well be a different blend of skills required to execute coding. At first when protocols like OpenFlow became well known, the claim was that you could write your own networking code. Big fat whoop. In 99% of environments, who the heck wants to have to do that? You want a vendor to do that for you; a vendor you can call to the mat when it doesn’t work. Yes, the Googles and Amazons of this world have the kind of dev teams that can take on this task, but the average enterprise really doesn’t, in my opinion, and indeed they shouldn’t try. It’s not their sweet spot.
Back on Topic
So, the younger engineers aren’t stupid. They bring a set of skills to the table with a more recent memory for sure. Some may also bring modern coding skills to the table, and while coding is not exclusively a ‘young’ thing, there’s a higher chance they’ll have learned Python or Ruby rather than something older. What’s for sure is that interviewing younger engineers is a challenge. We need to understand not only how we can use these newer skills, but how to successfully determine if the candidate truly has them.
Maybe then a better question would be “Are Older Engineers Out of Touch?”
I’ll leave that one dangling out there for now, and welcome your comments.