Chris Miles: 0:00

Hey everyone. It's Chris from Cables to Clouds here. I hope everyone is enjoying a nice holiday break, spending time with loved ones, family, friends, all of the above. I think this episode's actually coming out on Christmas, so if you celebrate, merry Christmas and upcoming Happy New Year to everyone as well.

Chris Miles: 0:16

Before we get to the episode, I just want to take a second to let everyone know that Tim and I, along with one of our critically acclaimed guests, one of our critically acclaimed guests, one of our most downloaded episodes, I think in the past with Steve McNutt, we've all come together to release the first edition of a certification guide for the AWS Certified Advanced Networking Specialty Exam that is being put out by PACT.

Chris Miles: 0:43

So the book is actually up for pre-order now PACT. So the book is actually up for pre-order now. So if you're interested, if you're doing anything with networking in AWS, I would heavily, heavily encourage you guys to check it out, even if you're not preparing for the exam. I feel like it's just a good overall composition of all the networking services within AWS today. So the book is officially up for pre-order now and I believe you get early access through PACT if you do the pre-order. So I will put the link in the show notes and if you're interested, I encourage you to please check it out. And with that out of the way we'll get to the episode.

Tim McConnaughy: 1:11

Thanks, Welcome to the Cables to Clouds podcast, your one-stop shop for all things hybrid and multi-cloud networking. Now here are your hosts Tim.

Chris Miles: 1:22

Chris and Alex.

Tim McConnaughy: 1:25

Hello and welcome back to another episode of the Cables to Clouds podcast. I'm your host this week, tim at carpe-dmvpn on Blue Sky, and with me, as always, is my co-host, chris at the Cloud Main on Blue Sky. And, as you may have guessed, we have a guest with us this week. We brought Erica Dietrich here to talk about cloud development. I'm going to let her introduce herself in a second, but you know, one thing I've always been pushing for is that I want to move across the stack. I want cloud infrastructure and cloud network people to get more understanding around what's riding on the network, because I think we need to have opinions and be opinionated about that. So, yeah, I just wanted to bring Erica on here and talk about cloud development. So, erica, go ahead and introduce yourself.

Erika Dietrick: 2:14

Yeah, so yeah, my name is Erica Dietrich. I'm a developer advocate at Cisco. I'm part of our developer program there and I'm basically enabling people to learn network automation, to use AI tools in their automation workflow. And, like you mentioned, tim, a lot of our community is also infrastructure and network engineers or cloud engineers. So I get to talk to a lot of that community and I spend about half of my time building things, breaking shit learning, and half of my time, you know, building things breaking shit learning and half of my time communicating.

Tim McConnaughy: 2:48

So getting presentations being on podcasts like this, annoying people on social media, all that jazz yeah, no, that's awesome, let's see, so let's, let's just, I guess, just let's just jump right into it. So talk to me a little bit about, first of all, just about what your day-to-day looks like, but also about what you've been doing with cloud development.

Erika Dietrick: 3:12

Sure, day-to-day ranges wildly. I would say that we work in seasons. I think that's a developer advocate thing, not just a me thing.

Chris Miles: 3:21

It is.

Erika Dietrick: 3:24

We work really hard towards big outputs.

Erika Dietrick: 3:28

So, whether that's, you know, a awesome YouTube tutorial video at the end of the month, or whether it's a Cisco live coming up, that we're preparing the DevNet zone and a bunch of talks, it's very periods of head down delivering and then kind of a recovery period head down delivering and then kind of a recovery period.

Erika Dietrick: 3:44

So I would say on a typical day for me, I'm usually doing my community interaction first thing in the morning, posting to social media whatever it was I learned and cobbled together the day before, try to be somewhat useful and educational and interact with the community there, and then it varies widely. Again, we've got Cisco Live coming up in February, which seems like it's really far away, but it's really not. So usually spend a good chunk of my day trying to ignore everyone after that and, you know, become an expert at whatever it is I'm talking about, because that is a big misconception is that we're just complete experts at everything we talk about. We're like everyone else in tech. We have to learn and then we teach, and then the afternoon I like leaving an ample amount of time for shit catching on fire.

Chris Miles: 4:38

So honestly, my app is pretty flexible, as it does.

Tim McConnaughy: 4:42

As you do Okay, no, do yeah, okay, no. That's great. It's funny because I have many developer advocate friends and it's pretty simple across all of the different silos of developer advocacy. That's the main goal, if you will.

Erika Dietrick: 5:01

Very different philosophies around it, for sure. It's just very different from company to company, org to org, and Cisco in particular, it's a little more challenging because we're not a traditional developer program, that's true.

Tim McConnaughy: 5:13

We're talking about DevNet, of course. Yeah, yeah, yeah, so that's a very good point. Actually, most of the developer advocate types are with a developer-focused company, like one of the CSPs, for example it's a lot of the DAs I know or with, like you know, like HashiCorp, or just one of those developer focused type of organizations. Okay, so, all right. So let's, how did you get started with the cloud stuff? I mean, obviously you probably didn't, like, like all of us, you didn't start, you didn't start with cloud. So like, where did how did you get started? Um to into the cloud, like from where you were?

Erika Dietrick: 5:50

Right, right. So, uh, and this is. This is one of the things that I thought could be insightful or interesting or maybe it's just going to validate what you guys already know about how developers approach the cloud, but um, the cloud, but um.

Erika Dietrick: 6:06

