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
Developers vs. Network Engineers
The divide between network engineers and developers has long been a source of frustration, misunderstanding, and blame in the tech world. When applications fail, the classic refrain "it's the network" often echoes through organizations, leaving network engineers scrambling to prove their innocence while developers remain convinced of their code's perfection.
In this enlightening conversation, former Cisco developer advocate Erika Dietrick joins hosts Andy Lapteff and Jeff Clark to unpack the root causes of this technological rift. Erika offers a rare dual perspective, having worked both as a software engineer and in Cisco's Technical Assistance Center (TAC). She explains how educational paths create fundamentally different mindsets: "Developers learn to code, period. We do not learn how our computer works. We do not learn how the network works."
Andy shares his personal struggles with learning automation, admitting to starting and quitting "every Python class on planet Earth." This prompts Erika's most valuable insight – that learning to "think like a developer" matters more than syntax or commands. The conversation explores how network engineers often find themselves drowning in daily operational tasks while being expected to add coding skills "for no more money," creating resistance to automation despite its potential benefits.
The discussion takes unexpected turns through topics like cultural differences between teams, the challenges of breaking technical silos, and how AI might actually help bridge these gaps without replacing human expertise. Erika outlines her upcoming free course designed specifically for network engineers learning to code with AI – addressing the exact educational gap that has frustrated network professionals for years.
Whether you identify more with Andy's automation struggles or Jeff's enthusiasm for Python scripting, this episode offers practical perspectives on healing the developer-networker divide.
Subscribe to Erika's Youtube channel here: here:https://www.youtube.com/@erika_thedev
Subscribe to our podcast for more conversations that tackle the human side of technology and join our Discord community at linktr.ee/artofneteng.
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, network engineer extraordinaire turned product marketer. Networking. Yeah, tonight today, this episode episode. I am joined by the returning jeff clark.
Speaker 1:Hi, jeff hi, good to see you you want to remind folks who you are, where you work and what you do oh yeah, I could do that.
Speaker 2:It's like almost like my job isn't to speak for a living, I'm a solutions engineer, systems engineer or sales engineer, depending on how you interpret. Se over at fortinet. All my things start with the word Forti.
Speaker 1:And the giggle that you hear in the background is Erica Dietrich, known in the social world as Erica the Dev. How you doing, Erica?
Speaker 3:I am doing fantastic now that I'm talking to you guys, yay, and drinking some wine out of my mug.
Speaker 1:Oh very nice, Fancy. Now I feel kind of of my mug. Oh very nice, Perfect. Now I feel kind of weak with my bubble, my club soda. So good for you. I wasn't going to ask if that was like water. But it's gin. I didn't really match the title intro of this podcast.
Speaker 3:Like heavy metal. Now we're going to drink some water.
Speaker 1:I have to keep my voice.
Speaker 3:Yes, yes.
Speaker 1:Are we drinking? Are we drinking red or?
Speaker 3:white, oh white, just whatever's in the fridge. It's all it means to an end, right?
Speaker 2:It's not.
Speaker 1:Shake the cupboards off.
Speaker 2:Get the nerve off.
Speaker 1:Erica, where do you work? This is a loaded question, but tell the folks who you are, what you do for a living and where you work.
Speaker 3:I am newly open to opportunities, so I just left my role as a developer advocate at Cisco, which is basically a software engineer that likes to talk to people. Now I am a inadvertent content creator and also just educator. I guess I'm going to call myself an educator because I can't fully embrace the influencer title.
Speaker 1:I love the inadvertent content creator. That's kind of how I stumbled into this too. We were a study group. Somebody said you want to do a podcast, and years later, here I am and my kids my kids are little and they Googled me the other day at school Like daddy, are you famous? Cause I Googled you. Your face popped up everywhere.
Speaker 3:I mean between like remote work, like trying to reach people, and then like I feel like our obligation as techies to teach people, to teach the next generation or just our peers. It's just really easy to fall into that as a side hustle.
Speaker 1:So you just left Cisco, correct?
Speaker 3:So, excuse me, Friday was my last day, so it's been like three business days being a free bird and like waking up whatever time I want, being an artist, a content creator oh yeah, thank you for not calling yourself a creator yeah, I don't know what title to settle on, but people are gonna give me whatever title they want, so I'm like whatever musicians and painters, and you know.
Speaker 1:I'm a visionary, yeah, um, what were you doing at Cisco? You were a developer advocate is. Is that what that is?
Speaker 3:Yes, so it's an ambiguous role to explain, but usually you have a software engineering background and then you help developers use the products, you develop free resources for them and also you kind of advocate for them in the company like, hey, this API sucks, this is what needs to change, and at Cisco we've got a lot of products, so it was a pretty big job.
Speaker 1:So that's a good segue. I guess you were a software developer working in a networking vendor, advocating for software, and that's kind of I guess why I wanted to bring you in and have this conversation. I can only go by my own experience, but as a network engineer, in the places I've worked and they were rather large places we were very siloed. Not only were the network functions siloed, like Jefferson Security, I didn't manage firewalls, we had a security team. I didn't manage the LAN, we had a LAN team. So the developers were in some glass tower with champagne and filet mignon and ping pong tables.
Speaker 1:Right, and I say that half-jokingly, but rightfully so. So the work that they're doing, they're creating applications and services that generate revenue for the company. I get it. You want those people to be happy and you want to take good care of them and the networking people down in the slums and in the dirt who would always get yelled at for all the things. We were a call center, right, we didn't really. It depends culturally on how the company looks at the network, Like the network is enabling those applications to reach people.
Speaker 1:But so where I've been, there's been a lot of silos and when I would interact with developers it was usually in an outage. Something bad happened so we didn't collaborate, and we'll get into this a little later. I think that there's cultural shifts. I think that developers and networking people are starting to work more together as teams, which is really smart. Our buddy, nick Calcutta, who is a college professor down in Florida he said the place he works they're starting to bring those teams together and see some really good results. But I guess I want to start in my reality, which is I get a call at two in the morning. Somebody says the network's broken. It's the network I'm scrambling to figure out. Ooh hi, doggie, I love you, it's okay.
Speaker 3:I love you. Okay, sorry, I was going to say no, no, no, I have two doggies here, I can bring them in.
Speaker 1:Not much I can do it sounds like a big doggy Two big doggies.
Speaker 3:My Aiden is kicking in Two big doggies. Similar to Great Pyrenees, like big white fluffs.
Speaker 1:Oh man, oh God, sound angry if you have to go check.
Speaker 3:They're easily agitated.
Speaker 1:So are mine. The UPS drivers and the Amazon drivers, those poor people.
Speaker 3:I gave them bully sticks, hoping it would entertain them for an hour while we talked.
Speaker 1:So why to circle back away from my ADD and back to the show? It's the network, and sometimes it was the network, but many other times it was not. Many other times it was developers that didn't have sufficient network knowledge to know whether it was the network or not. I was joking. Right before the show started I told Eric we spent days on this outage. That was definitely the network, because the application people definitely wasn't the application. And it turned out they had an expired certificate on the server hosting there and I was livid because I'm like I just spent four days getting yelled at trying to find the thing and it was so and again, that was just a one off. It didn't happen all the time. But I guess we just talk about hey, developers and network engineers, we need each other, we, we have this weird kind of symbiotic relationship, but we don't typically work together. You make the application, we make the network. When somebody wants to onboard the application, we get a firewall request. Here's the ports we need and we'll test.
Speaker 2:And the developers never know what ports they need. I don't know why. Right, yeah, so here we go. I was like, that's so true.
Speaker 1:So I just thought we kind of have a conversation about what's been your experience as a developer. Have you ever had something break and say it's the network, because you know your application's fine, like, let's start there?
Speaker 3:I had like five trains of thought when you were talking, so I feel like this could go in many different directions, so my background is a little bit unique. So first of all, I wait, can I cuss on here, is it?
Speaker 1:Yes.
Speaker 3:Okay, I don't mind shit talking developers because I also shit talk developers and I also come from some network engineering background a little bit, and familially my dad was both network and software engineer, so that won't bother me. But my background and my experience experiencing that divide. First of all, when I retrained into tech right, I was studying my master's of software engineering. I was entering with a dev mindset, but I retrained into tech right, I was studying my master's of software engineering. I was entering with a dev mindset, but I entered Cisco TAC, which is network support right.
Speaker 1:Wow.
Speaker 3:So that is my network engineering experience, which I know is not a full experience, but no, cisco TAC.
Speaker 1:The smartest people I know in networking spend time in TAC. Pete Lomber's company.
Speaker 3:It's a rough job.
Speaker 1:But you learn so much. Yeah, I have relied so much on tech Like I have called tech millions of times, and the help that I've received has been so appreciated because they do not get enough credit, for sure.
Speaker 3:There's something to be said for people who can fix things when they break, because there's not a lot on when things break. Right, you are really okay.
Speaker 1:Sure, you can learn to code, and that's not like an emergency most of the time right, but being able to fix something when there is no guidance is a huge, it's a huge skill. But anyway, not only fix something, but like the big thing and the money on the line and people are mad and like our stuff's broken and just like everybody blames the network, everybody blames the vendor. Well, it's fricking them because it's it's not working. So hold on real quick. How did you go from like software development MBA person to like Cisco tech?
Speaker 3:So I got an internship while I was getting my master's degree and I had a high school friend who was working at Cisco. I'm just kind of like hey, I know from my experience taking life to the face before going back for my master's that I need real world experience, like ASAP, right. He's like, hey, cisco is a great company, it's so fine that you don't know any networking. Just come interview with us, right? That interview was weird too, because I like show up in a formal dress, right. I thought this was like other jobs, where you like get dressed up.
Speaker 1:I show up in a dress and they're like what the fuck, always overdressed for the interview. I am a firm believer in that. I've worn a suit for every interview and I've been looked at funny like bro.
Speaker 3:I respect that. Let's show up just with enthusiasm and they're asking me like, oh, how would you troubleshoot the network in this situation? And I came up with like two options. I'm like, I'm sorry, like I'm just here with enthusiasm, that's. I'm just going to be honest.
Speaker 1:I wouldn't write a Python script. That's what you said. Right, right, right.
Speaker 3:So, anywho, I started as an intern and I did transition to full time while I was still getting my master's. So talk about taking from a fire hose like brand new to two different fields, but anyway like brand new to two different fields.
Speaker 3:But anyway, I worked on the firewall team. I'm not going to say anything crazy about that, except I had to interface with developers a lot in a number of escalations, enhancements, whatever, and even just as being support for the entire company, right when there's kind of a food chain in the company. I think support's usually at the bottom. So you talked about like developers being in their ivory tower and being above support or also network engineers, and then I think you also got like sales, maybe above all that. So I experienced that 100% Like I would be the knowledgeable person. I would have done my research, I've taken my notes, I've filed a full on accurate bug report and then I sent it to the developer and they want to talk down to you or pretend it's not a problem or that you've gotten something wrong, or let me get on the call and try to figure it out for you, and just they'd be trying to talk bad about people, but they're so condescending, aren't they?
Speaker 3:Yes, yes, you just they would find as many reasons they could to reject a reason, to have to look into something. It just there is so much I could say about the egoism of developers. They are like the stallion, I feel like, of tech. It's the thing that people can see. It's flashy, it sounds cool. You just get a lot of egos in there, people who think they're the shit.
Speaker 1:This feels important because part of what we're talking about, I guess, is the cultural divide between our two worlds, and I actually I was half joking when I said ivory tower and stuff, but it's helpful context for me to hear that that's their experience coming in. I don't know if that happens in university, I don't know if that's the companies who bring them in and just want them super happy so they stay. Is it maybe both? How does that develop?
Speaker 3:Oh, that's such a hard question. So I think in college there is this I think there's a culture of ego in general. Right, it's in the professors, it's in the students who come in knowing that's what they want to do. They've been coding since whatever age, and then you have people like me.
Speaker 3:I just want to work together. I just want to build cool things. Like why are we being like this? So I don't experience this as much in network engineering. This is a pro I think of network engineering is that I don't feel like on a mission to out each other as being frauds, whereas you might see online like we're constantly talking about. What is a 10X engineer? What makes you a real developer, all this other bullshit and that does kind of start in college.
Speaker 1:I failed out of computer science, so I didn't get to experience any of that. It might've been. That's very helpful context for me, because that is really the that I feel like that's what I received in those outage calls. It's absolutely not my application, it's absolutely your crappy network, because I'm so smart and I know all the things. Somebody in the chat which I think this is a good place to bring this up why don't developers know what ports they need and what IP addresses they are using?
Speaker 3:So I actually I slightly alluded to this in my LinkedIn post today. But developers learn to code, period. We do not learn how our computer works. We do not learn how the network works. We learn nothing but to code, which I understand that partially. It is a hard skill to learn. There's a lot to it, right.
Speaker 1:There's enough. There the focus is placed there.
Speaker 3:but it is a real problem I mentioned in my post today we don't learn how to deploy our applications. I remember sitting in my classes and I was writing these applications and I'm like I wonder how people would access this. And this was before I worked at Cisco or anything, but there's just none of that.
Speaker 2:That's funny Cause I've always wondered about that from the developers here. I work for a vendor, so we've got the hardware that has the software running on top of it and we're constantly dealing with developers. We've got this bug, we've got that bug, we're looking at the mantis, we're going to see what's the schedule for that to be fixed, whatever. And I'm always wondering are those guys just really super smart and understand firewalls? Or are they really just building components that essentially run an automation script? So it just seems like a lot of times they don't know the networking side of it. They don't even know some of the security side. They're very different.
Speaker 3:To be totally fair, I think there's a lot of silos in tech period. There's not a lot of people who are just gung-ho about hey, technology impacts everything. I should learn right. But I think that the pain is just really high between these two groups of people. It's more noticeable.
Speaker 1:I'm a better network engineer today than I was five years ago because I have started to embrace some dev stuff.
Speaker 3:I've been watching your journey.
Speaker 1:I've been watching you.
Speaker 3:I saw you wrote your first Python script.
Speaker 1:That was like months ago, but Well, and it's really been, and now I'm in containers and Kubernetes and Linux and I'm really really enjoying it. But it's been a journey and there was a time when I wanted nothing to do with any of this and part of that was because and I think you alluded to this there's so much to learn with coding and development that you can just stay there because you need to know all this stuff and if you start putting in networking and firewall rules and all that stuff, it just it pulls you away from your core skill, and it was. It was kind of the same with me. I was so busy and drowning in work and keeping the lights on when they said, well, now we all have to automate and learn Python and CICD pipelines and get, I'm like I am drowning, guys Like so.
Speaker 1:So I publicly which probably wasn't great for my career, but I publicly cried about it and yelled about it for years because I'm like I am not a developer. I went into networking to not be a developer. But here we are years later. So I guess I feel like today, a better network person. I guess the developers if the developers can learn some networking and the networkers can learn some development, I guess that's the golden place to go.
Speaker 3:I think what's the real problem here is and I've tried to touch on this towards the end of my Cisco career and I'm going to try to continue doing it but where do you draw the line? Right, Because you need to learn some development, in your own words, but obviously you don't need to learn as much as as a software engineer. That wouldn't make any sense, you don't have the time for that, etc. So where do you draw that line and how do you make that easy for you? Right now, I don't think I really do. And vice versa. Right, as a software engineer, I had the luxury of working at Cisco and getting that network engineering education, but I wouldn't know where to tell a software engineer to start Like, oh, this is what you need to know, this is where you go to do it.
Speaker 1:And I don't know from a software engineer, like a developer's perspective, how they would even like do they have visibility when you're working in silos? I didn't. I couldn't even see or log in the firewalls in my environment. So if there was a problem in the path it was a firewall on my problem. So I don't even know what I'm expecting of a developer, like when something breaks, like can they? They can't get in my routers and switches, they can't. I don't even know what test you could run. Well, it doesn't work, like ping failed, right. But but I think in troubleshooting, if I think our customers would have been made happier, quicker, if I could work with a developer and they could work with me and we could kind of if I knew a little bit about their world and they knew a little bit about my world, and then, well, did you check this and what about that? And it just never happened in my career in networking.
Speaker 3:Well, and there's again there's like there's like five different again paths. I could take this down, but being at Cisco as the developer, interacting with network engineers, something I can also say. Even if you have that desire to bridge the gap and to be curious, we speak two different languages. Like I will even be talking about automation. I will hear somebody explain something I'm like why are they talking about it like that? Like why are they using those terms? Like that doesn't make any sense and they feel the same about me, right? And who's really to say what the right way to say it is?
Speaker 1:This is the challenge I've had over the years with automation platforms that people build is they're built by devs, so the terminology they use and the logic, like none of it. I don't feel like the network context is there. Hey, networking people learn the dev stuff because the devs wrote the stuff and here's what we have to do and I forget that. My job now is I'm doing stuff in automation and I see the data and we talk about it. It comes out like the network automation forum talks about this too and autocon and all that, but I think I don't know if 30% maybe of networks are automated and of that, very little. The number I keep saying publicly, which I think is somewhere true, is like somewhere around 70% of the world's networks have zero automation and until so, maybe it's people like us, it's people like you with the content you're making and if we can, you said something about the language. We don't speak the same language. So maybe if we can start to normalize, if you can normalize some dev language for somebody like me and make it-.
Speaker 1:I'm trying, it's hard though it's hard, but you're doing a great job, but it's hard work. But there's a cultural component of the networking industry resisting automation. It's another language. They're drowning in work. Blah, blah, blah. You just go down the line.
Speaker 3:Well, I'll be totally honest with you too, as I don't know how much expertise you guys should be required to gain in this area. I don't know. I kind of have my doubts about like she'll be providing tooling or like making this easier for y'all. Why does it make sense? You need to be network engineering experts and developers.
Speaker 1:And where's that line, like to your point, how much? And I guess we lean on the curriculum right, like I was Before my job. Now I was studying for my CCNP and there was a ton of automation in it. So we rely, I rely on educational materials from vendors to help direct me in like what I should know and how much of it I should know. And I think that because Cisco was such a big learning beast, right, there was a lot of automation. I know it's now in the CCNA and I know that there was a lot in the MP. So it seems like the industry, if their learning platform is a barometer of the industry, is moving in that direction. But I don't know how much we need to know.
Speaker 2:And, like I, think you need a.
Speaker 1:GitHub account for like interviews. I'm like crap, wow, but that's a thing. It's getting serious. It seems like it. Right, I have a GitHub account, I follow people, I star things, like I put like I don't even know. So here's where I'm at. Like that python script that you talked about, that I that I did. I don't even know if I should put it in there because I stole it from somebody else from a course I was taking. Well, like because I know there's a joke like everybody steals each other's codes. But I was taking a class and they showed me what to do and I did the thing and oh yeah, but does that go in my almost nobody's writing it from scratch.
Speaker 3:Yeah. Coding is a big word right now. Oh my God, you're going to stress me out, but that's that's where you're at in your journey. Like we all start with the copy paste exercise, generic projects, blah, blah, blah. So no one's going to out you for that. But what? Where I really feel bad for you, andy, and for everyone, is that developer education sucks pretty bad, like we do not know how to teach people to code.
Speaker 3:That's why more people don't know how to code. In my opinion, whether or not you want to be a developer, not only does developer education suck, but then you try to apply it to network engineers, where you have to apply domain expertise, which is a whole nother ball of wax. Right, and I don't want to say that you guys are set up to fail, but it's definitely not easy.
Speaker 2:It feels that way. I'll tell you what I think, actually what the problem is. In the chat, systemmtu1 wrote that he'd appreciate it if the devs would stop putting in the message telling people to contact the network administrator.
Speaker 1:That's why we have to learn all this stuff because we're the ones that get contacted.
Speaker 2:And that makes it a mean joke.
Speaker 1:So here's the interesting thing, and I don't like it. I didn't like it then, I don't like it now. But somebody else said it in the chat earlier. They alluded to the network. Engineers are expected to know a lot about, or a little about, a lot of things. So when the app team says the network's broken, it's on us to prove it's not. And that is a lot more than just proving out your network. That is a lot more than just proving out your network. So and that's what's always frustrated me is I'm paid to be a network engineer, but I also have to have domain expertise in everything that lives in the environment. And now I have to be a dev for no more money. Like that was my big, like really I'm drowning. Now I gotta be a dev just to keep my job. Like it sucked.
Speaker 3:I've noticed that this seems to be a trend in tech in general too is all of the fields are blending. Right, where one field starts and where another ends is blending a lot, and at a bigger company for sure like a dev is just going to code just that halo around their laptop, spend their two hours coding for the sprint and then done. But a lot of companies for instance, I was a software engineer at a startup and same thing, right Like I, they're just like all right, we want you to create a CICD pipeline. I'm like I've never done that. Okay, like what are the requirements? We don't know, just make something. Okay, learned AWS. So you're just constantly being put in these situations where you have to somehow rapidly become an expert at things, and I think that's really hard on us. I don't think it's very realistic. I had another point, but I forgot it in explaining that.
Speaker 1:It'll come back. You have my attention with the education piece because I have signed up for, started and quit every single Python class that exists on planet Earth, every single one, oh yeah, so to your point. I thought that maybe there was something wrong with me, but maybe not to say there isn't. But maybe there was something wrong with me, but maybe not to say there isn't, but maybe there's.
Speaker 3:Also, it's indicative of the education, like you said this is my whole platform making it fun, making it simple. Cut out all the bullshit, all the 10 X engineer stuff, whatever I think, and also I know we all like to rag on AI and how much we're annoyed by it. But some positives of the whole AI thing. First of all, they're coming out with AI intelligence agents and I think there's opportunity for people to develop one time right.
Speaker 1:What is that?
Speaker 3:So an AI agent? It's basically someone writes an application that calls an LLM to do stuff for you, Instead of just asking chat GPT. I don't know what does this error message mean? Right, you can code an agent that asks the LLM, the the error agent error message is, and then, oh, if it's this, go ahead and do this for me, right? It's basically a form of ai automation is, I guess, a good way but anyway these are the kinds of things that I think that we need to be.
Speaker 3:I think we should be pushing companies to develop for us. I would like companies like cisco to be developing more of this on behalf of network engineers. These, these are things that you guys need, versus just hey, you guys need to learn to code everything from scratch.
Speaker 1:What do they need to provide that they're not? Like right now they're putting all this automation I'm not defending them they're putting all this automation stuff in the certification guides that we use to shape our careers. What do they need to do that they're not? You think? Lean more heavily on the end. I just think that they're not you think, lean more heavily on the AI.
Speaker 3:I just think that they should use the technology available to us and bake things into products or offering agents. You can start linking agents together to do multi-action tasks right. Cisco would be a great person to do that for network engineers. Create a multi-agent framework to do whatever. Whatever tasks that you guys want done right.
Speaker 1:Let's explore one of my cognitive biases around automation and AI. Is gasoline on that fire? I have a feeling. Well, no, I love it and I use it.
Speaker 2:Oh, then my wheels slumber.
Speaker 1:It's super helpful, right, automation is going to take our jobs. That's one of my core fears, right and now, when you just explained AI agents, I hear you, but I've heard a lot of developers say they're not going to need us because you can create and develop applications with AI. Now Is automation. Here's a reframe that I've had. I'm going to ask you a question, but this is all. Just.
Speaker 1:I've been in this world for a couple of years just being very curious about automation and the problem in networking and it's going to take our jobs, right. But there's also the shortage of talent. We don't have enough network people. So that kind of changed my mind. Like, oh well, if we can leverage automation tools and AI tools to help bridge that gap, so that I'm not working every maintenance window every day because there's too much work, so I kind of see the benefit in that. So I used to be afraid of automation and AI taking our jobs, but if there aren't enough of us if that's true I think it's true I don't hire. I guess that can help bridge that gap. Do you think automation and AI is going to make network engineers and developers go away?
Speaker 3:At least not anytime in the near future. I'm not an oracle, right, so I can't say when, but not in the near future. And the point of automationary is to take away basically tedious task, right, we're not going to get rid of people with brains and we're not going to get rid of people who can talk to people. If you are developing your critical thinking and problem solving skills and you're not an asshole, then you're going to have a job.
Speaker 2:It's true. The other thing I think, andy, when we talk about some of the AI stuff and the automation and really learning to develop and all that, I think what it ends up doing is it makes it so that an engineer, a single engineer, can do the work of 10 engineers. Now I don't mean that you replace 10 engineers. You can be, as an organization, more productive across the web. I saw Erica's eyes almost roll out of her head when I said vibe coding, because it's such a buzzword everyone's using right now. Who would have vibe code?
Speaker 1:I refuse to look it up. I saw my buddy Dwan talking about it and I'm just like I can't. It's almost like social media. I can't create another account to try to stay relevant. I'm just over it all. But now vibe coding. I'm like no, I'm still trying to learn.
Speaker 3:That's where you draw the line.
Speaker 1:I just can't do it. I'm still trying to learn Python, Like vibe. We talk about it. We're here. What is Vibe coding?
Speaker 3:I had to look it up because people were approaching me asking my opinion on this. I'm like I Googled it and apparently Vibe coding is a trend where you're using AI to code, like using prompts, right, and then it spits out code, and that's not necessarily weird. The weird part is you don't have to understand the code. You just spit out code and if stuff is working or you think it's working, then you're done. So vibe coders don't believe you need to understand how to code. You just tell AI what you want.
Speaker 2:And I 100% do not believe in that, and that's so. My brother is. He's a developer, he's big into AI and what he's able to do with his AI agent, versus what I'm able to do, who has very minimal development skills. He's able to do incredible things because he knows how to code. He understands the inner workings and what this thing can actually do. He understands the words to use. He understands how to say the right development words. You were talking about different languages that we're speaking here. He understands the language and the AI understands the language and he can better portray to it what he wants done, whereas I have to first figure out if what I'm asking it is even possible.
Speaker 3:Right right.
Speaker 2:He knows that at its core. But I do think that's where the AI stuff is getting interesting is. I think that maybe we don't necessarily have to know every command. Like you talked to, andy, about dropping out of Python, I wouldn't drop into a course right now on Python. I would start writing code. As much as we hate this word vibe coding it's worth doing a little bit with the AI so that you can start saying oh, you made this little change here, andy.
Speaker 1:Well, the problem with that for me is, I want to understand the fundamentals so I know what the hell I'm doing.
Speaker 3:Okay, this is great.
Speaker 1:And if then I really want to know. There seems to be like 10 to 12 fundamental concepts that would really be helpful if I understood them. And when I try to learn them I start to get lost in the layers of abstraction and I don't know where. I get lost and I'd have to walk you through it in real time and then you could see it happen to me. But okay, get lost, and I'd have to walk you through it in real time too, and then you could see it happen to me. But okay, I know a variable, I get that we're assigning a value to something in memory, great. And then we're going to do like a logic thing, like and if then okay, I get that. But there's some point where we get like four or five layers in that I'm like wait, what, what happened? And we called a function and then some library like something do that. But I really really sincerely want to learn just the fundamentals of how it works, just so that I can understand what the hell is happening.
Speaker 2:Am I doing myself a disservice? Did you take Spanish in high school? Do you speak Spanish?
Speaker 1:I will answer in Spanish, no.
Speaker 2:Right. The reason I bring that up is because when you take a language in high school or in college or whatever, they start you with the fundamentals.
Speaker 1:That's where they start you.
Speaker 2:They start you with how to say all the past tenses and all that. That's just not how you learn a real spoken language, and I feel like the exact same thing is true when it comes. At least for me, that's been my experience.
Speaker 2:When I want to learn a language, I go try it, because I'm going to learn how variables work when I figure out that I've written the same code 10 times and oh, that's the only thing that changed. Okay, great, Now I understand a variable. I'm going to learn if-then statements by having whether AI fits it out or I copy somebody else's code and I've looked at it a bunch of times. So I think learning to read it and understand what it does, rather than saying I'm going to know the fundamentals first, Cause I don't, unless we started in a formalized classroom. I don't know, Erica, you took classes in coding. Do you feel like that's where you learned the most, or did you learn it by doing, or I don't know.
Speaker 3:I'm gonna let you answer that again. So many things to say. I did not learn anything that was real world and practical in school, so I learned all the theory. That's a great foundation, but doesn't translate to actually building crap, right. So to your point there. You, you truly learn the skill by building and by practicing the skill.
Speaker 3:And then you both kind of had opposite opinions on the whole learning with AI thing or coding with AI, and that was a great point for me to shamelessly plug something I'm working on, which is I'm in the middle of creating a free, completely free course where it's geared towards network engineers and it teaches them how to code using AI. But there are levels, right? Level one is these are the concepts you have to know before you start using the AI. It's Andy's point about foundational knowledge. It's not a bunch of computer science theory bullshit that you're not going to need to know later. It's just these are the important concepts. Boom, boom, boom. Then I teach you how to use the AI chat right, because AI chat is just basically easier. Google, these are the concepts you can learn with this guide, et cetera. And then it moves on to level three, which is what Jeff's talking about, which is I'm not going to call it vibe coding, but it's using the code generation portion of it.
Speaker 1:Where do I and everyone else sign up for this, because I really need something like that. I think you addressed the first thing you said, which was that we have an education problem, maybe with development, and that's been my experience. I still am not proficient in Python and gosh darn. I've been trying for a really long time and maybe that's a tool I haven't used I roll my eyes because I'm just so worn out on the whole AI thing but it's a great tool when used right? So how do I sign up for what you just talked about?
Speaker 3:Subscribe to my YouTube. Erica underscored the death.
Speaker 1:Come on, man Say what, are you already subscribed, are you? Oh wow, I'm flattered.
Speaker 3:I only have like 18 subscribers right now, so you're an elite class.
Speaker 1:right now I'm subscribed to your Tiki Talk. I don't know if I'm subscribed to your YouTube.
Speaker 3:Don't worry, I'll be shamelessly promoting it very frequently soon, so you'll get a reminder if you're not already subscribed.
Speaker 1:Are you going to do a series? Okay, but it'll be like a series of videos or Yep, so it's a course it's going to have a guide and an assessment guide too, right?
Speaker 3:So if you don't have somebody at your workplace, maybe you just find a developer buddy, or maybe ask me whatever, and they assess whether or not you gain the competencies at each part. Each video is less than 20 minutes. I try to make them way shorter than that if I can. Then you hands-on practice it and then you get assessed and not just, oh, what was this? But hey, let me ask you a deep thinking question about whether or not you've got the concept.
Speaker 1:Damn. What's this going to cost me?
Speaker 3:It's free, free 99.
Speaker 1:Free 99. I really like this approach. I feel different than other things I've tried.
Speaker 3:It's an experiment, but I'm also open to feedback too. So it's version one, and if y'all are like, hey, this part of it is where it kind of pooped out, then we'll fix it.
Speaker 1:That sounds awesome. I'm just trying to catch up.
Speaker 2:I finally got a dev that's listening. Andy, Do you hear that?
Speaker 1:Oh, is there one in there? I feel like we've been talking a lot about automation and networking and I really think that it's. There is a maybe it's because of what I'm doing for work right now, but there seems to be a shift happening Again. If you look at the education stuff, if you look at things like autocom, if you look at data, like there's a shift happening in networking and there's people who are still dug in. I know one of my buddy who told me he's like dude, I'm in the public sector, I'm not learning this shit, I'll be out of here before they make us do it, like, and I'm like, hey, okay, like that's a choice, right. But then there's there's people like me who are like really thirsty for this knowledge, like I don't want to.
Speaker 1:I don't want to age out or skill out or become irrelevant, like I I would like to be able to. The example I always use in a place that I worked, we had to update the SNMP community string of like hundreds of devices and the only way I knew how to do it was going in one at a time with my notepad plus. Plus, it was going to take forever. Right, it would have been impossible to do all those. And we had a Python guy on our team and he spent a couple of days showing me and I think it was done in like two, maybe three nights, just because we were trying to be careful. But then what do you think me?
Speaker 1:months to log into 600 devices and make a change and a pre and post check and like and a change for each one like change would have been a nightmare. I see the value. It's just I don't feel like I can do that and I'd like to be able to like. He did it, he showed me. But every class I take I just hit that, I hit a layer of abstraction where my brain just explodes and then I kind of like run away and get scared.
Speaker 3:Back to your point a little bit too about the motivation of it. The conversations I've had where people are managing 600 switches or other ungodly numbers of devices, they're usually also people who are doing the jobs of three people. Most network engineers I know are very overworked. I think that's another great use case again for automation. It's really just maybe just take it down to like two people's jobs.
Speaker 1:It's really just maybe just take it down to like two people's jobs. We talked about this recently that I really think time is the greatest lever we can pull in this conversation that we're trying to have across the industry. Like do you want to work endless maintenance windows doing mundane crap? I don't. We had a guy on years ago Daniel, he's an Australian, he's a big. You might know him, he's a big automation guy, but that's what he told me. He's like.
Speaker 1:I and Jeff said this a hundred times I'm doing this to save time in my life. I want to go ride my bike and be with my family and play my guitar. I don't want to be working around the clock because there's too much work. If I can do the work of three people and with with some tooling, that gives me more time, andy, I'm like all right, this is I like time, especially the older. I get like to have as much as I can and to spend it doing mundane, stupid stuff the slow way because it's the only way I know just doesn't make sense. I don't know if that's we're not the first people to say that, but I don't know how you can talk to someone and say well, do you want to spend less time doing your job and getting paid the same, like you could do that.
Speaker 3:But to your point too. It doesn't matter how badly you want that If it's not easy to learn.
Speaker 1:It's not easy to learn. It hasn't been for me at least.
Speaker 3:Well, y'all will have to give me feedback because genuinely, this is this is part of my mission, so I can't promise I'm going to get it right the first time, just a dumb old dev over here it happens.
Speaker 1:And I'm not blasting them because everybody loves them, including me. But there's the Kirk Byers Python. He does it free every year. It's an amazing course and I've signed up for it three or four times and every time I sign up for it and start it, I forget that in the first class, if you don't have any experience, you have to start with this 300-page book before, and then I'm like, oh hell. And then that's another thing that I give up on Now. If I would have just got the damn book five years ago, the first time I tried and worked through that and it's a great course and it's got labs and videos and like I should have just done that. 15 bucks, so stupid. But any friction that gets there. I just kind of like, oh, I really want to take Kirk's course, but I got to do this prereq and I guess it's. It's just such an inside job for me. It's just all this kind of emotional and if I'm going to make the decision to learn this stuff, I'm just going to stop bitching about it.
Speaker 3:Well, here's another mistake with the courses that I think is making everybody's lives hard is that truly learning development in any form is not just oh, I'm going to pick a language and start learning it.
Speaker 3:You have to learn to think like a developer, right? So I have like a goldfish memory, so I'm not gonna remember like the parts of your brain, right, but basically, when you code, you're not using like the language parts of your brain, you're not using the math parts of your brain. You're relying on multiple parts of your brain that you do not rely on when, when doing any other task, right, literally exercising your brain in a way it's not used to being exercised, and asking you to solve problems in a way that you're not used to solving them. But big part of my foundation isn't teaching you syntax, blah, blah, blah, bullcrap. It's teaching you how to think right, and that's. Once you have that, the frustration factor goes down a lot, because you can Google a lot of coding, right, you can Google oh, how do I do this in Python? Again, right, but Google's not going to tell you how to think like a developer.
Speaker 1:This is the first time again that I'm like I wish I talked to you years ago. This is the first time I'm hearing that, that it's even a different mindset.
Speaker 3:Well, it would involve a developer or somebody who knows how to develop having the humble pie to know that anybody can learn to code if you teach it in a way that makes sense. We just kind of like throw crap out there and know, like, if you take it like fish to water, then you are graced by God, Like we're going to knight you right and if and if not, then just you're banished to apparently the network engineering. I don't know, but you're managed somewhere.
Speaker 1:Well, that's what I meant about an inside job. Like we're all shaped by our experiences and because my first semester in computer science I was put in C++ and calculus and just couldn't hack either. At a very young age there was this imprint made in me that like maybe I'm not smart enough to do this. A million years later, here I am and I'm trying to learn these things, and as soon as they're hard. So I really love kind of how you're framing it and even just thinking like a developer. I think you might have unlocked something I have hope, like I'm actually I'm genuinely excited, not just because you're on the show, but I have been searching.
Speaker 3:Don't fake it for me again. You have to be honest with me, don't fake it and anything for network engineering.
Speaker 3:to be totally honest, right, because hopefully this is changing. But, like being a woman and being from the country, like I didn't learn to work with any like tools or anything physical, right. So I started as an intern in network engineering at Cisco and we started out in the lab where we recruited customer environments right. So my job was literally to like, rack and stack cable up devices. I was highly uncomfortable doing that the thought of just literally figuring out how to unscrew a router from the rack. I know that sounds so dumb, but there's this mental block about.
Speaker 3:I've never used a tool, I'm not capable of doing this, and then you just shut down, right.
Speaker 1:Were you able to navigate that and just work through it? I guess you had to. You didn't have a choice.
Speaker 3:I'll be honest, I think it's a. It's something that still gets me every once in a while okay um, but back then. No, no, I didn't so me me and the only other girl intern we made. We had an unspoken oath. We have to figure this shit out. We can't tell you, but we don't know how to do use a drill, and we spent an entire day on it. So no, we didn't, we weren't wise.
Speaker 1:Isn't it interesting how, when you have to do something, like when there isn't a plan B, like I was, I was a cable guy for years and my body was getting beat up and I wasn't making enough and there was no way out of it I had to get that CCNA. I had, like, I had no plan B, that was it. I have to get this because this is what I need for the job. That it's just interesting. And I haven't had to learn to code, like it's just right. If I had to, it was like well, bro, you're not going to be able to eat in six months. Go learn Python. I'd be pretty good at Python, right. Like, because, to your point, like, I didn't use tools and I got to screw stuff and it's freaking me out and my brain just shuts down. And then I, I listened to my core but I can't do this, right. Well, it's bullshit. You got to fight through that shit. And if you have to fight through that shit, you have to fight through that shit.
Speaker 3:Yeah, we're all kind of just the culmination of our experiences and it's somewhat random and it's not as much choice as I think we like to pretend it is.
Speaker 2:Yeah.
Speaker 3:Not as if we don't have control of our fate, but just opportunities. Come your way, Blah blah. Think you have to threaten us in your class.
Speaker 1:Learn this or else no, I'm going to keep it fun. I can't do that to you guys. So before we start wrapping it up here, there was a comment that I just wanted to find that I loved. Hold on.
Speaker 3:He said oh, I'm scared You're laughing, it was, it was it was really good System.
Speaker 1:Mtu once said in quotes not an asshole.
Speaker 3:Putting that on my resume, something you said earlier which is hilarious it's true, if I was a hiring manager, that'd be a number one criteria. How tired I get of working with assholes. I'm just in every form of engineering. I hope the bar gets raised.
Speaker 1:I don't know if you can comment on the DevNet, sir, but we do have a question from RoboDaddy. He got a CCNA in 2017. He's thinking about going after DevNet. My first question is why? Why are you going after DevNet? I thought of going for DevNet Associate just because, again, it would force me. Okay, I paid the money and I'm taking the stuff and I'm going to publicly say it, so I'm accountable. That's kind of my little hack. Let me embarrass myself publicly until I pass this thing.
Speaker 3:Nice.
Speaker 1:What do you think about the After we just beat up on? There isn't good dev stuff out there. What do you think in general? If you can comment, maybe you can't, I don't know, so wait, what was the core of the question? I guess the DevNet. Well, what do you think of the?
Speaker 3:DevNet cert. Like, is it a good? It's hard to answer that without knowing, like, where this person is at. So to me, the DevNet cert is partially bridging that gap between the developer and network engineering worlds, right? I personally don't feel the place to go to learn how to code and don't feel the place to go to learn how to code, and it's not the endpoint for your automation journey. So, for instance, as a developer, I earned my DevNet Associate. There was it was pretty basic Python that I had to review. There was nothing really to review, but it was more what kind of tools will you use in order to automate your network? Or what? How do you use Cisco APIs when doing automation? Or maybe some common libraries that you're going to use in Python for doing automation? So if this person does not know how to code, it's not going to teach them that and I would personally start with some form of that first, have at least a little bit of comfortability coding or with Python, and then I would take the DevNet associate.
Speaker 1:And maybe before that you let Erica teach you how to get in the mindset Right Think like a winner. This is news to me. I didn't know there was a mindset, jeff, this is where I've been screwing up.
Speaker 2:I thought I could just learn Python. If you can dodge a ball, I think part of it is. I have a different theory on the automation. My theory has always been if I have a three-hour project and I can just go and I can knock out the whole thing in three hours, I would rather learn how to automate it in five seconds, but take three hours to learn that. So it may have taken me the same three hours, but I didn't do the same task over and over for three hours.
Speaker 1:I learned something new in three hours and then did the over and over task in five, ten seconds. I've watched Jeff do this and I think the difference between you and I, jeff, is you can sit there for three hours and actually do that, like I've seen you do it.
Speaker 2:Once I get, once I'm focused on that I will tell you when I'm coding and playing around with and again, I'm not coding from scratch, I'm stealing other people's code and understanding how to rate it and fix it.
Speaker 3:As you do, yeah, as you do yeah.
Speaker 1:But Jeff makes it easy, oh yeah Well, he just seems to Compared to me. I'm comparing myself to Jeff. Jeff, I hear you and I'm not disagreeing with you at all. I think for me you're somewhere To your point, sure, spend three hours figuring out how to automate it. I can't get through the first 10 pages of a Python book without spinning into the corner.
Speaker 2:That's what I'm saying. I spinning. I've never. I've never picked up a python book. That's what I'm saying. I've never.
Speaker 1:But you're figuring it out without that, and you were doing it even without ai when we used to work like together back in the day. So I've always been amazed at you who just kind of figures it out. Right, like you can just figure it out where me. I'm like can somebody please teach me the skill set I need to do this? Like if you told me to just go figure out how to manage a production network. No, I needed curriculum.
Speaker 1:But you're one of those guys that's just like oh, I just I figured it out, I'm basic and I made a call.
Speaker 2:If Erica looked at my code versus someone who had taken the fundamentals, she'd be like what in the hell is this guy doing? Because I would have gone a roundabout way to get there, but I'll still get to that end. So mine may run versus a five second script, but I'll still get there. But I think we're some of the fundamentals that you were talking about, erica, and I think this is kind of what you're leading to your teaching or hoping to teach. Is that thinking like a, like a dev person? For example, my versioning process consists of dave, uh, every so often and oh, cred forgot to save and oh no, I have to roll back six different old z's because I screwed up somewhere and I can't get out of this hole. And I know that there's version control and stuff like that. I think you learned that. I never learned that, so all my stuff's messy but it gets done.
Speaker 3:And that can get complicated to version control Like it's its own beast. Yes, that will be in my course, but to give you credit, I think that what's most important is doing it in a way that is fun for you. So if you have the most, like my husband's, the same way like when we were we met in network support actually, but when he was in network support he didn't even do training. He's just like no, just just let me shadow dive into cases, I'll learn it whatever. And I was the opposite. I was hyperventilating like I was reading a book and taking notes and like I want to be prepared.
Speaker 2:You're so disappointed, andy was like he couldn't sit in code for three hours. I couldn't sit and look at a book for three hours. I'd lose my mind.
Speaker 3:But it's just knowing yourself right. You dive in and then, once you've reached you've exhausted the point that you can in figuring stuff out yourself, maybe you go back to the book, at least a little bit.
Speaker 1:So I'm really looking forward to your class. I'm just, I wrote down a couple of things that I'm very interested in, but I haven't been able to cross that chasm by myself, like when I had a job where my buddy was writing a Terraform provider and it's the first time I saw Terraform and infrastructure as code. And again when smart people who know how to teach he walked me through it and I'm like I think this doesn't look that bad, like I think I could. Now someone brilliant showing me how they did it is a way different experience than me sitting at a terminal trying to figure that out. So I'm trying to like I'm fascinated, I'm curious, I want to learn infrastructure as code. I think Terraform is really cool.
Speaker 1:Apis are all the rage, like GitHub and CSCD pipeline all amazing. But as a network person who struggles with that whole world, I'm genuinely excited to see what you have coming out, because I haven't found maybe it's that certification the person talked about earlier, I don't know, I didn't take it, but if someone could just A get me in the mindset which you referred to and then B just start walking me through, like here's the stuff you have to know as a person who wants to learn all of it and be proficient. I don't want to write applications, but I'd like to be able to look at a Python script and know what the hell's happening. Or maybe automate some stuff around the house. Or, like Jeff talked we've talked before about like stuff I could automate. Like every time I come home I have to push 15 different buttons on my phone to like turn the alarm off, open the garage door, like do the heater thing, and he's like well, I wouldn't even know where to begin. So I'm really excited to see what you have coming out, because I want to.
Speaker 1:I just don't know how to get there and it sounds like you could be the bridge to to get me where I'm trying to get to, because I just haven't. You have to change your handle.
Speaker 3:Right, erica the Messiah, that should go over. Well, put a little halo above my head. I'm sorry Not to be like sacrilegious. Overwell, put a little halo over my head. I'm sorry Not to be like sacrilegious, but I don't. I lost my thought. I'm not a night person. I just I'm here for like the positive vibes, but like internally me is like asleep.
Speaker 1:Well, listen, this has been fantastic. I've really enjoyed it. Jeff, did you have anything before we wrap it up? I've learned a lot and I really appreciate your perspective, erica. I've never actually had this conversation with the developer and I've wanted to for a very long time. I wanted to yell at them because of it's the network and it's not in blah, blah, blah, but you've really given me a lot of insight and context. I didn't have the egos that they have and the way they groomed and they come up and they are treated well because they're rev gen and like there's just a lot of cultural elements happening and now the network engineers like us have to learn it and then the material isn't good. But you've developed other stuff, like I've really enjoyed this conversation and you've opened my eyes to some things I didn't know and then told me some resources that are coming which I'm really excited about. So this has been helpful for me and that's the whole deal.
Speaker 1:Here is like we can have good conversations and help us than I did an hour ago about me learning automation.
Speaker 1:Well, I do, and every time I talk to Jeff, there's certain people in the community that, like when you talk to them and they're proficient in automation, but they're not those egotistical assholes, it kind of they're pulling. I feel like you guys are all pulling me along. John Capobianco God bless him has tried to, but he's just so far down the automation promised land that he lost me Like I should have oh, I didn't AI. Like he right Automation and now AI. He's just taken over the world. He's going to be running the matrix soon, but this has just been really helpful for me. Jeff, you got anything as we wrap.
Speaker 2:My final thoughts are actually a last week thing is when we were actually supposed to meet with Erica. It didn't. I was like I need to go look at her LinkedIn page. I got to go read up on who this person is that's going to be on the show and I well, first off on her LinkedIn page there was some kind of like a hangman code thing that me and four different AIs were trying to decode and we never got to. But the real rabbit hole I ended up going down was just going through some of her content. She does a great video on how the internet works, something that I could send to my mother and be like Mom, this is how the internet works. I ended up just kind of going down a rabbit hole, erica, and watching a bunch of your stuff, and I can say I've become a really big fan. Thank you.
Speaker 2:Anyone watching this just know Erica is able to take some complex topics, put them into really simple, easy to understand, and what I like is bite-sized chunks too. Like none of the stuff you're doing is so long form that people feel like they have to really commit to it, so you can catch it kind of as a drive-by. So I just want to kind of give that pitch and say that I didn't intend to go as far down the Erica rabbit hole as I did, but it's been really good it's like crack.
Speaker 3:May I also add one concluding thought?
Speaker 1:Add to it.
Speaker 3:Because I feel like I took us down many rabbit holes and I wanted to just say one final thought on bridging the chasm however you say that word between software and network. So I do think that DevOps is a great middle point, right. A lot of software engineers I talk to are really interested in DevOps and it kind of turns them on to the importance of the network and why they might learn networking concepts, and likewise, a lot of network engineers are asked at various points to learn that. So I think that's a great commonality. Also, just this applies to like all silos, right, but like just being curious and empathetic, like as technologists if we're real technologists, if we're real technologists, we should be being exploratory and curious about other people's fields, right, when anybody wants to hit you with their ego, be like, well, a real developer would have learned some fucking network engineering. Like, just just just lay it on them. A real technologist would have done this. Right, because that's the truth. And then, and then be empathetic, which was not empathetic just then. But you get what I'm saying.
Speaker 1:That's what I, as I do. Yeah, so we're at the end. And when you say devops, like that could be a whole separate conversation because like I've heard the term, I know it's developer and operations and kind of like a blend. But like, how does one devop? Like, is that a cultural thing? Is that?
Speaker 3:a dance. Oh man, maybe another conversation you're tired.
Speaker 1:I don't want to keep you.
Speaker 3:I I'll be fine, I'm just going to go to sleep. It's not like I've got some exciting plans, but so it's somewhere between people just throwing crap together, trying to automate deployments and actually following best practices Again.
Speaker 1:I'm not a.
Speaker 3:DevOps expert right. I just was forced to somehow throw together a CICD pipeline for that startup I worked for, icd pipeline for that startup I worked for. But it's essentially automating release cycles, right. You have like a staged environment, you have a production environment and it seems to be both network engineers and software engineers who end up in that role. It does involve usually some infrastructure as code, but it's also a lot easier lift than actually learning development.
Speaker 1:I like it.
Speaker 3:It's not my cup of tea. I don't find it very interesting, but Okay awesome.
Speaker 1:Erica. You are fantastic. I love everything you do. Your content's amazing. Where can people find you if they're living under a rock and don't know where to find you?
Speaker 3:YouTube, linkedin, tiktok, instagram and sort of X. Erica underscore the death and I really appreciate you guys having me on. This is like the Hollywood of network engineering being on the art of network engineering. I took offense to you thinking I did not know this podcast. I had watched episodes. Also, I studied for this podcast. I wasn't going to go live, but thank you guys so much for having me on and humoring me, thanks.
Speaker 1:You did fantastic. Thank you so much. Thank you, Jeff. Thank you. Where can people find you, buddy?
Speaker 2:I mean, I'm just so boring. Find me on LinkedIn or go to the Discord for Jeff, I need to start posting online but I just don't. I got two kids and a job that I really like doing. Jeff's tired yeah.
Speaker 1:Jeff, be tired. Well, guys, thanks so much for coming on. For all things Art of Network Engineering you could go to. Where am I going to send you Our link tree Link, tree, forward slash. Art of NetEng has all the things Most notably our Discord server called.
Speaker 1:It's all about the journey that came out of a study group that aj had started because we were all failing the ccmp and we needed some help and and a community. He he said it best. He's like I don't know why I thought, joining up with a bunch of other people who failed the exam, somehow we would come together and and it's grown into a beautiful community. There's like 3,500 people in there. There's rooms for every kind of tech stack that you would ever imagine, and people are in there studying and study groups. So if you don't have a community, I highly suggest checking it out or finding a community. You don't have to do this alone. I tried to do it alone. It stunk and now that I have people it's so much better. Thanks so much for joining us for another episode of the Art of Network Engineering and we'll catch you next time.
Speaker 1: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.
