The Art of Network Engineering
Join us as we explore the world of Network Engineering! In each episode, we explore new topics, talk about technology, and interview people in our industry. We peek behind the curtain and get insights into what it's like being a network engineer - and spoiler alert - it's different for everyone!
For more information check out our website https://artofnetworkengineering.com | Be sure to follow us on Twitter and Instagram as well @artofneteng | Co-Host Twitter Handle: Andy @andylapteff
The Art of Network Engineering
Is Network Automation Worth the Struggle?
Network automation remains one of the most polarizing topics in our industry. Despite years of being told it will revolutionize our work, actual adoption rates hover around a dismal 20-30%. Why the resistance? And is there finally a path forward that makes sense for everyday network engineers?
In this candid conversation with Jeff Clark and Colin Doyle, we dive deep into the psychological and practical barriers that keep most engineers firmly rooted in traditional networking practices. Jeff shares how his "selfish automation" approach transformed a tedious 15-minute ticket process into a 30-second task, while Colin explores how modern intent-based networking is fundamentally changing what network automation means.
The truth emerges that resistance isn't just about technical challenges—it's about cognitive biases like loss aversion and fear of job displacement. We confront the paradox that many engineers chose networking specifically to avoid coding, only to find programming skills becoming increasingly essential for career advancement.
What makes this conversation different is our focus on practical, accessible starting points rather than theoretical ideals. You'll learn why small, personal projects that solve your immediate problems are the gateway to building automation skills, and how communities of practice can provide the support and accountability needed to progress.
Whether you're automation-curious or automation-resistant, this episode offers a refreshing perspective on how to approach this inevitable shift in our field. The future of networking isn't about replacing engineers with code—it's about freeing engineers to focus on what matters most.
Find everything AONE right here: https://linktr.ee/artofneteng
This is the Art of Network Engineering, where technology meets the human side of IT. Whether you're scaling networks, solving problems or shaping your career, we've got the insights, stories and tips to keep you ahead in the ever-evolving world of networking. Welcome to the Art of Network Engineering podcast. My name is Andy Laptev and this episode I am joined by two friends, two smart gents. I have worked with them both in the past. I work with one now. I'm hoping to work with the other one soon. Maybe I'm working with him now and don't even know it. Where are we going to start? So let's start with former guest of the show, jeff Clark. How are you doing, jeff?
Speaker 2:No complaints. I mean I'm glad to be here, it's exciting.
Speaker 1:Thanks for coming back. I went back. I don't know if your episode was like 30 something or 40 something. It was pretty early on Four to Jeff and the.
Speaker 2:Ford camper.
Speaker 1:Yeah, how have things been? Anything new? You're still just four to everything in the Ford camper and everything's good.
Speaker 2:I feel like everything is different every single day, but it's also kind of the same. Everything's unexpected, but you just start rolling with the punches. That's kind of just the SE gig in general, though, is it's a lot of you're telling the same story, but getting different questions and getting to figure out how to answer differently. But no, it's, it's good. It feels like time's flying by them. 2025. I can't believe that 2024 is over. It felt like it just started a couple of weeks ago.
Speaker 1:It ago. It did Well, Jeff. Thanks for coming back on. It's great to see you again, Colin Doyle.
Speaker 3:Colin. Hello friend. Where do you work? What do you do? How are you? I work at Nokia. I'm a principal consulting engineer, which is just a jumble of words. That means I work in the data center practice. As we start to buff and build out that muscle.
Speaker 1:Principal, that sounds fancy.
Speaker 3:It did sound fancy, I remember when I got that title and I'm like this is good. I don't know, there's certain I've always felt like the shorter your title, probably the more important you are. But when you like, there are certain words, like principal, where I'm like ooh, that's neat. That means I can suspend children from school now.
Speaker 1:All right, fellas. Well, thanks for being here. The real reason we're here. Right, let's get into this. Let's let these people into the fun.
Speaker 1:We've been hearing about it forever, right? Network automation it's going to revolutionize networking. It's going to make our lives easier, right, we're going to break stuff less. We're going to eliminate mundane tasks. We're going to free our people up to work on higher value things. If you can't sense the sarcasm in my voice, it's there. And yet here we are. Right, decades later, adoption rates are low.
Speaker 1:I forget the last time I looked at the data, I don't know somewhere around 20 or 30%, and of that it's minimal stuff. It's like I don't know, other than the hyperscalers that have automated everything, the rest of the industry is pretty piss poor as far as level of automation. I mean, we're still managing our networks the old-fashioned way. In my 15 years managing production networks, I managed networks the old-fashioned way, right? But here we are still being told network automation it was supposed to be the next big thing, right? There's always this next big thing in tech. You know what I mean. I don't want to draw this parallel because we've had an IPv6 episode and my mind was changed by the end of that. But IPv6 global adoption we're at like 37%. 20 years ago it was released and we better do it before the internet breaks.
Speaker 1:Maybe not right? So that was the next big thing we had to do. Y2k all the planes are going to fall out of the sky, are they really Okay? So I'm going to say something, I guess provocative, inflammatory, here to get the conversation started. Network automation it's a failed passion project. Right? These DevOps nerds, these coders who for some reason didn't go into networking, decided that they're going to tell us and they're going to convince vendors and they're going to tell the world, like these network people who have been avoiding coding all this time, they need to code, they need to automate. You know, aren't networks good enough? Right? If we want to go fast, can't we just go use the cloud? So, guys like, prove me wrong. I am the voice of the industry, the 70% of the industry that refuses to automate anything in 2025, right, prove me wrong. Why are my beliefs twisted? Where can we start?
Speaker 2:So I'll kick this off partly by saying I think what ends up happening is, when we talk about automation, I think everybody kind of puts Python up on the pedestal. Right, it's the, oh, it's Python or Ansible, or it's this, we've got to automate it that way, and then everything has to be automated. What we fail to realize is that automation has happened around us and we didn't even know it. I spend at least 60, maybe 70% of my time in a GUI, and a GUI is realistically just somebody else's automation tools. Right, it's somebody else's macros. So I mean, I work for Fortinet, so I build a VPN. Instead of going in and entering all the commands to build a VPN manually, I'm using some semblance of a wizard that's telling you hey, you know, you've got to remember that. You know, in addition to this bit and this bit, you need to also know that you're going to be doing this pre-shared key and you're going to be doing this type of encryption. You're doing that and it's a wizard that walks me through it. In reality, that's network automation. We don't call it network automation, we call it central management, we call it single pane of glass, but. But in reality it's network automation. It's just become so mainstream that we don't even look at it that way, then I think we also we need to look at regular automation tools like writing scripts, which is probably more of what you're talking about. You know scripting and that kind of stuff.
Speaker 2:We're also living in a time where it is easier than ever to learn it.
Speaker 2:I mean yesterday, when I found out that we were doing this, or the day before, I went into chat GPT and literally my prompt was literally I don't know anything about Ansible. I want you to function as an Ansible teacher and help me write my first script. And at the end of the day, I now have a script that creates a virtual machine in GNS3 for me. It goes to the licensing software that I use here at Fortinet gets a license for me. The licensing software that I use here at Fortinet gets a license for me. It finds the first available IP address on my network and it adds a DNS entry for that host name that I create for the endpoint, and it does it in about five seconds, and that was something that used to take me about three minutes. So it's not like I changed the world with this, but I learned a bunch of stuff and it was really easy to do. So my argument is automation is already around us and it's easier to learn than ever. So I don't, I mean.
Speaker 1:So you created a playbook in Ansible, correct, I did.
Speaker 2:Yeah, I didn't know what that was until yesterday.
Speaker 1:And how long? What was the process of? Because, honestly in the time, so 2025, right, like LLM's chat, gpt just kind of kicked off and got mainstream. I don't even remember. Was it a year ago? Is it longer, shorter? It seems like it's been here forever, but it hasn't been that long like year-ish.
Speaker 1:So when I was in production trying to learn automation, that wasn't an option. So I actually liked that use case. I was trying to you know Kirk Byers Python thing, and then he says, well, if you've never touched it, you got to do this pre thing. And that's 187 page book and like 100 days of code. Like there's just all these python courses.
Speaker 1:And again me and a lot of my colleagues struggled with, like I think it's the layers of abstraction that I've always gotten lost in, like I get it. Like when I see it and somebody walks me through it, I I'm not dumb, I understand what's happening, but for me to sit down and write it and get it all right and call the variables and and get the logic right and know where to pull and what library to like it just. And then, well, you know, do I use VS code? And then, well, am I supposed to have this in GitHub? And like what repository? And oh, and then there's, there's, there's dependencies, right, like you have to do something with. Like I forget what the Things can break, and like.
Speaker 1:So we say I'm not undermining what you just said, but we say how easy automation is, at least in Python. The more you learn, the deeper you go and the more kind of harder it gets, at least in my experience and opinion. So I like Ansible because Ansible is a really easy entry right, like it's not that hard to create a playbook and you have a config file and you know. Just tell it what you want it to do. But I kind of like that To your point. So in the chat Daniel Pelfrey says Ansible is your friend, it beats using expect scripts. And then some guy AMW Film Ansible is amazing.
Speaker 3:I've been using it on servers. Next step is to use it on my networks, colin. Well, I think that there's some decision paralysis which you're touching on now. If somebody hasn't engaged in automation, the tool landscape is rather complex and if you don't benefit from some sort of reference, either within your own organization or through your own experience, it can be overwhelming. Python is an easy place to start, but Python in and of itself is just a language library that has a runtime, so you still have to wrap around that your own experience and then set it up in a way that's going to interact with your network devices.
Speaker 3:Even now, I'm considering what the problem in networking has been. Guys, I think the call is coming from inside the house, I think it's us, I think it is networks, and I think we're starting to see a change now with some of the tooling that's coming out things like Terraform and more intent-based networking. Some of the tooling that's coming out things like Terraform and more intent-based networking, the meaningful automation, the ones that actually get investment from large organizations, like the very large enterprises that actually do automate are based on treating the network not as its own entity that exists for its own sake, but making it centric to what the network is actually there to do and that is provide services to hosts that are connected to it and connect those applications to each other and back to those users. So that's also, I think we see more automation in a WAN environment with service providers, because it's a much easier ecosystem to make sense of in terms of how you're doing service delivery and provisioning system to make sense of in terms of how you're doing service delivery and provisioning, and in the data center, where the common reference architecture that EVPN VXLAN offers is more homogenous with the intent tools.
Speaker 3:A lot of every DC control point these days has some form of intent. There's a rich conversation to be had about what intent actually means. You need to be able to trust the network to do what you tell it to do. If you're going to do meaningful automation, if you're going to have the network programmed in service of the things that use the network, you need to trust the network is not going to break itself. I know that there's statistics in the data center. If you take out power and transceiver failures, we break the network. It's an unintended consequence.
Speaker 3:So you think, about what a maintenance window is. All a maintenance window is it's an amount of time you give yourself to make sure that the thing you're going to do didn't break something else you didn't mean to break and you fix it before that window ends whatever you broke right.
Speaker 1:Permission to break things and fix them in a certain time period. Real automation shouldn't require can't I would actually say it can't require a maintenance window, it cannot Hold on, hold on. What do you mean? Real automation, right I?
Speaker 3:say. When I say I'm sorry, if you're automating something that is programming the network and you need to take a maintenance window to do it, then I suppose what I'm saying is that it's not real automation, but it kind of falls into two categories. There's procedural automation, which is the things like Ansible, and if you're writing Python scripts and then if you play with it long enough or you start with the correct framework like Terraform, there's declarative automation, and procedural automation is just going to save you a lot of typing. Generally I I've got something I'm going to do a hundred times. I need to push this new VLAN provision of VLAN in a campus network. It's good for that because human error is a real thing and if I have to type something a hundred times, I'm probably going to mistype it at least once or twice. So there is value there.
Speaker 3:When I'm looking at the enterprise no-transcript talented resource pool but limited resources like funding or access to heart I'm talking about higher ed Let me just cut to the end of the story here and a lot of their focus was how do I turn a these common workflows into a self service workflow that somebody can now go and self provision, a wireless network for the SSID or something for their dorm right, self provision, a temporary key for the wireless if they have somebody sticking a stay.
Speaker 3:So what's changing right now is, I think the tooling that allows us to manage networks with declarative automation and intent are getting better, which means that any of the automation we put over the top of network management can now be rightly considered to be a far more reliable source of truth. And when that happens, you get to do some magical things where you have the users or you have the applications that use the network, telling the network what they need, instead of somebody opening up a ticket and then people having to work together and try to build a workflow which in and of itself can be repetitive. I feel like I've gone far afield, so I'm going to stop for a second. But this is just that's. The inflection point I think we're at right now is just the tooling itself and the frameworks we're using are starting to shift.
Speaker 1:I want to park there just for a second and then, jeff, I'm going to, I'm going to hand it off to you because I see you have something to say. So I think something important. You said no-transcript and that's what we did, and then I think, two maintenance windows, we banged it all out. But I wanted to mention you walk through the continuum of something like that, like automate a thing, with something that types faster for you and pushes it faster for you too, the intent, declarative stuff. And I guess you said source of truth, right, what I keep going back to in these conversations. You ended at the promised land I of like push button, get banana, the 80 percent, let's say 70 percent, of the networks that haven't automated anything.
Speaker 1:I think there's a cultural component that you called out, right the. The people like me who failed computer science in the 90s didn't want to go into programming, got into networking instead because there was no programming and the jokes on me, haha, I have to learn programming. So I avoided it as long as I could until I couldn't anymore. But in places I've worked, our vlans are housed in spreadsheets. Our ipam may or may not be accurate. There is no source of truth for anything. The ip address is discontiguous everywhere. We just had a merger and now we have overlapping ip space and a firewall in between us netting their 10 dot to our 10. Like you know, we're in multi-cloud where everything's everywhere. Like these environments are complex, they're crazy, they're nuts and it would be great to be start at the end, state right, build it all, greenfield push button, get banana.
Speaker 1:My experience and I don't know if this is what's feeding into why it's so slow to be adopted is there's so much technical debt out there. You had mentioned we were talking on the side like automation will not fix technical debt and I was working four maintenance windows a week. I worked 26 Sunday maintenance windows one year, which were like six hour windows that span Saturday night into late Sunday and if anything broke I was on the phone all day Monday, right, like I was drowning in work and exhausted just keeping the lights on. Now I know that automation in theory can get us to. I can be more efficient, I don't have to work as many maintenance windows, we can push services faster, but I don't know how organizations get from. I'm drowning in debt, I'm working round the clock to keep the lights on and now I have to automate stuff. I just.
Speaker 1:For me it seemed like too much. It was a straw that broke the camel's back. It was like I don't want to work in networking anymore because I can't freaking believe. Now I have to be a coder. Jeff, I didn't mean to cut you off.
Speaker 2:So actually, daniel, in the chat already hit upon it, which is, I think you have to start small. I mean, colin, I agree with what he's saying, that the ultimate goal is to automate everything and have it all push button, get banana. But, um, this is. I've been doing some semblance of network automation or automation, uh, for my entire professional career, but I haven't been doing it with the intent of making everybody else's job easier. I've been doing it with the intent of making my own job easier, because I I hate repetitive tasks and I could never work in a factory. Can you talk about the ticket?
Speaker 1:tool. Yeah, so I you talk about the ticket tool.
Speaker 2:Yeah, so I'll talk about the ticket tool. Essentially, when Andy and I worked at Comcast together, we were working in the NOC and we were working in what's called cellular backhaul. That meant that we monitored all the cell towers for T-Mobile, sprint, at&t and Verizon and we monitored Comcast's equipment at those cell sites. A big part of our job was just sitting and waiting for stuff to break. You didn't have to wait long.
Speaker 2:You're not the main tech guy? Exactly, yeah, we're not the main tech guy there. Someone snags aerial fiber with their truck or something like that. Next thing you know, you've got five towers down.
Speaker 2:When we were there, the process to open up a ticket Comcast is super process, heavy and super organized. I learned you know organization really well at Comcast. But that process to create a ticket was I'd have to go into what was it Remedy? I'd have to open up the. You know I'd have to start the initial ticket. I'd have to say, okay, this is who all is down. Okay, well, I've got AT&T down. I need to open up a ticket for AT&T. All right, now I need to contact AT&T's NOC. And then I'd have to go find some document that someone had created somewhere with the contact information for AT&T. So maybe it was an email address, maybe it was a phone number, maybe if this tower was on the East Coast, it was a different distro that we would have to send the email to than if it was on the West Coast. And so it became this arduous process to open up a ticket because you had to jump through all these different hoops.
Speaker 2:Well, I got really tired of having to go and figure this out every time. I knew we had an entire database of all the towers and who they belong to, and I knew that the options were pretty limited. If I choose AT&T East Coast, this is their Knox phone number, this is their email address and so on. So the first thing I did was I just dropped it into Excel and started creating VLOOKUPs right, which was basically, if I put in this cell tower, it would look up in the database and say, oh, that's an AT&T tower. And then it would look up again and say, okay, well, an AT&T tower on the East Coast is this. Anyway, the long and short of it was it was just an Excel document.
Speaker 2:I really got a little bit lazier and started figuring out with macros. I could actually control the keyboard and mouse and do essentially keyboard emulation, and so I even had it. So I set it up where the computer would go and it would open the ticket for me and then it would take all the information from there and it would pop it into the ticket. So I didn't even have to do that, and then it would write the template for the email that I had to send to them, and so it did all this stuff. That just became repetitive tasks and it didn't start out as one big project. It started out as a bunch of little projects. I need to be able to look up a tower and know which carrier that is. I need to be able to look at that carrier and know their email address or their phone number.
Speaker 1:How did Excel send information to Remedy Like? Was that an API call?
Speaker 2:It was using. No, it was actually no man, I still don't know how to do API calls. I just make stuff up as I go. No, that was it was literally using. It was a Visual Basic which is built into Windows. It was using Visual Basic to be able to control stuff and it was as simple as it gets. But what ended up happening was that I was creating tools that were super consistent. All of my notifications read exactly as the company wanted them. I never messed up and said Verizon. When I meant to say T-Mobile, all of my stuff looked so clean that another engineer was like hey, what are you doing over there? And so I showed him my thing and he's like that's really great. And then he told our manager at the time and our manager was like that's amazing. And the next thing you know, I'm running an Excel document for the entire team and updating this thing and doing change notifications to the team.
Speaker 1:For all three shifts. It had to be used with that, but it saved so much time. It took 15 to 20 minutes fighting Excel and spreadsheets and documents and databases just to get a ticket open.
Speaker 2:The cell tower was on fire.
Speaker 1:And what was it like? Two minutes, a minute 30 seconds, I forget it was 30 seconds.
Speaker 2:We went from 15 minutes a ticket to 30 seconds that it took to open up a ticket and that was because it was Visual Basic and I wrote horrible code, was Visual Basic and I wrote horrible code. I still write terrible code. But I guess my point is I think what happens is, as engineers, we get so focused on well, it needs to be exactly this and we OCD over it. Sometimes it's just a matter of come up with some project for yourself, Like the thing I talked about earlier that I did in Ansible. I knew that was a repetitive task. I'm constantly starting new virtual FortiGates to build up some lab, and some of them are long-term labs and some of them are just. I need to build this thing right now to figure out something for a customer and I automate it. So now it happens in five seconds to build it. That's for me. It's a selfish script. It does nothing but help me, but I learned something in the process. I learned Ansible. I nothing but help me, but I learned something in the process I learned ansible.
Speaker 1:I didn't know ansible before I actually thought of the program. I want to read a comment in the chat and then I'm sure colin has um things to say. So dan riley in the chat says the main resource jeff had here was time. If you're already drowning, you won't be able to pull off automation, right? So again, harken back. Well, okay, harken back to my time in prod like drowning bro. Drowning like I hate my life. Drowning like why did I go into your?
Speaker 3:drowning was a little different than jeff's, though right like jeff, you were overwhelmed by a process that had a workflow that required you to do a lot of the same steps over and over. What andy?
Speaker 3:was describing if I can take the aside. Here is something that I think is a cautionary message to anybody who's thinking about automating, and that is if your network's already on fire and when I say on fire, you were using scenarios, andy, like overlapping address space, a subnet. Creep things were a mess, you didn't have a source of truth. Creep things were a mess, you didn't have a source of truth. Automation is a dangerous thing to use as a workaround for foundational network design issues.
Speaker 3:It can be, tempting and also it can be somewhat discouraging if you're a network engineer looking at that landscape and trying to figure out how do I use automation to abstract some of these challenges. I know, at least from experience doing other things that are automation adjacent, that all you're going like don't take a problem and make it more complex with automation just by distracting things. So I would say you want to fix things first. If you're looking for projects, some of the things that.
Speaker 3:I'm thinking about doing are probably going to be things at my own house, with my own switches and stuff, to begin with, because what am I going to do at nokia and I don't have direct customers yet because I'm less than four months in. So it's that was one of the things we were talking about in the discord leading up to this is where do you what? What is sort of the perfect, what's the description of? Like the perfect first automation task, and not I also accepting that you cannot look around at your org and say we don't really need to automate something right now, and I think that that's true for a lot of folks.
Speaker 3:One of the things that was in my decision making for leaving Juniper and coming to Nokia was that I knew that the job was going to force me to learn automation, that I could continue to work in the role that I had previous and still continue not to touch it, and I felt that I needed that extra torque. I couldn't find stuff to do over there and I can find stuff to do here, so you don't have to automate every network, and if you do, you should be careful about the things that you're looking to automate, because, jeff, I'm also guessing that you then became the owner of that software, right, correct?
Speaker 2:And that's the thing. The software ended up saving me time, but it ended up eating a ton of my time. But I spent my time doing something where I was learning something, as opposed to doing the repeating thing. And that's where it's like the argument that Daniel made, which is Jeff had time. It's true, I did have time, but it's only because I ended up literally saving. I ended up making that time for myself because I could learn a V lookup command in 15 minutes and that V lookup saved me three minutes every time I create a ticket Right. So once I figured out how to automate the entire 15 minute ticket process, it meant someone's like open up a ticket, I push a button and I'm done and that's a repeatable task.
Speaker 2:But you're right, you can't automate everything, like I have customers constantly asking me you know how do we template something where every site is different? And the answer is you don't right. You don't template something where every site's different. It's impossible the same with auto template automate same thing. You know, if everything's different, you can't do it. So you shouldn't automate everything.
Speaker 3:It's a tool. God help you. If you build a tool that people use, because it's going to be like picking up cursed armor in a game, you're not going to be able to put it down.
Speaker 2:Yep.
Speaker 1:Is it fair to say that networks are more complex than they've ever been?
Speaker 2:In many respects. I don't know that in every way, though, but I mean in a lot of ways. Take, take cisco. Right, if you tell me that you have a cisco network and I would say, all right, well, uh, what are you running? Well, are you running cisco ios? But, yeah, we're running ios. You're running nexus? Yes, are you running nexus with aci? Yes, all right. Are you running a firepower? Yes, none of those are the same operating system and that's just one vendor. Right, it's like you could do this with every vendor in the world. So in some ways they're more complex, but in other ways, like Colin was saying, we do have some tools that fix some of that.
Speaker 3:I think that as bandwidth has increased and infrastructure has paced that to provide better I mean, it's Moore's Law Things get cheaper, you can put higher bandwidth in places that wouldn't have normally gone. That has allowed us to start shifting more services onto the network. So in the sense that we are now like the, the simpty, uh, a uh audio video stuff that's happening now, where now we're doing 4k, 8k AV streaming over a network instead of on its own discrete audio visual system, or the upgrades that we're trying to do right now to the critical infrastructure, where we're seeing a convergence of ITOT systems, which wasn't possible, both for secure and for throughput and connectivity reasons, even 10 years ago. So what a network does hasn't really changed much, because networks don't exist for their own sake.
Speaker 3:Networks exist as a tool to interconnect resources and that has not changed at all the types of resources that we're now putting onto networks and the drag pull through effect of requirements that that creates in terms of protocols that we need to develop, ipv6 obviously being developed in order to address the yeah, oh, my god, we're gonna run out of v4 space, remember that and the but things like a VP to audio video bridging, yeah, and EVp and vx land, which is sort of the end state of what we've been trying every protocol that's ever run in a data center has tried to accomplish, which, in its heart, is very simple, and it's just trying to trick two services that are geographically apart that they're connected to the same broadcast domain and right next to each other, but that's that's it.
Speaker 3:So everything we do is trying to get to that abstraction layer. We're getting better at it, so they're getting more complex in terms of how we have to support the services. But if you look at AI data center designs for training networks, it's simple. There's not a lot to them. It's just throughput and latency. They're packet pumps. Build it up, build a rail design and run it to within an inch of its life for eight months, six months, three months, whatever.
Speaker 2:Yeah, a lot of problems are solved when you have more bandwidth.
Speaker 3:That, I believe, has simplified some of the stuff we had to do more relevant is we're all getting a little bit more comfortable with letting those services that rely on the network exercise a degree of agency over the network and program it. To a certain extent, that is what most funded automation at any organization that relies heavily on automation is focused on. It's not making that one task a little bit easier. That might be a part of a larger platform or framework that gets designed, but that's almost always going to be something that's driven by an intent, and that intent is never expressed as a direct networking configuration to a certain device. It is a description of what services need to communicate using the network and where those services reside, and then behind that is all the configuration that then gets generated. And I think it's fascinating, and I think it's cool that that is kind of where we're at, because we now treat a network as this gestalt entity as opposed to these collection of nodes. And when you do that, some really cool things start to happen.
Speaker 1:I think that, well, so we're talking about all these reasons that people should automate, right, and it reminds me so where I'm going was like psychological factors, right, Like yeah.
Speaker 1:I learned this from Mike Bouchon like cognitive biases, right, like so we think and we do this. We do it with our kids, we do it with our spouses. So we think and we do this. We do it with our kids, we do it with our spouses. We think by continuing to say the same things over and over again, louder and louder, if we say it enough, we'll convince people to see the world the way we see it. So, as I hear Jeff talk and as I hear Colin talk, I keep hearing the automation drumbeat that I've been hearing forever and I don't know if just presenting information more and more louder and louder in different contexts, I don't know if it addresses the cognitive biases. So, like Colin had mentioned, like loss aversion and negativity bias. So I thought they'd be like two quick things because really, if you're trying to change people's minds and that's, I think, what we're trying to do in the networking industry is, you know there are plenty of benefits of network automation. I don't think anybody could, I don't think anybody could look and see what automation can do, like if it was easy, if a vendor could figure out an easy button, if there was a way to take all that complexity, and like if there were, you know, like so culturally right, I mean, we'll get into the cognitive thing in a second but I always felt and it wasn't my main constraint but automation is going to take my job. They're trying to do more with less people. People are expensive, right, but maybe that's loss aversion, right. I think that they're going to take my job, are they? Or is this going to make my job easier?
Speaker 1:Because then I see Jeff's story about the ticket tool. I worked in that NOC for years and I spent my first year spending 20 minutes per ticket opening it. And then Jeff comes along and the sun shines through the room and he's like hey, check this thing out, and you press a button and in 30 seconds you have what used to take you 20 minutes. It didn't take my job. We didn't lay people off at the knock.
Speaker 1:I have proof, I mean, for me in my life. I kind of need proof that refutes my belief systems and my core beliefs, to really look at things differently. And Jeff, that was just one example of like oh, the ticket tool didn't take anybody's job. I remember when you left they were freaking out Like, oh, my God, who's going to manage the tool, the biggest problem of Jeff leaving the NOC was like oh no, who's going to do this? And you spent your last two weeks there trying to train everybody on the ticket tool. So, like, loss aversion is a psychological factor, right, and I don't know how much of this plays into people, but what's the thing? But what's the thing? Like losses feel twice as impactful as equivalent gains.
Speaker 3:So, like we do everything we can to like and the number of negative scenarios are 10, outnumber the positive ones 10 to one, when you're making a decision too, yeah.
Speaker 1:It's really stacked against so like, right, yeah, I mean, am I going to lose control over my network if I start automating? Are they going to get rid of me if I start automating? Are they going to need less of us if I start? I don't know how many of those different cognitive biases are in there, because you really can't and I don't want to draw a parallel to IPv6, even though I do and I keep saying it and I don't know if it's the same thing but when you see something that makes so much sense technically, that solves so many problems, that makes technical life better, easier function better, get rid of problems like Nat and V6. And for us as an industry not to adopt it, there has to be something else going on besides. People haven't heard enough people tell them they need to automate, and that's what I was trying to, that's what I wanted to get to.
Speaker 1:Tonight is like there seems to be cultural and cognitive stuff and psychological, like as an industry, we have said no, leave me alone, go away, I have a buddy, and then Kyle, and I'll hand it to you. I have a buddy who works in the public sector he works at I won't even say where or what state he's in. He works in the public sector and there's six of them that just spent I don't know if he said three weeks updating. I don't know if it's SNMP or it was some. Oh, it was an IP helper address, so they had to dude. They had $600,000 worth of network engineers spending three weeks of their time doing it manually. That is the state of most of networks, like that is how we are managing networks. Now it's bonkers. But what he said was well, I'm in the public sector, we're slow to change, they're not making us automate and honestly, bro, I'm going to be retired by the time they're making people automate around here. So that is the mindset I think. I don't want to say he is a representation of the rest of the industry.
Speaker 1:But I was fine doing it the old fashioned way, manually and slow, because it was intimidating to learn coding. I was afraid and I also have my own cognitive biases. I'm not smart enough to code because I failed out of computer science in college. It's not true, because, spoiler alert I used the NetMeco library to use Python to log into a router and change a host name, but that's after like seven years of me bitching publicly about all the bad things about coding. So this has been a journey for me too, and I'm just now getting to the point of like being open to these conversations, being open to work on it.
Speaker 1:Colin and I may announce something at the end of the show, but I think we're going to like issue a challenge to each other and actually make each other automate things in networks. Colin, you wanted to say something, but I think there's a lot of psychological stuff and a lot of biases and it's really I don't know how you I've watched people like Mike as a wizard kind of change people's minds. I've watched people like Mike as a wizard kind of change people's minds. I don't know if I have that skill today and I don't know if the three of us on this show can change anybody's mind tonight about how they feel about automation, because the industry just really sucks right now at adoption and telling them over and over again how great automation is doesn't seem Like the network automation forum is doing great work. I think it's amazing. I haven't been there yet and I hope it's not a bunch of people who are automation zealots who are telling each other how great automation is, because that hasn't moved the needle in 20 years they had really good tools tutorials.
Speaker 3:I was at the last autocon and I hear.
Speaker 1:It's amazing. I'm not trying to be up on them, right oh no, you're.
Speaker 3:I, I had the same concern, uh, and they? What they did was very nano, I guess, where somebody would present a scenario and then their presentation was walking through the tools and the outcomes that they got and how they got there. Less of a evangelical conversation and just more of a practical application. I wanted to say that I don't necessarily think it's just individuals deciding not to automate Companies, the organizations that we all work for. It's not just automation. How many times have the? You know we, objectively, this is the thing we need to do to fix our network, just put automation out of it. This needs to be refreshed, this needs to. We need to do X, y, z and it doesn't get done right and it is part of that decision matrix that's so influenced by risk.
Speaker 3:What I discovered in the time that I was in SE is that what status quo was really code for was people that were really comfortable with the predictable failure, so much so that they weren't willing to take a chance on unpredictable success. So, unless you have a support system around you that's encouraging and saying, hey, we're all going to learn this together. You know, this is an initiative. Most of the appeals that we're going to have to make to try to get people, or even ourselves, to learn something new and this is true of everything Autom automation is no different is really kind of that Maslow's hierarchy self-actualization. What am I going to get out of this?
Speaker 3:So you mentioned Mike and his ability to change hearts and minds. The superpower he has is being very aware of who his audience is and being very good at making real-time personal appeals. You don't tell your own story, you tell that audience's story with you in it, right? You make them. What Mike would say is you make them the hero of that story.
Speaker 3:So getting people, I think, interested in automation is painting a picture, and it's very specialized. So it might be very difficult in a forum like this to make something that's bespoke enough to actually get somebody excited, which is why I'm hoping just giving somebody something easy to consume and showing them here's the steps that I'm taking and you can follow along click by click might be helpful that there needs to be something that says look at how good this is for you personally at the other end, because ultimately a lot of folks that are going to start an automation journey are going to have to do so without any reasonable expectation that the work that they do is going to make a change to their material existence. Right, they're just going to have to kind of do it for themselves and then, as they get more comfortable with it, they're going to get better at doing things more efficiently. You actually one of the examples you used at the beginning was like we were gonna do this thing.
Speaker 3:It was gonna take a long time. So we sat down and we spent a week building a automation tool and the first thought I had was if you had just worked eight hours a day for five days straight, could you have done what that tool did? Maybe the answer is yes, maybe the answer is no. It's hard to connect with the value of that automation assuming it gets done correctly anyway when you start with the actual time that you invest into it versus what you're actually going to be automating. So you kind of have to do it for yourself.
Speaker 3:And that's where I think just having some basic understanding of the tools landscape, so you don't get into that paralysis of where do I start, uh, and what do I use, might be helpful, because it is. There's a lot out there and that's git has been a blessing and a curse, because git is like oh, we have all this repo and this collaboration and it's wonderful and it's like that's so awesome. What tool do I use? I don't know. This thing that I use has been forked like 40 times, so I don't know which version is best for you like uh I think it.
Speaker 2:I think it's easy to come up with a lot of reasons not to do something. If you look at the chat right now, there's been the if automation goes wrong, automation goes really wrong, Absolutely legitimate.
Speaker 3:It's a megaphone.
Speaker 2:There's been the argument that you're going to spend an hour troubleshooting something that maybe saved you 15 minutes 100% true. There's the argument that it's not in our makeup as network engineers to be programmers, and some of that's true. Our brains don't necessarily work that way. But I guess the way I've always looked at network automation, the way I look at really any task that I take on, is I can spend hours doing repetitive tasks and get them done, and I can do them pretty well. I can do those repetitive tasks, or I can spend hours learning how to automate that repetitive task. At the end, I actually learned something with one of those two choices. The other one, I just repeated something I already knew, two choices. The other one, I just repeated something I already knew. And so for me, I'm always constantly in a state of wanting to learn something, because I can't imagine wanting to do the same thing over and over, which is part of what got me into network engineering in the first place. Right, it's a job where we get new problems and it's a job where there's always a solution. And for me, I just I like to try new things, I like to try new things, I like to see new things and I understand that sometimes you don't have a ton of time on your plate to go and learn new things, but we've got the stuff that's happening with ai right now. So many people are kind of feeling the same way about ai that network engineers feel about automation, like I'm steering clear of that, I'm not touching it. What happens when it spits out wrong information? And? And the answer is absolutely it can do that. If you were not, I mean like I wouldn't enter a command that a network engineer I knew really well gave me if I didn't know what that command did. So it's about going and figuring out you know what am I doing? Why is this doing it? And you can do that with the automation tools. But start with you know, put in the chat, start with show commands. We used to.
Speaker 2:One of the biggest or the best scripts I ever wrote was one where we had to do bandwidth capacity checks over at SunGuard and what it was is we'd be turning up a new customer and that customer would want a one gig circuit and I would have to go and check all the LSPs on their MPLS circuit. I'd have to check every hop by hop by hop to make sure that if this guy wanted one gig service, we weren't going to create some bottleneck and screw him up because it was an old network and we were constantly having to upgrade it. Well, that was a tedious process. It took 15 minutes to go in step-by-step and check in the bandwidth and we were able to automate it.
Speaker 2:But it took me weeks to write the automation script. But then what I got to do was I got to take that automation script and hand it off to somebody who was not me and they got to do that obnoxious, tedious job because they could do it with a script and if they only had me doing the job, they had another engineer doing the job because they knew they could trust us to get the right answer. Once we wrote a script to do it, we could hand it off to somebody else and our jobs were secure. So anyway, like I said, I think it's worth.
Speaker 1:I always think it's worth learning something and I feel like that's the real advantage of automation, because I'm a selfish automator, you know, I don't do it for everybody else, I do it for me I wonder if time is the lever that you know, if that would be an effective lever to pull, and I know this isn't a new idea, but, like if time is our most precious resource, right in the older I get, the more I that is internalized. Um, and I don't know if I want to say it was daniel technia. He's a guy in australia that we had on and he's a big network automator guy. But he, you know, he said that he would rather he would rather spend time with his wife and kids. He would rather spend time playing his guitar, riding his bike, going fishing. And the more he learns about network automation and the more he leverages network automation in his networks, the more time he has to spend with his wife, with his kids, on his bike, playing his guitar. He's been able to stabilize his network work less maintenance windows, the on-call.
Speaker 1:He made a compelling. He was like Andy, it's all about time and I know you don't want to do this, I know it's hard, I know it's scary. You're telling me that time is your constraint and I hear that a lot. I I'm drowning in work. I can't do this one. I'm going to do it and there almost seems to be like I don't know if I had time to study for my CCNA when I was working 55 hours a week as a Comcast Gable guy and doing my other stuff, but like I needed to make a change in my life and try to have a better life. So I spent every spare moment I had during the workday and hours every night and eight hours a weekend going to school studying the stuff I put in the time to learn route switch so that I could become a candidate and get a job ultimately with you, jeff. So again, this is just more proof in my own life of I have spent time learning hard things when I really didn't have time necessarily, but I made it a priority because there was a bigger, there was a bigger benefit to that temporary, temporary suck. It almost reminds me of like Goggins. Like you got to embrace the suck. You got to do the things you don't want to do and the things that aren't fun or that don't seem appealing now for a better later. You know what I mean and and that. So I don't know. I kind of like that for myself because again I have spent.
Speaker 1:I can't imagine spending three weeks, five maintenance windows a week updating IP helper addresses, like my buddy I talked about. But that's the decision they're making because that's the grind they're in and that's just what they're going to do. To your point and to Colin's point, you could probably spend a week working on a tool and then do that in a night or two. Now you have just reclaimed two weeks of maintenance windows that you're no longer up for and tired the next day and grumpy with your kids and less time with your wife. It's less maintenance. Like you can do more work in less time. Like that seems pretty good to me, right. Like that couldn't. It just doesn't seem like the networking industry sees the value and how this is gonna make their life better. It's going to take my job. I don't want to do this. I don't like coding. Well.
Speaker 1:I mean it's going to take your job.
Speaker 3:You would think it would be the motivator, but it isn't. That clearly didn't work, so it's going to. It's going to sound like I'm being smart, but I actually I had to Google this.
Speaker 2:It's going to sound like I'm being smart, but I actually had to Google this. I'm lying. I chat GPG'd it, but then I double-checked it. It was a guy named Peter Drucker. I read this quote somewhere Peter Drucker, he was a management consultant and he used to have this saying that said, managers must take the lead in making obsolete their own products and services rather than waiting for a competitor to do so. I think there's a lot to be said about that. When it comes to automation, when it comes to AI, which is could this thing someday take your job? Yeah, but you better create the thing that's going to take your job rather than letting somebody else do it, because if you are not the one that knows automation, they're going to replace you with somebody that does, if you're not the one using the AI products they're going to replace you with somebody is.
Speaker 1:So if you want to not lose your job to these things, go be the guy that's using the tool. I've said this before I couldn't get my job at Fiserv today that I got eight years ago, because now you must have a modicum of Python knowledge to get that network engineering job I had then. I can't even get hired there with my current Python skill level for a job that I had. So you're right, that needle is moving and this is going to. I mean, and this is all additive I had Scott Robon, you know. I told him oh, my skills aged out and I don't know coding and I'm on DevOps guy. And he's like, try to reframe that. Your skills didn't age out. Route switch is always there, everything's running on a network. But this is additive. You can, you can add it.
Speaker 1:And he had another good point. He said you know, programming used to be done with punch cards, andy. He's like they found a better, more efficient way than putting paper cards with holes in them to program computers. The punch card people lost their jobs, but the industry became better as a result, right? So I think this always happens. There's always disruptive things that come along and can displace people. So to your point right, you better learn the automation or you're going to be out of a job. And now with AI, it kind of seems like that too. Right, like you better try to figure out what the hell is going on with LLMs and AI and machine learning.
Speaker 2:At least to be able to have a conversation.
Speaker 1:Well, right for you to keep a job. I mean, I like to be employed, I like to keep a job, learn something new, go learn something new. Yeah, yeah, for sure.
Speaker 2:So we've been beating the same dead horse for 45 minutes. What are we going to do about it?
Speaker 1:You know that was the point of this whole conversation, right? I don't know if anybody heard anything. So for me, what I've been trying to do recently is kind of come in with that hot take in the beginning, like network automation is nonsense. There's a reason the industry hasn't done it, sense, there's a reason the industry hasn't done it. It's another next big thing, like V6 was, and nobody's adopting it for that reason. But you guys have made some compelling cases for it and I don't know.
Speaker 1:Jeff, I'm kind of just fixated on your time thing and your example of that ticket tool. And if you want to spend 20 minutes a ticket and you're opening 10 tickets a day and that's how you want to live your life, fine. Or you could spend some time and learn an automation or build an automation tool and take 20 minutes of work and make it 30 seconds of work. I have just gained so much time in my life. Again, maybe it's an age thing, but when you get to a certain point in your life where you realize or you lose some people in your life, we're not here forever, we only have so much time, how do you want to spend it? I don't want to spend it updating 6,000 IP on purchases in three weeks and make this Windows right.
Speaker 2:Yeah, that's the thing. I'm not saying you're going to gain time back necessarily by automation. If you're the one writing the script I mean someone in the chat's like yeah, then you're the one that maintains it and I spent as much time maintaining that script as I did opening those tickets. I don't think that automation necessarily is going to save you time. You were calling that, just said it's additive, right? I mean, if I learn something here, I've at least got some knowledge that I can now build on. I can write Visual Basic or I can read Visual Basic. I can read Python, I can read Bash, I can roughly read Perl. I can't write efficiently in any of them, but I can read other people's work and make it do what I want, because I learned from writing the basic stuff.
Speaker 1:Well, you said something the other day about you felt like the networking world reached an inflection point with automation. Have you touched on that? What do you mean by that? Because it seems compelling to me.
Speaker 3:I think that the tooling is getting better and while I'm no great fan of EVPN, vxlan, the campus network, the idea that we're starting to implement overlays and places that they haven't traditionally been means that we are going to have more network designs that can be easily viewed through the lens of intent, where you have a distributed control. What I'm saying is there's not really a lot uniform networks are writ large, and this is why data centers are a great use case for this, because there's essentially a handful of reference architectures and you just kind of scale them horizontally and then maybe you know, three stage, five stage. That is going to shift, like the network control, the things that you've described, the ticketing integration ServiceNow has got a ton of integrations that are just baked in. A lot of this stuff that has been historically automated is now being put in a product, or products themselves are addressing issues. The thing that intent does is that suddenly, if I have an intent-based system, I don't care about that Excel spreadsheet with IP addresses. It's irrelevant, I don't need that any longer. The network is a single entity. It's not this collection of nodes. I don't need to rely on each node's perspective of its local space and what it's directly connected to. And then do I mean this is the network architect's job forever was being able to look at that magic eye poster on the wall of the network and blur their eyes until they saw the boat Except in this case it was. You know why is this ping not working right? And you've been relying historically on collecting information from individual network devices and then using your experience to infer what could be happening.
Speaker 3:And an intent model says no, no, I just care about these services. Between these two points it has a very different perspective. What that means is that the inflection I'm talking about with automation is that we're the skill set. I think of the network engineer of the future. Right, I'm not going to do the Futurama voice here, they're Matic hands like a World Fair presenter but is that network engineer is going to be the person responsible for the network side integration of the application centric automations that are being done? So if you learn automation for networking and never, ever use it to actually automate, it's still going to make you better at interfacing with the other people that run the higher layers of the network model, the people that are in the application layer, and the way that they're thinking and the way that they're building tools and the way those tools interact, because, ultimately, they don't care about the network. They care about the relationship between the applications and services they're delivering and dependencies and the people that need access to them. And the network to them is no different than a water pipe in their house, right? They just want to turn on the faucet and the water comes out and we're plumbers and that's so. I think we always have a job. It's just we need to have a perspective on what that job is going to grow into. And it's now moving.
Speaker 3:I think that when I said inflate like specific pin in the calendar, the adoption and interest in Terraform, the things that Red Hat Linux is starting to incorporate with some of their event, what is their? Nokia is using the same acronym for something as them. They have an EDA and we have an EDA. There's a similar concept where they're starting to incorporate more declarative and intent-based workflows into the solution. That's what's happening right now, that adoption, and there's a long tail on it. We all still have time, no need to panic. But it is going to foundationally change the way that we manage networks and I think that's a good thing, because what's changing is we're shifting our focus towards how they're delivering the services, and not just a collection of access layer switches, distribution layer switches, core switches, which is what it's always been. It's exciting.
Speaker 3:I mean, I've been doing this for a long time and I'm excited about it.
Speaker 1:You know, I think you're both right. As you were talking, colin, I'm thinking about some of the things I've done recently, in the past 8 to 12 months. That, like, I installed Linux and I started messing around with Linux, right. And then, when I covered an NFT event, I wanted to learn SR Linux. So the fact that I had Linux running was good because I had to install SR Linux in that environment. But I learned lab as code, right.
Speaker 1:Like I think there was three Linux commands and I had Docker up and running, container Lab, sr Linux running and a YAML file built a lab as code environment. For me it took five minutes probably. Import the repo from Git, like. So again, I'm saying these things out loud because a year or two ago, if you were to told me that I would know, like, how to have Linux running in a server, connect my VS code to it, have be able to pull from a GitHub repo, get Docker and container lab up with SR Linux and then import the YAML file, like this was all foreign to me two years ago. So, like, if an old dog like me who's been bitching and complaining about automation all these years publicly, by the way can can learn some of these things. If I can change I think any of us can and there are places, like you said, that are creating better tooling. They're making it easier, the documentation's easier.
Speaker 1:I mean for me to get a lab working and say GNS3 or EVE-NG. I'd never been able to do that in five minutes or so. There was a lot of wrangling with this and doing that and the other thing and setting this like and I love those tools, but just lab as code. And I guess I'll finish with this my buddy, chris Margett, that I worked with at Juniper. He built this Terraform provider. I didn't know what Terraform was and he was all in infrastructure as code and I'm like, all right, dude, like you're just a nerdy developer, I can't talk, like what are we talking about? But he, he spent an hour walking me through it and I understood it and I'm like huh, so like I could just write a text file right, like it's executable documentation yeah, yeah, and it's kind of intent in there, right, like tell it what you want, push a button.
Speaker 1:Terraform what is it? Terraform create I forget the verbs, but like terraform apply, right, it was amazing watching him do it and I told him and I was on it, it was straight from the heart. I'm like dude, I think I could do this and this looks accessible to me and so like a tool like Terraform, just as an example, or like Labus Code or SR Linux or others. So you know, I guess, if we want to start closing it up, I mean where I always tell people to start with Ansible because I think it's the easiest thing to do. You don't have to know code. The syntax and the playbooks are pretty easy. The config files, some IP addresses I think it's been a while since I've done it. I mean, what would you tell the 60 to 70% of network dinosaurs who are still doing the IP helper and maintenance windows for $600,000 at a clip, like my buddy that works in the public sector? Where do people start? I mean, what do we say? Start with something small, right, like start with something that you can make your life better with.
Speaker 3:I like the show commands or something that has a small blast radius. I mean, I imagine most people that would tune into something like this are going to have some home networking switches. Start by figuring out what different tooling those switches can interact with. Are you going to be using OpenConfig or GNMI? Are you going to be using heck? You could use SNMP, whatever. I mean, the most scripting I've ever done was Slacks and it was painful and it was Juniper only. I used some PyEasy, you know. So there's libraries and stuff that are focused on certain vendors, but figure out what the vendors support and then cheat like hell. Somebody's already done what you want to do. Don't think you have to cut it from whole cloth. Go figure out what somebody else did, do it and then work backwards through the automation we say that where do you find that?
Speaker 1:where's that place called? There's no place you can get code. Well, a lot, of, a lot of.
Speaker 3:There was another one like a lot of companies will also run their own repos or they'll have their own forums or presence where you can interact with the community and get access to tooling that's specific to their switches. So I've got juniper hardware here, uh, at my house and some hp and dell stuff as well. But you know, ubiquity is pretty common in homes, uh, you know that kind of stuff. It that just figure out what you can do at home, uh, or?
Speaker 1:stack overflow. That's what I was thinking, is that? Where people go and ask a question and then they'll give you code like right, I mean, there's multiple places, I guess you're gonna start, you're gonna google it, you're gonna find it, but go like, go search.
Speaker 3:It's like, how do I automate the show command and then use a postman right, which is just I think Google, isn't that a Google tool or something, I don't know, it's just, it's a way. It's the fastest way you're going to be able to just send a command like a call, and it's a. Basically there's two models here, and the one that you're going to want to start with is just I'm going to send a query and it's going to send back a response. Doing is you're creating a surrogate for a command that you would type in a CLI and once you've got that done, you can apply it and point it at as many devices as you want. But start small. It'll start to feel neat and hopefully that'll be enough so that maybe you spend a little bit more time on it. Also, it's like going to the gym or anything else that you want to form a habit from, create some accountability that's external to yourself.
Speaker 3:Andy and I have had some conversations about how we can do that with each other and find a community of people, whether it's local or a lot of people have, or cities have network user groups from NUA and look around.
Speaker 3:When I was trying to figure out resources to publicly speak and get on stages and organize my thoughts, I started looking for Toastmasters, chapters right, these things are out there, they exist. And the more you can build a community around you while you do this, one thing that you'll learn when you go to AutoCon, andy, and you will, is that everybody is super nice and helpful and if you don't know a damn thing about automation, everybody's going to want to talk to you because they're so excited that you're there and you're interested, and they want to help and they want to follow up and they want to exchange information and they want to invite you into Slack channels. And they understand that once you get that ember going, you have to kind of blow on it and give it some more fuel. And then, once you get it going and I'm only now realizing that with what's going on in Los Angeles, this is a terrible terrible analogy to use right now.
Speaker 1:I think you get the point. I'll feel like the hot girl at the party at all. Con. I haven't felt like the hot girl at the party in a long time guys.
Speaker 2:I'm all in. Jeff, what do you think, man? Your closing thoughts, yeah, so, in terms of you asked the question, where do you get started? And I'm going to sound like I'm beating the AI drum, but I'm telling you the stuff that I can. You know, I popped in the question to chat to you.
Speaker 2:Give me 10 ideas for network automation. One of them is automate configuration backups. Well, that's a great one to write. Create your own IPAM, so IP address management on that. Create a device configuration auditing so actually that's something I do regularly is, instead of actually pushing the script to the device, I'll have it create my change plan for me, so it tells me what I'm going to put in there. Like, if I'm writing a script, I'll have it write the change plan, then it's copy and paste and I don't have to hit commit on that until I'm confident in what it's put in there, but start with it. Until I'm confident in what it's put in there, but start with it.
Speaker 2:Find a project, I mean, and I say the AI stuff, because AI can give you 100 bad ideas in a second and out of those 100 bad ideas, you can usually come up with a good one, and I think that's what's really great. Is it going to take over all of our jobs? Sure, probably someday, but not in the immediate future. And I think right now, going in there and just getting it, having it spit out a bunch of ideas of what you could work on and then use it as a teacher, I literally learned Ansible yesterday completely from ChatGPT.
Speaker 2:I didn't go to the internet for anything, I just went to ChatGPT. I spent an hour writing something that, in the end, is a completely stupid playbook, right, I mean, it doesn't save me a ton of time, but I spent an hour and I learned something different and I had the time. I had the time to do it. So, yes, I realize that's a luxury that not everybody has, but it was fun, right, I mean, it was a fun, interactive thing and I wasn't working on production gear, so I wasn't worried I was going to break something, and the only person in charge of change management here at the house is my wife and I didn't even have to consult her with this. We're good. So, yeah, I mean, just find a project, go do something, get your hands dirty.
Speaker 3:Don't break the toaster.
Speaker 2:Don't break the toaster, I had a boss that told me something that was the best advice I ever got from a manager and it made me feel the most comfortable in my job and I think I said it last time I was on. Which was he told me? He said go break things, don't be afraid to break things right. Go, go break something. Make sure it's not production right. You don't want to have to generate your resume or your resume anytime soon, but go break stuff in your own lab, because you'll learn so much more by putting it together. And the same thing is true of automation, the same thing is true of scripting. Go mess it up a couple of times and figure it out.
Speaker 1:Thanks so much, guys. It's been an incredible conversation for me. For all things Art of Network Engineering, we have a link tree. It's linktreecom forward slash Art of NetEng. I always try to remind folks that we have a great Discord channel and they're called. It's all about the journey. There are thousands of people and they're studying all kinds of things, helping each other out. Somebody just said they wanted a home lab, somebody else just gave it to them. So if you don't have a community around you, I highly suggest it. I've been in tech with the community and without, and life is much better with one.
Speaker 1:So link tree forward slash art of net edge. You can find all kinds of cool stuff in there, including our Discord server. Thanks so much everybody for joining Guys. Thanks, great seeing you again and we'll see you next time on the Art of Network Engineering podcast. Hey folks, if you like what you heard today, please subscribe to our podcast and your favorite podcatcher. You can find us on socials at Art of NetEng and you can visit Linkt socials at Art of NetEng and you can visit linktreecom forward slash Art of NetEng for links to all of our content, including the A1 merch store and our virtual community on Discord called it's All About the Journey. You can see our pretty faces on our YouTube channel named the Art of Network Engineering. That's youtubecom forward slash Art of NetEng. Thanks for listening.