So I was working a lot of different gigs after my undergraduate degree, right, um, I was most recently, before being in tech, working at starbucks and, uh, managed to get back into a master's program of software engineering. Uh. So, granted, I was looking to have a challenging and rewarding career and my dad was a software engineer and for some reason, there was some sort of disconnect where I never learned what he did or why. I just knew he liked his job and I'm like what the hell? You know, I'm smart enough, probably.

Erika Dietrick: 6:31

And so I went into this software engineering master's degree at East Carolina and I would say that, even though I had a lot of catching up to do, my experience when it comes to the cloud was probably pretty typical with every developer's learning experience, especially if they're going the academic route, and that is that you know development. We're very much focused in the IDE or in the developer environment, where it's just you learn to master a language and you don't really give a. I don't know, should I be cussing less?

Tim McConnaughy: 6:58

No, that's fine, You're good, you don't?

Erika Dietrick: 7:01

really give a fuck about anything else, right, you know. So I think that it's a lot more naive and siloed than coming from an IT network engineering background, where you kind of have a general, well-rounded sense of how technology works and how things communicate in the real world. You're just sitting there in university learning variables and methods and whatever other programming concepts and being happy that you are printing a little line statement to the console. Eventually you get more advanced, right, depending on your interest mobile app development, game development, whatever. But what's not taught in university is really anything beyond just building the code.

Tim McConnaughy: 7:42

The language itself.

Erika Dietrick: 7:43

yeah, so, in terms of how are real-world apps deployed? Where are they deployed? What do you have to consider when deploying them? Everything, I mean I talk about this a lot with DevNet too but everything from code security to how you document, how you work with other people and not just on your homework.

Erika Dietrick: 7:59

It's a pretty big problem in my opinion, and it really. I was, I guess, a little bit lucky because in university I ended up taking a Google Cloud Platform course and it was because they had some kind of student program that they had partnered with ECU and they were giving, you know, a certain number of free credits. A professor that I absolutely adored had been, I think he applied for this program and was chosen and they gave him some, you know, PowerPoints and materials and he did a great job with the course. Um, but so I'm I'm lucky in the sense that I was at least exposed to it before, you know, the real world hit me in the face. But, um, you know this, this program? It essentially just kind of throws you into a series of labs, and the labs are hands-on, they're well done, they're meant to get you familiar with different GCP services and using the CLI and all that. But again, as a developer, you just have no idea like why am I learning?

Erika Dietrick: 8:55

this. Why am I? There's a huge disconnect, right. You don't have any understanding of networking or how applications run. So I took that course and it it was exposure, but nothing really stuck. Um, what's interesting is that? Um, my experience and stop me whenever you want my experience, both as a student and later on in startup world, was all with Google cloud platform, because they really push heavy on those empowering you to use the platform free credits, all that but afterwards I've never touched GCP. It seems to be they're really trying to claim the market there on the little guys and girls.

Chris Miles: 9:36

Well, we've been talking about it on this pod for a while. It seems like GCP is, or, as we should say, google.

Tim McConnaughy: 9:43

Cloud. It's not GCP anymore, but Google Cloud.

Chris Miles: 9:47

It feels like they win the developer battle almost every time. They are very attractive to developers day in, day out. I don't know. Do you have a take on why that is? Is there something in that realm that was more friendly to you, that was inviting? I mean, obviously there's credits and there's incentives to use the platform so that it's, you know, cost effective. But, like the platform itself, what's, what's? What sets it apart in your mind?

Erika Dietrick: 10:10

It's honestly, it's interesting to hear you say that, because I okay.

Chris Miles: 10:14

So I think, it's easier to use. I think it's easier to use an AWS.

Erika Dietrick: 10:17

I don't think there's anything particularly special about how Google cloud is set up. I just think there's less services to choose from and it's not as confusing as AWS Interesting okay. And, you know, in the developer world too. I don't know, maybe this is the same for network engineering, but there's basically Microsoft shops and non-Microsoft shops.

Tim McConnaughy: 10:36

Oh yeah, right sure.

Erika Dietrick: 10:38

So you know, if you're a Microsoft shop, you're using Azure, no matter what Right. And if you're not, you know, and again, and you've never been exposed to a cloud platform, you're probably like oh, AWS is complicated, you know, jump over to Google.

Tim McConnaughy: 10:51

Yeah, what's interesting is something we observed and I still think it's true is that I feel like Google Cloud's networking was built with developers in mind, like the way they do their networking was built like you don't have to care about it, we'll just kind of do it all for you. Like built towards developers that won't know or care how the network works, we'll just kind of figure it out for you, which confuses a lot of us network people because it doesn't work like you would expect networking to work.

Erika Dietrick: 11:21

Well, and I think it's part of that disconnect to the farther, we abstract what's happening in our cloud services versus what's actually happening in the data center.

Chris Miles: 11:30

You know what?

Erika Dietrick: 11:30

I mean as a developer. Okay, that's great that you're catering to us and, like I work with them, enabling them on the code side, and you know they want to take shortcuts or just use low code, no code or whatever it's like. I know this was built for people who don't want to learn and it's easier, but it's not really great.

Chris Miles: 11:55

Yeah, I totally get that I'm assuming this has to relate to the fact that there's just been like a boom in the industry and there's more people gravitating towards this career field, right, like I think, like you mentioned before, that early on you know that you'd like you didn't have to learn some of these things.

Chris Miles: 12:13

Like you know, you just like focus on the code, but then maybe you start peeling back the onion and learning how networking works.

Chris Miles: 12:18

