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?
TLDR
No, they’re not, but they bring something different to the table.
Stupidity
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.
I have many concerns regarding how we transition future help desk and entry level networking techs into roles of architects and experts. The question is how much foundational knowledge will always be required, and how is it obtained in an automated environment.
Indeed, Paul, and thanks for sharing your thoughts. I think this is going to be a challenge, and as the older guys with sandals, I think we have to bear some responsibility for figuring out how we pass down knowledge. Whenever we figure out what needs to be passed down, that is…
I liked the comments about juniors stating “no, that can’t be right…” when working through a question.
One of my favourite interview questions is when discussing port address translation, “how does the router know which session belongs to which host internally?” If they answer the source/destination tcp/udp ports, I follow up with “does Ping work with PAT?” Why, or why not?
At that point I don’t care if they get the answer right – it’s a bit trivial. I would rather them come up with the wrong answer and right way of thinking about it than coming up with the right answer with the wrong rationale.
Thanks for the insight, Serge. I agree – it’s as much about whether you can figure out the logic of a situation as whether you know a specific detail. Being able to process things logically is something you can apply to new subjects too!
So what is the best, most shining example of our generation of network engineering? Netflix? I don’t think we’ve set the bar too high for the next generation.
I personally give ARP no more than 20 years before it’s obviated — if the next generation can’t come up with something more interesting than IP then shame on them. But give them a few years. Why do we all know ARP anyway (answer: because we had to?) And so what? I bet even less of us know the electrical characteristics of copper-based ethernet. But I don’t often feel guilty not knowing. (If I do, I just launch nexfllix for a few episodes of Upstairs, Downstairs, and then I know my place).
I like thinking “what if” when talking about the next generation (my daughter is hot on my heels, so it’s germane): what if we’d started with OC3 everywhere instead of 56K? What if we’d started with encryption being a commodity item? What if we’d started with this whole concept of social connections driving our weltanschauung? What if all the best compilers and IDE’s were free and could be downloaded in under a minute? That is the charge for the next generation.
I’m looking forward to retirement, and am optimistic. Now where are my sandals, know I left them somewhere….
Well in fact, ARP will go out the window along with IPv4. Oh wait, your 20 year estimate may have just gained credibility! IPv6 uses Neighbor Solicitation instead of ARP, so the next generation of address resolution is already upon us.
As to why we know ARP, as I think you’re suggesting, we know it because we have to. Why do we have to? Because it’s something that ended up being used in troubleshooting a lot. As I’ve suggested in these posts, once something becomes so reliable you rarely need to even know it’s there, it becomes taken for granted, just like those electrical characteristics you mention. Over time we naturally get further away from the most fundamental information and focus our attention on the higher level stuff that runs on top of it.
I’m not quite ready to be mothballed, but I have a secret store of sandals ready to go when I am. 😉
oh please, when “you old guys” were doing tier 1 stuff you were doing basic things like changing tape reels and making sure the mainframe jobs were being printed. Tier 1 is just that, kids learning slowly from the people who’ve been there for awhile. The problem today is that you sandal wearing old people see certs and assume the candidate is good, not realizing that the candidates are just good at taking tests. Gauging something as silly as PAT mechanisms in an interview – not too sure I’d want to work for someone who asked that during my interview (even though the answer to that is cake). For tier 1, you essentially want to get someone who is eager to learn, and could follow instructions.
As a parent, I’d have to say “hmm, well – if you think the new network engineers suck, then lets take a second look at the people who are supposed to be mentoring them.”
We do? I hadn’t realized. You might want to read my post about the value of the CCIE certification and see if you think that’s true in my case at least. I’ve met enough idiots with certs, and experts without, to be appropriately cynical about certifications.
That’s true at Tier 1, and you expect to have to mentor those people and train them up. The first post I made on this subject – which spawned the follow ups – addressed the question of what knowledge candidates should have when interviewing for a Senior Network Engineer position, not Tier 1 though.
I can’t speak for the mentoring abilities of person they work for prior to coming to interview with me. Maybe what we’re seeing are people with “paper certifications” applying for jobs that stretch way beyond their experience. After all, the very reason we ask questions in interviews is to gauge somebody’s real abilities. If we believe so blindly in certifications, we wouldn’t need to interview half the candidates and would just give them the job based on the letter groupings on their resumés.
Why not? Explaining PAT is beneath you in some way? Whether PAT or ARP are good topics for an interview question is highly subjective; maybe the interviewer is less interested in your technical understanding of PAT and more in how well you can communicate?