An old networking friend whom I mentored for his CCIE a long time ago wrote me an email: I’ve been a CCIE for 10 years now, he said, and I’m feeling like a dinosaur. Everyone wants people who know AWS and automation and they don’t want old-school CLI guys.
It takes me back to a moment in my career that has always stuck with me. I was in my early twenties at my first job as a full-time network engineer. I was working at the San Francisco Chronicle, at the time (early 2000’s) a large newspaper with a wide circulation. The company had a large newsroom, a huge advertising call center, three printing plants, and numerous circulation offices across the bay area. We had IP, IPX, AppleTalk and SNA on the network, typical of the multi-protocol environments of the time.
My colleague Tony and I were up in the MIS area on the second floor of the old Chronicle building on 5th and Mission St. in downtown San Francisco. The area we were in contained armies of mainframe programmers, looking at the black screens of COBOL code that were the backbone of the newspaper systems in those days. Most of the programmers were in their fifties, with gray hair and beards. Tony and I were young, and TCP/IP networking was new to these guys.
I was telling Tony how I always wanted to be technical. I loved CLI, and it was good at it. I was working on my first CCIE. I was at the top of my game, and if any weird problem cropped up on our network I dove in and got it fixed, no matter how hard. As I explained to Tony, this was all I wanted to do in my career, to be a CLI guy, working with Cisco routers and switches.
Tony gestured at the mainframe programmers, sitting in their cubes typing their COBOL. “Is this what you want to be when you’re in your fifties,” he said under his breath, “a dinosaur? Do you just want to be typing obscure code into systems that are probably going to be one step away from being shut down? How long do you think these guys will have their jobs anyways?”
Well, I haven’t been to the Chronicle in a while but those jobs are almost certainly gone. Fortunately for the COBOL guys, they’re all retirement age anyways.
We live in a world and an industry that worships the young and the new. If you’re in your twenties, and totally current on the latest DevOps tools, be warned: someday you’ll be in your forties and people will think DevOps is for dinosaurs. The tech industry is under constant pressure to innovate, and innovating usually means getting machines to do things people used to do. This is why some tech titans are pushing for universal basic income. They realize that their innovations eliminate jobs at such a rate that people won’t be able to afford to live anymore. I think it’s a terrible idea, but that’s a subject for another post. The point is, in this industry, when you think you’ve mastered something and are relevant, be ready: your obsolescence commeth.
This is an inversion of the natural respect for age and experience we’ve had throughout human history. I don’t say this as a 40-something feeling some bitterness for the changes to his industry; in fact, I actually had this thought when I was much younger. In the West, at least, in the 1960’s there developed a sense that, to paraphrase Hunter Thompson, old is evil. This was of course born from legitimately bad things that were perpetuated by previous generations, but it’s interesting to see how the attitude has taken hold in every aspect of our culture. If you look at medieval guilds, the idea was that the young spent years going through apprentice and journeyman stages before being considered a master of their craft. This system is still in place in many trades that do not experience innovation at the rate of our industry, and there is a lot to be said for it. The older members of the trade get security and the younger get experience.
I’ve written a bit about the relevance of the CCIE, and of networking skills in general, in the new age. Are we becoming the COBOL programmers of the early 2000’s? Is investing in networking skills about the same as studying mainframe programming back then, a waste of cycles on dying systems?
I’ve made the point many times on this blog that I don’t think that’s (yet) the case. At the end of the day, we still need to move packets around, and we’re still doing it in much the same way as we did in 1995. Most of the protocols are the same, and even the newer ones like VXLAN are not that different from the old ones. Silicon improves, speeds increase, but fundamentally we’re still doing the same thing. What changing is how we’re managing those systems, and as I say in my presentations, that’s not a bad thing. Using Notepad to copy/paste across a large number of devices is not a good use of network engineers’ time. Automating can indeed help us to do things better and focus on what matters.
I’ve often used the example of airline pilots. A modern airplane cockpit looks totally different from a cockpit in the 1980’s or even 1990’s. The old dials and switches have been replaced by LCD panels and much greater automation. And yet we still have pilots, and the pilot today still needs to understand engine systems, weather, aerodynamics, and navigation. What’s changed is how that pilot interacts with the machine. As a pilot myself, I can tell you how much better a glass cockpit is than the old dials. I get better information presented in a much more useful way and don’t have to waste my time on unnecessary tasks. This is how network automation should work.
When I raised this point to some customer execs at a recent briefing, one of them said that the pilots could be eliminated since automation is so good now. I’m skeptical we will ever reach that level of automation, despite the futurists’ love of making such predictions. The pilots aren’t there for the 99% of the time when things work as expected, but for the 1% when they don’t, and it will be a long time, if ever, before AI can make judgement calls like a human can. And in order to make those 1% of calls, the pilots need to be flying the 99% of the time when it’s routine, so they know what to do.
So, are we dinosaurs? Are we the COBOL programmers of the late 2010’s, ready to be eliminated in the next wave of layoffs? I don’t think so, but we have to adapt. We need to learn the glass cockpit. We need to stay on top of developments, and learn how those developments help us to manage the systems we know well how to manage. Mainframes and operating systems will come and go, but interconnecting those systems will still be relevant for a long time.
Meanwhile, an SVP at Cisco told me he saw someone with a ballcap at Cisco Live: “Make CLI Great Again”. Gotta love that. Some dinosaurs don’t want to go extinct.
3 Comments
Wonderful post! As a circa ’94 Network Engineer who got his start as an 18 year old Mainframe Operator in the Marine Corps and obtained my CCIE in 2006, this hits very close to home! The last few years has led me towards management and business development, though my heart still beats to the tune of ones and zeros. While I have authored winning proposals and CONOPS on Service Automation and NFV, I have yet to personally deploy service orchestration at scale. There is hope! I have recently built a new hybrid cloud lab with plenty of storage and compute resources to spin up anything I can dream up. The last 15 years after having children, my RSVP-TE agent (wife) assigned lab funds as scavenger class, discard eligible while soccer, school and home improvements were guaranteed assured forwarding with flash override :p That, and prioritization of that most precious resource, (time) to ensure all required endpoints (family) are not starved of resource allocation is a challenge that no amount of AI will ever solve. Love your blog – Look forward to reading more!
Prior to my CCIE I spent 5 years writing code. 1997: All the new Object Programming Languages were coming out and IDE’s and I was a huge Delphi / Object Pascal guy. Then Microsoft decided that this was something they wanted to do, and Boreland went out of business in a year or two.
Everything I hated about programming, all the bugs, endlessly trying to please users with their unreasonable expectations, hundreds of hours poured into tiny successes, were simplified for me when I learned CLI, and started into networking.
I escaped a life of being a Microsoft Visual XYZ coder to become a CCIE, learn CLI. I left Delphi and Object Pascal 20 years ago, to delve into OSPF, EIGRP, BGP, IPX, VOIP, and master the IOS CLI. And now Cisco wants me to learn Yang / Conf / Perl / etc ?
As of right now I think most of your audience is just Developers looking to get CCIE money. I sit in a room full of developers. I have no need to learn any of those languages. If I need something written it would be a colossal waste of my time to try to write it. Either someone else already has, and I can just download their code, or the guy behind me will do it in 4 hours add about 15 features I didn’t ask for, and be super excited he was able to Dev on the Network.
Essentially this isn’t replacing the CLI Master, this is adding a Dev to the Network team. I pay Cisco good money to write IOS / IOS XE. I might use an overlay tool to rapidly and accurately deploy code, but I have no intention of writing my own DNA Center.
Thanks for your comment Brian!
First of all, Cisco doesn’t “want” you to learn YANG or NETCONF. We’ve found that there is a huge demand for programmable interfaces from our customers, and so we are implementing them and doing everything we can to help network engineers take advantage of them. It’s really up to you whether you think that NETCONF/YANG or similar APIs are a good use of your time.
I actually share your experience. I took a couple programming courses in college and hated it. I got into network engineering because, as you say, I could focus on protocols and just making stuff work, and I left the coding to others. When I came back to Cisco in 2015, I kind of fell into programmability. The way I look at it is this–there are a lot of tasks that we do repeatedly as network engineers with basically no automation. We use tools like Notepad to automate. If we have the capability to eliminate repetitive tasks with machine interfaces like YANG or tools like Ansible, why not do it?
Despite being focused on programmability for several years now, my own coding skills are not great. I make a point of emphasizing that at Cisco Live and elsewhere. I’m not a coder. I don’t want to be a coder. I want to learn the minimum skills needed to make some stuff I do easier. My audience is not developers at all. My book, my Cisco Live sessions, all the work I do is targeted at network engineers, and my point to them is to stay network engineers. You can’t do anything with NETCONF/YANG if you don’t know what it is you are automating.
Meanwhile, you don’t have to write Cisco DNA Center! I agree, let it do the work for you! That’s a perfectly acceptable way to deploy and automate your network. We’re just giving you options. Choose the option you want.
If you are coming to Cisco Live San Diego, please check out my session BRKCRT-3075, “The CCIE in an SDN World”. I’d really like you to hear my presentation and perhaps have a chat afterwards.
All the best.