I feel like that comes with the genuine curiosity that was kind of unique about either working in infrastructure or working in software development. You probably had that genuine curiosity that was kind of unique about it, either working in infrastructure or working in software development. You probably had that genuine curiosity regardless and it kind of led you down those other avenues to explore because you just like couldn't fathom not understanding how the entire system works, right. But I feel like now that the bar of entry for this stuff is much lower and it's becoming a much more standard career field, like I think people just lack that curiosity and like I've been a big proponent about this for a long time is like people need jobs and you have to let people be mediocre at their job sometimes, because to some people this is just a fucking job, right? This is just how you put in your 40 hours and you go home and, like you, take care of your family, and that's that's what's important to you, right?

Chris Miles: 13:04

You don't give a shit about what you're doing for work really. So, like I don't know, do you think there's a correlation there? It's like just coming from the other side of the stack.

Erika Dietrick: 13:11

A correlation between sorry, can you summarize the?

Chris Miles: 13:15

question. Yeah, sorry, I said a lot there. Just kind of the boost in the career field, right, and there's probably more people just looking at it from the lens of like, hey, this is a job more than this is like something I'm truly deeply interested in and want to find out more.

Erika Dietrick: 13:29

I definitely think there's two camps of I'll just generalize as tech folks. But you know, there's people who just have a love of learning and you know, maybe they start out in one discipline but they're at least willing to explore in other areas or where it makes sense and they want to understand how things work. And then I feel like the other is just looking for that high salary tech career, right.

Erika Dietrick: 13:50

They gravitate towards the title and I'm going to get the credential for that title, I'm going to build for that title and then I don't care about anything else. So I definitely think cloud engineering is one of those. I'm not really sure why, but it's one of those titles people have been really gravitating towards lately. I mean, maybe it feels a little more accessible than things like cybersecurity. You know, you feel like you need I don't know more background to get into stuff like that.

Tim McConnaughy: 14:13

I think if you're starting from nothing, like, say, you're coming through college right now, for example, the CSPs have laid a large advertising campaign around the idea that like, hey, we make everything extremely easy for you. You know we have a high we can give you. You know we're involved in high. You know everybody's moving to the cloud, so you're going to find a job as soon as you get these skills. But, more importantly, you don't have to know all that on-prem stuff. You don't have to know all that other garbage. We're serverless.

Erika Dietrick: 15:00

Like we. You know we're serverless. You don't have to care about 90% of this, we'll take care of all of're. Just ticking boxes, you know, but really I can't think of any engineering discipline where you really shouldn't know anything at all about the other disciplines.

Chris Miles: 15:14

And you know I'm a little bit.

Erika Dietrick: 15:15

I will say I am a anomaly, I think, on the software engineering side, because while I was getting my master's I did a internship at Cisco TAC and you know, I actually learned network engineering I mean at least at a CCNA level at the same time as software engineering. So I had more of an appreciation for oh, this is how it all comes together. But most software engineers, I would say probably zero exposure to network engineering and then just cloud as needed, or you know, if you're wearing a lot of hats at a startup or whatever, yeah, I definitely don't want to come across like I'm poo-pooing and, you know, like the old man shaking his fist.

Chris Miles: 15:51

Like back in my days you had to learn every bit of the stack or anything like that. I think it's just more now. There's also like a wealth of things that you need to learn. Right. If you tell someone to learn everything, then they're never going to start right. Like AI, like I'm sure AI is like the like learning for that right now is probably so oversaturated and like people don't know what to do.

Tim McConnaughy: 16:13

I don't know what you're saying. Yeah, definitely yeah, but like yeah.

Chris Miles: 16:20

So that one yeah, definitely like yeah.

Tim McConnaughy: 16:21

So it's kind of like um, freedom of choice is kind of the natural enemy, I think, in the in this in this situation, I think, yeah, well, and also, uh, one thing that the cloud has done, that is, that development that makes developers probably need to learn more about the whole stack is this concept of loose coupling, where we're pulling apart applications into other pieces, right? So now it's not just front end and back end. You've got like databases, you've got web tier, you've got app tier and like all these different tiers and all, and they're all in other places. Uh, so what's? What's latency?

Chris Miles: 16:49

dude, who cares?

Erika Dietrick: 16:51

yeah, I mean it's. It's so difficult too because, um, again, I don't know if this translates to network engineering as well, but as a developer I mean even within development you can have such vastly different experience and knowledge. And even what you're talking about with, with the decoupling, I mean, I know people who spend their entire careers building, you know, three-tier applications that they're deploying all in the same place and you know they do that same thing over and over and over. You know they have a hammer and they see everything as a nail. And obviously it varies, right, and other people are working with microservices and stuff.

Erika Dietrick: 17:28

But, like with my cloud experience, my first time actually actually having to use it was when I was hired for my first software engineering job at a startup and to be honest, it was well, I'm thankful for this job. In case this person hears I am very thankful I had this job, but you know it was a little bit traumatic to have to learn. You know cloud engineering while really practicing software engineering professionally for the first time. And then also there's that you know, creating a CID, cicd, pipeline. You know who does that fall on? Well, when there's four people in the startup, somebody's got to volunteer, right and that I think that very much. Even in that scenario, right, you'll find a lot of times.

Erika Dietrick: 18:13

So there was one other engineer, at least initially, in this startup. It was just me doing the backend, which is just things you can't see, and then the front end guy who's doing, you know, the website, and you know it's not a matter of, oh, you know well, we're going to have a, you know, sql server database and so we should really deploy that in Azure because it's more cost effective, or this, this or that. You know, it's just a matter of well, I like this one, you know well, I knew this one. This one seemed nice, you know, and just arguing, you know, back and forth. That that's how most developer conversations go that I've had, and cloud was no different. It did not feel like we chose anything based off of any real um, expertise or reason besides, eh, I feel like doing this, um, so anyway, that's how I ended up. Getting into AWS was, uh, you know I was. I was doing a, a Microsoft shop back end, but I was told no, this needs to be an AWS.

Tim McConnaughy: 19:11

Was. Was it told to be AWS because the front end was being developed on AWS or because the business had decided like AWS, is we're going to keep it all together, or so it was a React native front end.

Erika Dietrick: 19:25

But again I really think it just comes down to that Microsoft anti Microsoft sentiment. I will say I'm pretty opinionated on how much, how many problems this causes, that this is like our only decision-making process and so many technical conversations, but I think it was literally just Just anti-Microsoft. Most people seem to use AWS. Let's use AWS and screw.

Tim McConnaughy: 19:47

Microsoft. No, that's interesting for a you know to make such a big commitment Because, if you think about it, the business is making a huge bet. When you're doing back-end development, front-end development, you're doing the whole thing. You're developing the revenue generating app on this cloud and it sounds like just because you know, didn't want to do Microsoft. Sometimes there's a lot of times, of course we have those discussions and it comes down to hey, what do you know? What have you used before? What's your preference? But to think of an entire business betting, of course it was a startup, so everything's already on fire and it's the Wild West anyway. But to bet the whole farm on AWS just because anti-Microsoft, that's interesting.

Erika Dietrick: 20:28

Well, and you know, when nobody has any true understanding of these cloud platforms too, I mean it makes it almost impossible to make any logical decisions. It's a lot of waste of time. I mean it makes it almost impossible to make any logical decisions. It's a lot of waste of time, I mean. The easiest simple example I can think of is you know, we had a database deployed in AWS RDS I don't even remember what that stands for anymore and then we had an EC2 instance for basically just another portion of the app. It's not that important.

Erika Dietrick: 20:55

Yeah not that important, and so, anyway, whenever we were working with and testing this app, right, we had to have the instances on right.

Erika Dietrick: 21:05

It takes time for you to turn the instances on and then for them to tear back down, and so you know that costs money. And you know people ask, you know leaders were asking well, why? You know, why are they taking so long? Blah, blah, blah, why are we being charged this? And I'm like look, whenever I test it, I have to turn it on. It takes time to turn on, it takes time to turn off. And they're like well, we only want it to turn on the instant an API call is being made, and then it should turn off after that.

Tim McConnaughy: 21:30

That's not a thing.

Erika Dietrick: 21:39

We wasted an entire at least an entire sprint or so you know like a amount of time in developer land Right, trying to implement middleware that would, on a timer or trigger, turn on and off these instances and it didn't work. Okay, and again, I was like this is a really bad idea and this is not how they're designed. I mean, this is how they're designed, this is just how it works.

Tim McConnaughy: 21:58

Did they not understand what serverless was at that point? Like serverless, you know, like Lambda or API Gateway or any of those services that are completely elastic?

Chris Miles: 22:06

I'm thinking you frontend with API Gateway just to do a Lambda function to start the instances, and then you basically say like the response to the API call is like try again in 15 minutes. So I will say you know as a semi early in career person.

Erika Dietrick: 22:23

I don't get a lot of influence, or anything that's done, but, um, you know, again, I think it goes back to with developers. At least it's either hey, uh, this is what I know and we're gonna do this period make it work, or I don't know. They've learned some cool new technology, or like they've got into Lambda or whatever and they're like everything's you know going to be Lambda Hammer and nail.

Tim McConnaughy: 22:45

Yeah, the parallels are uncanny, because it's like that with I mean, you know, it's like that with network engineering too, like nobody ever got fired for buying Cisco. I know the Cisco CLI, I'm CCNA certified. We're buying Cisco, right? Or Juniper, or whatever that is right. Or you know, or hey, you know, I know EIGRP, so that's the routing protocol we're going to use. You know whether or not it makes any sense to do so.

Erika Dietrick: 23:12

It's infuriating to me. Maybe that's just me, Maybe I just like making my life hard and having to learn new things all the time, but I got to try. I feel like you know.

Tim McConnaughy: 23:21

So I mean, tell us, tell us a little bit more about the startup gig, cause that sounds pretty interesting. Specifically like a little bit. I mean you kind of you kind of went into the well, what the business was looking for, which, of course, was completely untenable, uh, what they were trying to get you to build, but, like, what did you end up doing? I'm curious, like from a development perspective, like how I'm interested in the in the architecture piece that developers are I have to come up with here.

Erika Dietrick: 23:42

So I was hired in. I feel like I gotta be careful, being too honest, but I was hired in basically because, um, they had initially outsourced the work, um to an agency in India, and so they had one on-staff engineer who was doing the front end, which was the website and the mobile app portions that you could see, and then this Indian agency was doing the back end. So they were doing a C-sharp REST server, which just means that's where the API calls were being created, and then the SQL server database, which is where all the data was stored. So the story I was told was that the communication didn't go well, they didn't get exactly what they were promised and you know, for different reasons, you hear that story fairly frequently.

Erika Dietrick: 24:31

But as a startup, it's pretty hard to pay market rate to developers in the US, and so you know I was cheap and bright eyed and looking for that first opportunity, and so I was hired and I was supposed to just be, and I have a background right In C sharp and SQL server, at least from university and so I had come in and I was supposed to basically fix a bunch of bugs, is all it was told was. Fix a bunch of bugs is all it was told it was fix a bunch of bugs, implement a few new features Again, the architecture of this originally was that it was a React Native front end C Sharp REST server, SQL server database and we're making API calls between each of those three tiers.

Erika Dietrick: 25:17

That's how we communicate between the tiers. So, anywho, we get started and this is very typical of all startups. Every startup I've ever worked at or interacted with. I get started and it's a completely different situation when I start. We're going to start from scratch, we're going to do this way better. You know it's going to be highly performant, all this stuff. So I'm like okay, that's cool. So we call that greenfield application, doing a greenfield application when you're doing it from scratch. So I got to actually help, you know, give a voice on architectural decisions, which I think is kind of unique for a junior software engineer. And you know that basically started with the database design, because you know, with a relational database it's a lot less forgiving than.

Tim McConnaughy: 26:04

MongoDB or other types of databases Like NoSQL or something.

Erika Dietrick: 26:08

Exactly so. You really want to think of it from a database perspective and then kind of build the API calls out from there and then connect the front end via those API calls. So we started with database design. I don't know how much you want to go into that, but it's literally sitting at a table with a piece of paper and we're going back and forth and scratching stuff out, and it makes more sense to couple it this way.

Tim McConnaughy: 26:33

I can actually commiserate with you on this, because when I did my WGU cloud computing degree, one of the courses one of the not just a theory course but an actual like do something course where you have to create a project was database design and I actually had to build a database schema. Oh my God, it was like I still have nightmares. I hated it.

Erika Dietrick: 26:55

Well, again, what's funny is that, you know, in university I love SQL Server. Something about relational databases just made my day, and then I realized it was because in school, you know, I was doing stupid little.

Erika Dietrick: 27:09

you know, oh, user ID application with three tables you know and you know two foreign keys, you know. But yeah, so an enterprise, or well, this was an enterprise, I don't know, using mixing up my terminology, a real world production database. It was much, much more complicated and in a startup you don't really have anyone to ask questions to right.

Tim McConnaughy: 27:29

So it's very true here You're the, like it or not, you're the, the person.

Erika Dietrick: 27:34

Exactly yes, so did the database design. As the only backend engineer and the only person who understood C Sharp, I was I would say over 50% trusted to just build it how I thought it needed to be built, so I used what's called a model view controller architecture. It's just a way to separate, yeah.

Erika Dietrick: 27:55

Yeah, I'm familiar yeah, yeah, I'm familiar, uh, and you know, beyond that again, and startups, it's usually kind of a cluster. So you know it was a matter of do however you want and then I'd do it. No, not like that or no, it needs to have this too, you know I wouldn't know anything about that, I just I just like to. I like to be funny and talk crap, but I honestly learned a lot of this experience.

Chris Miles: 28:16

So just you have to laugh about it, or else I mean well, I'm just keeping my bridge unbridged.

Tim McConnaughy: 28:21

Well, honestly, where else could you have gone and get this kind of?

Erika Dietrick: 28:25

Yes.

Tim McConnaughy: 28:26

Experience, even if it is stressful at the time, Like there's very few places that you could you know, most places would crib you to the point where you barely learn anything for a year.

Erika Dietrick: 28:35

You know, I will say that too. You know it was a cluster. But you know, had I been at a big I don't know, a fortune 100, you know I would have been. You know I do, you know, work this one little gear in this gear only. So I did get to touch a lot.

Tim McConnaughy: 28:47

It's good after the fact. It's good for building the portfolio. It's good for building the portfolio.

Chris Miles: 28:52

Glad you did it, but you wouldn't sign up for it again.

Erika Dietrick: 28:54

Well, you know, and things happen too right. I mean in startup world, like you have venture capital, you know, like at Cisco. I mean obviously it matters what we do, deadlines matter, but at the end of the day, you know, in startup world you really can't afford to do that. That's the death of your company and so on top of that, you're usually riding on venture capital. You usually aren't actually profitable for I don't know years. You know many startups out there are not actually profitable.

Tim McConnaughy: 29:32

No, that's well. Well, yeah, agreed.

Erika Dietrick: 29:35

So you know you've got this one little eager you Agreed. So you know you've got this one little eager. You know junior engineer who you know. The entire architecture, the CICD pipeline, the way it's deployed, is riding on this.

Tim McConnaughy: 29:46

Millions of dollars.

Erika Dietrick: 29:46

Six-month-old runway. And then you know, oh, why is the service down? You know emergency. You know, hello, I don't know. I'm not going to pretend I can figure it out.

Tim McConnaughy: 29:56

Yeah, no, that lesson's learned Everybody. Honestly, the best lessons are learned in the fire, but as long as it doesn't actually like make you want to leave tech forever, you usually come out the other side with the kind of experience that would take you years otherwise to get. So there's good and bad to it. It is a very high-stress environment. Somebody was asking in Discord yesterday you know, hey, I want to get into tech, but what's the work-life balance and the stress level like? And I'm like, do you want to know the answer? Do you want to get into tech? Because I'll tell you Like, so anyway, but that's.

Erika Dietrick: 30:30

You know, but it does get better though, because it does. So I'm I have, I will be starting year six in tech this year. I mean, you don't feel like you get any wins Like you feel like you know nothing.

Erika Dietrick: 30:45

It's not just oh, you know, I'm good at some things and I get that self-esteem boost and I'm also learning and getting knocked back down again. It's just getting hit in the face over and over and not knowing. So I mean, I feel like that part does change and I think your attitude also changes about it. Right? Because again, university, you know, as a developer we're not even I mean, at least I wasn't in many developers I know you're not even taught how to debug your code, which is highly unrealistic, right.

Tim McConnaughy: 31:13

Oh really, no unit testing or anything. That's not part of the curriculum.

Erika Dietrick: 31:17

So I learned how to do unit tests and how to use certain mocking frameworks. But I mean, I think that some professors, you know, they kind of gloss over the debugger. It's complicated, I won't get.

Tim McConnaughy: 31:30

Like the step debugger where you have to go like Right.

Erika Dietrick: 31:33

So there's this joke in programming land about how we debug using print statements. I don't know if you guys are familiar, okay.

Chris Miles: 31:40

Yep, I write Python, so yes, that's the only way I've ever debugged. So yeah, so yes, that's the only way I've ever debugged.

Erika Dietrick: 31:53

So you know it's fine in a pinch or sometimes, but it's really not that helpful and inefficient for real world development. But shockingly, it's used constantly. People just do not use the debugger and that's the real world. The real world is that your code just doesn't work. It doesn't magically work. You mess up all the time. That's changing a little bit with AI coding assistants. Some of the really irritating things that you troubleshoot for hours you know don't really happen anymore, but that's good news, yeah, yeah, so should we?

Chris Miles: 32:16

should we open that up a little bit? I know, obviously, the the kind of AI coding assistants or co-pilots, as we put them um, not to use the specific branded item, but it's one of the most popular ones, so it's not like we can avoid it. But I mean, how do you feel that is changing the kind of development lifecycle? For better or worse yeah.

Erika Dietrick: 32:37

I mean, there's a lot of AI copilots out there. Typically, you know, the one people are most familiar with are code generators like GitHub Copilot. There's a lot of others out there and they range from. You know, I only generate code and have chat functionality to. I'm a full on developer environment, you know, meant to, you know, save workflows or suggest things to you in that way. So I will say, at least from a GitHub Copilot perspective, which is so I will say at least from a GitHub co-pilot perspective, which is, you know, or at least was, the most widely adopted AI coding assistant code generator at the time.

Erika Dietrick: 33:12

It's what I've done, a bunch of presentations on. It's absolutely revolutionized development life cycles in both good and bad ways, and I do think that, even though bread and butter developers were probably the first to flock to these tools, that really we're talking about something that's going to change things for anyone who codes, and so I know we've got some network and cloud people. So I'll speak more to that At Cisco Lives and when I give talks, the main thing I'm asked again is you know, do I actually have to learn how to code now? Is it just a matter of prompt engineering? Um, and then I, and then there's people on the other side of the fence right, who you know you're like. You shouldn't be able to touch an AI coding assistant until I don't know you're a senior developer or whatever.

Tim McConnaughy: 33:59

Oh yeah, the gatekeeping.

Erika Dietrick: 34:21

And what's interesting at least what I found through my own research and opinions is, you know, I think that it's really going to be not the code generation per se, especially for network engineers, but it's going to be are taught and hired. And coincidentally, this bleeds a little bit into teaching network engineers how to code, and assessing their skill is essentially, you know, we give you some assignment, we see how you execute said assignment or how you code it, and then are you able to explain it right, and then we do some form of that in the hiring process when we're evaluating people too, right, it might be on a whiteboard, it might be solving some stupid riddle, but essentially we just give an assignment and ask to code and then whatever.

Erika Dietrick: 34:56

So you know that is completely blown on its head now that there are AI coding assistants right, because you have an assignment and you can generate the answer to that assignment, and you can hit slash explain. Literally, it's that easy slash explain, explain to me what was just written, explain it to me line by line, and you know that's your student assignment, you know that's your take home for your, for your developer interview.

Erika Dietrick: 35:18

Um, so it's really not an effective way to oh, to gauge ability anyway, right and because it's not an effective way to gauge ability, it poses a lot of challenges for teaching. You know, how do you know when somebody actually knows how to code, and how reliant should we be on these tools? So I feel like I'm rambling a little bit, I'm sorry.

Tim McConnaughy: 35:37

No no, no this is good.

Erika Dietrick: 35:38

This is actually really good. I think this is important.

Chris Miles: 35:42

But it's funny because, like I've read on social media, I've never had to go through one myself, but I've read a lot about, you know, these software engineering interviews where people feel like the process and the interviewing criteria is so strict and so over the top that they hate the interview process Because it's all like, oh, do this live in front of all of us, you know, write this code, do this thing on a whiteboard, blah, blah, blah. And they think that it should be simplified and they should like, almost almost like the, the, the hiring manager should be more trustworthy about things in a sense. But now it almost sounds like from what you're telling me, like it's kind of spinning back in the other direction. Like, how do you validate people? Know what the fuck they're talking about and they haven't just done this on, you know, through a chat bot, um, other than doing that. Like, where do you think it fits into that?

Erika Dietrick: 36:28

So I won't spill all the tea, but I'm going to be presenting on this in February oh, all right, yeah a roadmap how I think that we should now be evaluating and teaching and all that. But yeah, I mean, I think it's an opportunity. You know, people see it as, like you know, ruining engineers.

Erika Dietrick: 36:45

No, they're never, going to learn blah, blah blah. But I think it's a great opportunity to revamp how we teach people to code and how we assess it. I think that the kind of like you mentioned, I think that the model was completely broken, I mean even when I was just learning to code, right, I mean it was I overused the word traumatic, but it was traumatic, you know. There were many tears shed, it wasn't fun. I didn't learn the most efficient or effective way.

Erika Dietrick: 37:06

Yeah okay, and so I think that you know we can focus more on things like people's past experiences and what they learned from it and how they would apply that to new problems, and talking through people's thought processes and the way they think about problems, right, because that's what engineers do. It's not about do you know C sharp or Python. I mean a little bit. It depends on the, on the level of the role, um but it's about can you actually think like, do you know how to solve a problem? Um, have you encountered enough problems that you can deduce how to solve a similar problem at our company? So you know, that is generally the way, the direction that I hope, interview assessments are taken.

Erika Dietrick: 37:47

And again, I think that from a chat perspective, you know, really it's just Google on steroids. So developers learn through Google, right, we do a lot of teaching ourselves, but Copilot chat has been absolutely revolutionary. I taught myself TypeScript in a couple of weeks using Copilot chat Absolutely phenomenal, in my opinion, at least, based on my work speed. So yeah, a very long story short. I could talk about that forever is that it's really making us rethink how we teach people to code and how we assess it for network engineers as well.

Tim McConnaughy: 38:23

What do you think about not just AI as a code assistant, which is kind of what we're really talking about? You know, hey, generate this code for me you mentioned. Like you know, it changes the way we teach people, do you think? Or what do you think AI has a? Does AI have a place in the teaching process as well, or is it really better kept to the assistant level? And if it does have a place, like where do you see that fitting in?

Erika Dietrick: 38:51

Well, I can answer yes to both your questions, because I it should always be kept at the assistant level. In my opinion, it is not the brain, and that is where most people's disappointment comes from. Again, especially if you don't know how to code is just like do this for me you know, so it is most effective as an assistant, and that makes sense, right?

Erika Dietrick: 39:07

Because if it's the brain, then why are we even here? And then, yeah, 100%. I think that you know it's essentially it's going to be akin to using a calculator for math right.

Erika Dietrick: 39:18

So you know whether, again, it doesn't matter what your background is you're going to want to learn certain foundations. You're going to want to learn how to think programmatically because that is a skill right Thinking from like a discrete, mathematic, logical perspective. And then again, I won't spill all the tea, but there's certain concepts. I think you should learn some building blocks and then I think from there. I think you use your calculator to continue learning, and to I mean not generate all your code, but at least to continue learning.

Chris Miles: 39:46

Yeah, no, I think that's valuable. I mean, I think it's um, I hope.

Tim McConnaughy: 39:53

I hope you call your talk software engineering re-imagined or something like that or something. But just kidding, it's already submitted.

Chris Miles: 39:56

I should have talked to you, no, but I think it's. I think that is a great approach because I feel like that kind of takes a page out of the network engineering interviews that I've done over the past, Like whether or not I'm, you know, the interviewee or the interviewer. You know, I interview a lot of people and a lot of times when I'm asking questions, I'm not asking the question to know whether or not you know the answer. I don't care if you know the answer. I want to know how you react when you don't know it. Like how you react when you don't know it.

Chris Miles: 40:26

like how like how you explain, how like and what you said. You want to know if people have seen enough problems to learn like theory around yeah, what their thought process is, how they troubleshoot you know, if they can draw correlations. I want to see how they build that mind map like live, right, and then it depends on what questions they ask me in response.

Tim McConnaughy: 40:44

Right, that's yeah, that's how you really tell what that's like. What questions do they ask me in response? Right, yeah, that's how you really tell. What questions do they ask you back to try to get more information? Because you can teach anybody network engineering. You can teach anybody TypeScript or code or you know whatever. I can teach structured data, json to somebody, like all that stuff. It's just stuff in a book that you can teach someone. You can't teach someone how to think. You can't teach someone how to how to solve problems. Like you know not, not really. I mean you can, but like the actual thought process of solving problems is something that people have to kind of come up with, figure out how it works for them, and they have to do it themselves.

Erika Dietrick: 41:16

Yep, 100%. And I mean these co-pilots, right, I mean we can try to slow them down and say, rah, no, no, keep them out of coding, but I mean really they're going to infiltrate every area of life like we've. I went to um my first black hat um this year, which is a cyber security conference, and they were talking about how um microsoft has a co-pilot studio now where anybody of any non-technical background can create their own ai co-pilot and connect it to, like, for instance, their hr database and have it assist them with things or whatever it is. Their profession is right.

Tim McConnaughy: 41:47

That's a great idea.

Erika Dietrick: 41:50

So there's the self-serve no code, low code options, but there's also just all these products coming out right. I mean, we've co -pilot, for Azure was recently announced, so there's no aspect of tech that is not going to be touched by some form of AI assistant that can't just parrot out facts to you, right or lines of code. So, again, I think we can see it as a bad thing, but at the end of the day, you know companies want productivity, so it's in your best interest to learn it, and it's an opportunity to hire people who can solve problems.

Tim McConnaughy: 42:26

Yeah, I mean, and it can keep people from having to know everything. Like you know, for example, I'm working on a project with Andrew Brown for his Gen AI bootcamp, and you know we were working on something yesterday where I needed to get PyDict data out, which I didn't even know. Pydict was a thing Like it's, you know, python, interpretation of structured data. So I went and I like explained my problem I think I was using Claude I explained my problem and like what I was looking to get back from structured data and and it it did it. Now I can't say it's a hundred percent correct because I don't know it well enough, but I will say that it's got me a lot further along than I would have been had I had tried to go read documentation and tried to learn it all myself, like so, yeah, I mean, it's like the personal assistant thing is definitely keeping you from having to learn everything.

Erika Dietrick: 43:17

Well, even just navigating bad documentation. So I kind of I'll just talk about it because I kind of axed the project. But I was interested in doing a VS code extension at one point, um this year and, uh, you know I was not familiar with that development.

Erika Dietrick: 43:32

Right, they have their own API that you have to learn. Uh, so I'm going through the API documentation and I'm reading through it and at first it doesn't make sense because I'm brand new to me. I have zero clue what they're talking about and I was like you know what I'm just going to ask my GitHub co-pilot. And GitHub co-pilot just broke it down Boom, Simple, Summarized how the API is structured, what API call I need to make to do certain actions. It was that easy. So I didn't even need to really learn the API. I didn't need to struggle over the documentation or guess or make the API call and realize it's actually needs this additional field that's required or whatever.

Tim McConnaughy: 44:12

Yeah, I think people are afraid, though, that people, people are leaping straight to oh well, then you know I don't need then then if I know that, then you're going to replace me with a robot type of thing, and I think that's a big. I think the more I, the more I learn about what they are and are not capable of. It's a very large leap. You know, if the only value you bring your organization is knowing how a certain API call works, then you're probably not going to be around very long anyway.

Erika Dietrick: 44:36

Well, you know, I think I lost my train of thought. Let me see if I get it back. I think that it's the same conversation with automation, right? I mean everybody, you know. They set their sight on some point in time and technology and they're like I'm going to get good at this, and as soon as they get good at that, the point has moved somewhere else and they have to know something else, right? And so they think that knowledge is useless. But I mean, it's really not right. I mean even just from the perspective of problem solving and learning or how the brain works, right? I don't remember all the terminology, but you know, when you learn something, you know the brain can more easily learn related topics because it has something to connect it to.

Tim McConnaughy: 45:13

So that's exactly right.

Erika Dietrick: 45:15

I mean, there's many reasons. You can go on and on about that, but I think people just get too laser focused on you know, got to know this.

Tim McConnaughy: 45:22

Right, yeah, well, right, yeah well, the moving goalpost thing, the treadmill, the tech treadmill, is well published and well understood, right, we're always on a treadmill in tech and it's it's like the uh, you know the old cartoons with the, the fishing pole, and it's got the, the banana or a piece of cake or whatever it is, the tank, we're all, we're all just like running towards it forever. Um, but that's, that's a whole other episode. Um, okay, so no, this has been great. We need to go ahead and wrap up, but it's been really great having you on talking to you about this stuff. Yeah, I think we covered a lot of good stuff tonight.

Erika Dietrick: 45:55

Yeah, no. Thanks so much for having me on and for dealing with my Casper lighting and a great conversation you guys are doing a great job on the podcast. Oh, thank you.

Chris Miles: 46:03

I'll do what I can in post, but I promise all the listeners or the watchers, I should say that Erica does not look as pale-faced as her camera is made.

Tim McConnaughy: 46:10

She's not quite, as I don't look enough though it's fairly close. I mean, we live in North Carolina. There's no way she's walking around with skin that pale and still being alive.

Erika Dietrick: 46:19

I've got a lot of Irish descent, so oh, me too.

Tim McConnaughy: 46:21

Yes, yes, yeah. So how do people, how do people find you on socials? How do people connect with you?

Erika Dietrick: 46:36

Yes, yes, so I'm on LinkedIn as my name Erica Dietrich and I'm on X, Instagram and. Tiktoks for as long as that lives, Erica underscore the dev More platforms to come out, but that's where you can find me for now.

Tim McConnaughy: 46:44

Yeah, we might lose two of those things before too long. We'll see.

Erika Dietrick: 46:46

Oh man Okay.

Tim McConnaughy: 46:49

It's crashing and burning with the tech community right now, but anyway, okay, great, so everybody go.

Chris Miles: 46:55

Do you want to plug the talk you have coming up?

Tim McConnaughy: 46:58

What was that? Anything, anything else you want to plug?

Erika Dietrick: 47:00

Sure. So I have four talks coming up at Cisco Live in February, but the one most relevant to our discussion is called Teaching Coding Skills in the Age of AI, and I'm actually co-presenting. It's my first co-presentation and I'm doing it with my dad he's a university professor he's been a software engineer for 25 years, so I thought it'd be a nice blend of perspectives the somewhat newer developer and seasoned I love it Cool.

Erika Dietrick: 47:28

Yeah, we're going to take you through, you know, the traditional, where we were before and where we're headed now, provide you with a roadmap. And again, at the last Cisco Lives I've went to. Every single time I'm approached by you know, managers of network engineers saying you know, I need a blueprint for teaching my engineers how to code and we're going to provide that.

Tim McConnaughy: 47:48

Oh, that's awesome. I can't wait to see it. This is an Amsterdam, still right it's?

Erika Dietrick: 47:52

an Amsterdam. Hopefully it'll rotate. If it's popular, it will.

Tim McConnaughy: 47:56

Oh, I love it. That's a great idea. I can't wait to catch it on the replay. All right, everybody. Well, this has been the Cables to Clouds podcast. Make sure you follow us on all of the social medias that we still are on, and we'll see you next week. Bye, hi everyone, it's Tim and this has been the Cables to Clouds podcast. Thanks for tuning in today. If you enjoyed our show, please subscribe to us in your favorite podcast catcher, as well as subscribe and turn on notifications for our YouTube channel to be notified of all our new episodes. Follow us on socials at Cables2Clouds. You can also visit our website for all the show notes at Cables2Cloudscom. Thanks again for listening and see you next time.