Techstrong Gang – March 26, 2024

Everybody and to we're be all kind. So we're take back in to the movies and start talking about communicate, and finally we're gonna end. That's figure, we'll, in a Folks, we're structured outta ai and we have seen proof of concepts from an called Cognition Labs, and I guess all anybody's seen is the video.

Some folks have been able to into private data. So it's hard to say exactly how this thing works, but the company is that reason a lot. And I'm assuming that means it's making useful large language models and uh, much higher end practicing capabilities.

And what makes it different is instead of just writing code for you or testing what code you need next, you can actually tell it to be tasks and you can type in you this. That's kind of a cool idea. I dunno how real it's, but let, let's get started with you.

I know you kind of looked at this a little bit. What's your impression? Well, they're, they're positioning this as, uh, Devin as a software engineer, right?

And, and a full one, not a, not a, uh, assistant or a copilot or, you know, whatever the popular name dejure is. And part of their inter, part of their idea is they have a large language model that's been trained around software development. It's not just a generic, you know, industry-wide model.

And it's supposed to be, I kind of think of it as the no-code version of AI development where you just describe what you're looking for and you have to, don't have to give it the specs for the whole app. You can start with, I'm looking for a website, I'm looking for this, it kinda looks like this as a style. Create it this way.

Now, how much design work it actually might do on that site's another question, but at least can build the code for you, put it into production, maybe test it, those kind of things. That, that's, that's the end goal. To actually have a, an AI assistant that can go, or a software developer that can go do this.

Their interface is made to be very interactive. Not, here's my prompt, okay, now that he gave me an answer back, now go do this. It's much more of a kind of build automations into it and interactive for someone who's not a developer.

That's how I describe it. Now, I've not worked with the tool yet. I've, I've looked at some videos and read and, you know, submitted to be in the preview.

Haven't, haven't gotten there yet, but it sure looks interesting. Yeah, I, uh, I I think the key word there is allegedly, right? Because, uh, until we can really get our hands on it and see what it actually does, we're going by the videos and the proof of concept, which to be contrary, of course, they're not gonna come out with the videos that show Devin failing.

So I, I don't know. I'm, I'm very, very skeptical myself. I think we're gonna get to a point, not just in software engineering, but across the board where we're all gonna have some sort of assistance that's capable of performing of some level of expertise.

And I some level, because I think it's gonna be like helping. It might be, or somebody or high school student, I'm gonna do something. Okay, but it's not gonna be perfect.

You're gonna tweaking in a little bit. Maybe the machines will continue to get smarter over time and that would be a good thing. What do you think software engineers be comfortable with this?

Or is it gonna be, uh, is it a little too close to home in terms of what they think is their perceived value? Well, that's why I like the no-code analogy, right? It's, you know, most softwares don't do no-code.

They may do low code kind of things, but it's become part of the tool set of it. And developers, we, we'll see how, what the adoption looks like. It seems the intended is an end user who doesn't write code.

So it's a different persona of who would use Devon. Um, and what, and so you're, the, the big, um, the big hope, the big gap that it's filling is that Devon knows what to do that a developer would know also, and isn't, you know, isn't acting as the, uh, the receiver of the, the, the, the input or the text or code or whatever it is, and then making sure that all makes sense. And then Jesus is gonna say, okay, it looks good to me.

Go ahead now what, what do I do next? Right? What, oh, can you add this too?

And, um, I don't know, it could be, it could be a real, a real productive productivity gain. It could also be a nightmare of what it might develop, but you just have to kind of see where it goes. Think we've, Yeah, You think we're gonna get to a point where AI is gonna close that gap?

We'll be able to have enough talent between the humans and the machine running around going, we don't enough. Right? I, I think that's always been the hope and folks have been saying that about low code, right?

With citizen developers that, oh, okay, we don't necessarily need to hire more full stack developers. We can train citizen developers to come in and they can create the apps that they need themselves with drag and drop. So I think Mitch has a great point using the low-code analogy that maybe Devon can come in and fill some of those gaps with a little bit more of the software development expertise that was missing from, you know, if you bring in someone from accounting who doesn't know the ins and outs of development, maybe, um, it's, yeah, I, I think it could definitely help in that respect for sure.

It much, So, I mean you all the time, but vulnerability, my question to you is one of the things that is one thing to be wrong, it's another thing to be wrong. So, you know, can we basically, we now have to AI agents, Well, that's the thing is when do you turn it loose to be a be autonomous software engineer, right? So Mike in Mike in, uh, editorial says, this is what I want this app to do, and it goes and does that, and Mitch in it says, oh my God, why did you ask it to do that?

That's not what we wanted to do. You know, you're like, but that's what the business needs know. So if it's just gonna go off, conversation happens.

Oh, well, yeah, that's actually our next meeting that we're having. But anyway, we'll, we'll get to that. Um, it's that, uh, autonomous letting it go off on its own.

So where is that balance of, if a, if an end user's gonna direct Devin, I suspect it's not gonna be end users to beginning, it's gonna be developers and people who are writing code and say, Hey, can, why don't you go write this for me? Go do this. Um, add this thing to it.

I mean, I'd love to have something like an assistant like that to take, rather than me digging back into the code and saying, now how do I go and add that and just go at it for me, figure it out. So it, it, it's, rather than a co-pilot, my IDE, it, it is another development capability tool, right? That I can kind of set off to do certain things.

But I think we're a ways, long ways away from the, uh, takeover of the AI software engineers. So there's an interesting issue here about entry level developers and skills that, that kind of sparked in my mind, Mike, when you, when you brought that up. And one of the things that keeps coming up around skills is there, there's not enough, obviously there's not enough developers.

So how do you teach new developers to then climb up the ladder and assume some of these roles? And the way that it has always been done is the older, more seasoned developers train the younger up and coming developers. If, if AI and Devon or the next generation of Devon comes along to handle all of that lower level stuff, who do the entry level professionals then learn from?

Do we need entry level professionals? How do you then bridge that gap between someone who graduates with a computer science degree and, you know, a SWE level two or three, that's a whole other, you know, existential question that this kind of brings up. I don't know the answer.

I think skills AI is gonna take now the definition entry level is changing, and you're gonna have to up these to a higher level of what we now new entry level a years to get to that. So if you were thinking bunch in time, you're just coming outta school and you're looking at all this stuff, what would you be thinking? I'd be jumping on the AI bandwagon and figuring out how to use it.

I mean, really, I would, why not? And the other side of it is, I wouldn't like at the behest of everything else, because this is the iceberg problem. Writing the code, writing an app is a 10th of the effort, right?

The real cost is maintaining it, fixing it, updating it code in that it uses, needs updated. It's the, it's what it happens after you deploy it in all those series of kind of day two DevOps stuff, plus, you know, to, to, to say, Devin, go figure out what the problem is that we're currently experiencing. It might be able to figure it out.

I've had some AI tools to do that with code, but on a pretty simple basis. But what if that problem is elsewhere in the stack that it isn't running right? Who's gonna look at that?

So there's a whole level of depth and, and I've always believed, at least in my career, the best software developers who kind of knew enough about all levels of the system and the network and a little bit of security, a little bit of, a little bit of a lot of things, but have some depth in, in the stack that you're running on, those folks not only know how to fix it, but how to get the best out of it. So maybe Devin can help you do that, but you're still gonna need some real heavy skills. So I, I would jump on ai, but jump on all of it.

You know, learn the stack, learn all pieces of it, even if you're not gonna be developing in it, knowing how it works is hugely helpful. Here's the point I waste. See, because chaos stuff let's, that I have a, you have a dev and a dev, we are so, and how well we going talk to each other, which is doing what when, and the business and everybody else is gonna have their own digital.

So suddenly all our IT need to talk to other communicate and collaborate with each other and get something that we all agree. I mean, what do you think? I mean, that's obviously a problem, especially if you are training your Devon on your own proprietary LLM that happens to differ from someone else's proprietary LLM.

Um, you know, developers have different, they're, everyone is unique. They have different ways of approaching a software problem and building something to fix it. So how do you figure out which one is right, which one is not, which one is, yeah, that's, that's thorny.

That gets tricky real fast. Also, software development isn't a single person sport, right? And one person doesn't define what the app is.

It's a collaboration and input from several sources. So I think there's a new way of working that we'd have to find to work with all these Devons and all these people who have their own Devons. But one thing I know for sure is since I control the resources of the GPUs that all our Devons use, my Devon will win Department.

We'll, back in a minute on our next, Hey guys, this is JJ man with Mitch Ashley co-host of CISO talk where we have engaging bite-sized conversations for current and NextGen CISOs. You know, we have some of the best conversations on CISO talk with some of the greatest talent in security people like Andy Ellis who talked to us about optimizing security strategies and how to navigate the boardroom. Lisa Bradley came on and talked about vulnerability management bug bounty programs and Y SBOs aren't the solution to all your software security problems.

Steve Reynolds was also another great guest, and he talked to us about what not to do when a security incident happens. The what not to dos are great, but we also had Eve Mailer and Steve bitten on talking about security, uh, and third party software, SaaS applications, and weaponizing ai. So go ahead and join us for the latest episode of CISO Talk.

You can find us by going to tech strong TV slash ciso, talk Hard communicating, know what we have here we to communicate. Describe to me what goes on in DevOps all the time. Um, do, but um, it seems like we're starting to see some tools that will pull, maybe we will make it easier for us to share what's going on and maybe even track some of compliance issues and know what software is worth.

Um, both talked to a couple of companies that are working on it. It just seems to me like one of the antiquated things about DevOps is that we all these tools for working with the code and then we turn around and say, okay, here's my little process is saying, we're here to do something. I mean, we gotta be done.

Well, I think, I think one of the exciting things about DevOps and automation many of us saw early on is like, wow, it's not just the automation, it's all the data that's gonna be created as part of doing these things. And that should help with security, it should help with, should help with, uh, compliance and a lot of other tasks that developers hate doing. None of us really like to accept people that are specialists in that field.

Um, but the challenge is that assumes that there's a pony in there somewhere, right? Here's this huge, massive amount of data. Go find the stuff in all that and make sense of it that we can then go assemble a compliance report or, okay, did we, did we do all the things that we said are in our security policy?

Can we find that everywhere in all the distributed set of tools that we might use? Uh, DevOps, development, testing, security, all of it. I think the, the, the approach that people are now trying to look at is how can we put something in the process of how software gets created so that it knows what artifacts have been created and where those are.

So when it comes time to pulling that together, or maybe it's doing it as it's happening, it isn't an apt after the fact and said, well, we didn't actually find a pony. We just found kind of part of one. Um, but that way it's more intentional of what you get out of it.

And I think that's a, I think that's a smart move and kind of a makes sense from an evolution standpoint. I hate It a spreadsheet. It's a spreadsheet.

If you ever wanna p**s Mike off, just start sending him spreadsheets. Hey Mike, would you look this over for me? Yeah, sure.

I'll be right back to you Then. Well, and I, I think to a point, yes. I mean, how much time do you wanna spend actually developing, moving software through a workflow, deploying it, maintaining it, versus filling out where it is and why it is and what it needs to do next?

Um, I think there's, if, if you're asking if there's room for improvement in these tools, I absolutely think so. Um, but it, it's, there does need to be, I think with so many fingers in the pie of software development, I do think there needs to be some way for everyone to quickly look and go, oh no, Mitch moved that along last Thursday, so it should be here and therefore the next step needs to be whatever the next step is. Uh, yeah, that's my vague non-answer.

Answer. How's that? I, I think that was on, I think people are waiting for somebody to like some sort of alert that the project was now your to do, your bit needs to try because it's work, right?

Um, I think we lot head over and over again eventually sink, but um, I just feel like, you know, if I look around in all these environments, you know, DevOp for example, you world opinion, I know basically, you know, something that looks like a digital clipboard and you're asking people, did you finish this stuff? Well, you know, nobody wants to sit down and send an email specific manager manage. I think we're getting, I'm hoping, but Well, I, my dream if I'm gonna dream about it, you know, I keep getting bombarded by new tools that will help look at your calendar and help schedule when you need to work based on what things are in your task list and what are in your calendar.

Kind of a new thing. It's not, uh, completely new, but trying to apply some AI to it. And as you are talking, you know, we still work on the handoff method notifying Sharon that I've done my part and Sharon notifying you that she's done her next step, right?

And so every one of those in, in the DevOps mantra, every handoff is a delay because it doesn't pick up right away, right? I'm busy doing something when I let Sharon know and Sharon's got a stack of things to get done before she gets to whatever. It's, so all those are delays we add into the process.

I'd much rather have that kind of queue up for me as come up into my, here's my task list, here's the stuff I'm working on, I was planning to do today. Things start appearing that because someone else finished their steps. Then I can look at it and say, you know, that's, that ought to reprioritize what I'm doing today or Good, I'll get to that tomorrow, or whatever it might be.

But if it really worked into our workflow, like to an individual level, I think it would look like that instead of the clipboard, are you done yet? And then let me go tell the next person. Whether that's through a Slack message, email, spreadsheet or person.

That's the thing I think, Mitch, you just hit on that would be most valuable is the reprioritization when you're, you get the notification you're in the middle of something else so that you can quickly look at it and go, do I need to drop everything because this is on fire? Or where does this now go in the endless list of other tasks that I have to complete? Does it jump to the top?

Can I put it off till tomorrow? You know, does somebody else need to take a look at it quickly before I get to it? That's, I that absolutely adds delay time and that cascades into other things.

If you are having to drop something that's arguably just as critical, then that delays that project as well and then it's, that's starts cascading in a bad direction. So, yeah. Yeah.

And what I want, the second question would be, do you wanna do something about that? Or would you like me the AI to do something about that, to buy you some time? Maybe take percent depending on what it's, and I think if we get to that level of ai, people will be a lot more excited about this whole concept.

Just seems like, yeah, you know, we're doing some role level work for you and we're kind of making it faster for you to type. And in some cases it's all very, it's always so probabilistic is the term, I believe you still have to supervise all this stuff, which with, but frankly, I wonder if we're by, I'm amazed by, Well, it, it's, it's, I I think that there's another layer to what you're describing and that is it might show up in, you know, something that I could do or it might show up in sharing in my list of stuff to do and, and she's, she's more productive and gotten a lot more done today. So she's able to pick that one up before iava could even get to it.

So, you know, that's sort of the agile, right? Pick the, pick the work item off the Kanban board sort of idea. But think about doing that in a, in a automated workflow with some AI to help prioritize here this is a more important, here's why.

Maybe, maybe air Sharon's available to do it, where Mitch would take longer 'cause he takes longer to do those tasks or whatever it might be. But there's a lot, there's, there's the multiple people working together versus my to-do list view of everyone's individual to-do list of the world. I think that's where the real productivity could be helped greatly Come back, take Well let's pick on him.

Yeah, We were talking about remote workers and how hard it's work remotely and we, everybody coming in the office, but I would argue that if we could solve some of these communications issues using, it'll get a lot easier to distribute. Maybe we won't need to be tightly linked in the office, so always be better, but it's just not feasible. What's thought can we get, you and I were working together for two decades remotely, so, you know, Same to us.

It does, I think this is, this is the age old in the office versus remote. And I will say what I always say, for me, I will never go back to an office. It works for me asynchronously.

I can work, you know, this Mike, I can work at four 30 in the morning and then work for a couple hours, go do my thing, come back, you know, seven 30 at night, get stuff done when I can get stuff done. That works. Uh, some folks that it doesn't work for them.

They need to be in the office and have that structure. They need to be able to leave it behind when they walk out the door at night. It's, uh, I think it's an individual thing.

And I think when you are trying to figure out who needs to be on certain projects, even down to that level, you need to also take into account people's personalities and preferences and work styles. And I think that is also an area where some of these workflow tools might benefit from AI or at least some other kind of way to, I don't know how to factor that into who's working on it, where it is and how to move it along. I to check in, you know, there's always like a segment in there where we should get together and have a conversation because we're gonna, some level of inspiration we'll do just where we're, and I move on, Right?

You're in Colorado, You know, the software development teams, much like you and Sharon have been working distributed remotely. That's why we have GitHub is why we have GI that was made for distributed development. Yeah.

Not, not saying that solves every problem, but we, we've been doing this for a while. We saw during, uh, we did a study as Textron research about, um, remote work, the future of remote work and how much organization was kind of picking up either knowingly or unknowingly some of the agile and the, and the DevOps ideas, even though they weren't doing unquote DevOps per se. I, I think, I think it's just a fact of the matter.

We're not gonna live in a world where everybody goes into the same office. And um, my argument's always been, and when you are in the same building, you're around about 30 people that you normally work with on your floor. You don't go to the other floor to collaborate with PP people 20 times a day.

I mean, you still work in smaller communities, whether they're online or even in an office. So, I dunno, I just live in a world where the best talent is wherever the best talent is, and I don't wanna be limited to the talent that's just in Thornton, Colorado, right? Or even Denver for that matter.

There's a lot of people in a lot of places like canoe development and there's some techniques we've learned, like having some common times where we know we're all gonna be online if that, if that works, depending on how distributed you really are. I also had a really great development team, wasn't my team, it was one of my folks team in Atlanta and they had a, they were all distributed all over, not even, you know, not in the same state, all that kind of stuff. And they basically got, uh, office space, uh, twice a month where they would go in and do a day day of collaboration, you know, sitting in the war room and kind of working together to get that part of the, of what they can't get in an asynchronous world.

So there's ways of doing that. I, but I understand Alan's frustrations. I mean, I remember CEOs looking out the window and saying, where's all the par cars?

How come nobody's here working? You know? And that wasn't that long ago, by the way.

And not Alan, There's, I, I know we don't like to talk about cryptocurrency a lot, but I'm going to use the Ethereum developers as an example here. Uh, they, the teams that work on Ethereum, on the backend, all, all open source, and they are, it's global. They're in Australia, they're in France, they're in Italy, they're in the US on both coasts and they make it work couple times a year.

They have a big developer get together, they pick a fabulous city somewhere around the world and they go for 10 days and get all of the stuff that they need to do in person banged out. And it works. And it's lovely.

So I, I would be lying to you if I do not stay at least once a day, maybe every other day I at a minimum, but you know what? I need to go home and get something done because if I'm sitting in this office, you know, I 10 people running. So not really me, what I'm working on at the moment, and I'm trying to rush because I to do in my life and I'm really interested in your political opinion for about five seconds, right?

Whatever this week. NCAA jacket, you know, let's be honest, it's not in the office either, right? Because sometimes when you go into the building, Right, I call that 3:00 PM Mountain Time, Denver, just when everybody in the East Coast is kind of getting dinner, going home, picking up the kids, gets really quiet, you know, there's, and, and vice versa, right?

It works both directions. Absolutely. I get so much done in the early morning before our West Coast folks log in and start hitting me up for stuff.

So yeah, it, like I said, it's all individual preferences and mostly what works for the people involved. Alright, We're gonna sit gears now to talk about the rise of dev at the Edge. I feel like we've been talking about edge competing in some form for a decade or more, but something fundamentally changing and what seems to be is we're processing and analyzing data at the point where we consume.

And then as a result we're having much more real time interaction, less dependent upon gonna go away as a, we take all something cloud, cloud for further analytics. So the way that we kind of manipulate the data and work with the data is changing. What's your thoughts here?

It seems like, um, highly computing environments itself, limited resources. A I think it's a combination of DevOps and software architecture and devices. Because part of what enables this is creating distributed, even if they aren't fully distributed to the edge day one applications, you can talk about microservices and service mash and containers and that's just one path, right?

For doing this. There's also iot, a number of different kinds of ways that we create software, but, but the thing that you're pointing to is no matter how much speed we get to the edge of the network, how much compute capacity we might have there, it's still not the same as what's kind of core in the cloud. And, but that means we might need to do things at the edge because the data's there.

I don't wanna ship the whole data lake to the cloud to be able to work on it. I want to do it right there and I wanna distribute some work to where that is located. So, you know, data itself has gravity kind of hits hard to move a lot of data around at high speeds.

Uh, so that tends to pull you to locations in the network. Also, location where services or people or devices or things are also kind of put there. So I think that we're already in this world today.

I mean the edge is in our cars, right? If you have a car that connects to the network, if you have an ev certain, uh, vehicle for certain, right? They're talking to the network all the time and they generate, you know, some cases, gigabytes of data a day that either gets shipped off to some local edge process or somewhere else in the network.

So I think, I think as inevitable, but the more we can make our think of creating apps that are distributable where we want to distribute 'em can change over time. We just can't take a monolith and say, how do I distribute that? That's tough.

Yeah. I wanna get your thought on this, but I wanna frame it a little bit. Yeah, please.

Yeah. Widely successful gonna force us to like the of, I think, hmm, I think it's gonna have to, especially if we need real time or near real time updates to all of these edge devices. I think we gotta get, we gotta get over the hurdles and get better at deployment.

There's, I don't think there's any other choice. I'm gonna add to that too, Sharon. The other part of the other part of deployment is the more kind of infrastructures code that we do if we can manage it like we do code not, not saying the same way but then to GI ops or whatever method that helps us abstract what's at the edge to some degree and have more common stacks or at least know what we're running on versus I'm sticking it on some computer or some process or something at the edge, which I don't really understand well enough to know how to effectively deliver on our KPIs or our services.

So I think that's, maybe that's one I think dial in parting, uh, being able to help this. 'cause you think about your CCD process for your application, your, your stack and your infrastructure as code, uh, you can, you have more, more management of that as you deploy code Essentially up the way it teams organized. And I asked the question, Hey teams over here and there's network operations folks and a few security people mention a couple of engineer out in the middle somewhere.

And I feel like we have all these silos to just revisit that whole thing because what we're trying to do is much different. Well you can argue, you could argue that we're creating new silos, right? We had our own silos of ops and development and whatever, and now we hopefully we don't create a platform engineering silo and a operations tech silo and a cloud engineering silo and a security team silo.

So hopefully we're not doing that. I mean, I think there is a tendency human nature in some ways to do that kind of thing. I think we have to constantly think about, about, we just have to make sure we don't plant too deep a flags in the ground to say, I own this ground.

That's a silo. We to do that Points, um, to be, Ah, I don't know if I thought about it that way. I, I was thinking about it more as, oh, I don't know.

Um, I was thinking more about how all of the different departments were going to have to focus more on the larger whole to be more valuable to the business rather than solidifying their own power in their own silo. That's actually interesting. We, this is a, you know, we used to pay a lot of a to how efficient code was and cloud and kind efficient it's carbon we code to do something as possible and we didn't it as much.

We have to kind of revisit those skills that in a lot of ways wayside in the last, I think. So I think that is a is is a definite, because if you're talking about edge devices that may be in far-flung locations somewhere that you're not gonna have, uh, the ability to get to as quickly, if something goes wrong, then you absolutely need the code and the software to be able to do that for you. Um, I'm thinking of, you know, things like remote sensors and connected devices, um, but you know, that, that may not so much apply to, to other scenarios, but, uh, but yeah, I think, I think that's, that's definitely key.

We, we kinda always abstract things too, right? Mm-hmm. To make our job easier.

And whether you're talking about from, you know, flipping registers to a similar language to compile, to runtime environments, to whatever, you're always, you're always sacrificing some efficiency that way. I think the bigger challenge is just doing it smartly and wisely based on conditions, operational conditions and what's changing, right? I mean it's, most of these systems are so large and complex a person can't figure out the most optimal way to run it right now.

That takes different disciplines, it takes data. Maybe it takes some AI at, at, at certain points. Um, but we ask also have to be kind of smart and just not do dumb things.

Like if I don't need that to run every five minutes, you know, for the chance of one time it's gonna happen, maybe I could sit something else that's a trigger that will tell my stuff to run. Instead of writing a, you know, Aron job to run every five seconds there, there are ways to do things inefficiently that you could really tighten up as well as, and that's just a stupid simple little example, but an easy one to understand. Same thing for the way you write code, right?

You can sit there and pull these APIs and suddenly, uh, whatever SaaS service is gonna say, yeah, we're gonna turn you off. You're a little too, too greedy with our resources. So efficiency is always a challenge.

There's also the sustainability argument, right? A lot of people are taking that seriously of what can we do to write more sustainable code and how do we make sure we don't just switch the problem over to using every GPU in the world that could ever be made? 'cause we're inefficient about how we use ai.

And you know, there's another issue here too that's just about basic network latency, right? It's going to be less efficient and take longer if your network needs to struggle to get data or processing power or anything across to these edge devices. So that's another argument in favor of the efficiency focus.

So the one thing application, What, there you go, there you go. Software discover this. What, because, um, a lot of this stuff is a generation of developers out there that never have deal with, Well you think about what's happened in the, you know, even the ISP networks to our businesses in our homes, right?

And how much more capacity, you know, you have more, you're moving to symmetrical speeds beyond one gig through the cable networks as well as what we can do with fiber, et cetera. But that doesn't account for latency, right? I can do very high, high speed things, but a gamer could tell us, your guys' network sucks because you know, you, you think 20 milliseconds is fast.

No, I need to sub five millisecond, I need two, three milliseconds to, to do what I need to do, right? And that's just a use case. There's other business use cases like that too.

So you know, that one delay of 20 versus five in that one, one instance is not much, but you do that hundreds of thousands of times an hour a day or whatever. Now you're talking about really slow apps. So that's, I guess I'm, what I'm trying to say is that's one of the constraints you've always gotta design for too, is what is your latency as well as capacity as well as throughput, as well as all those things.

I happen to live in New York in LA Extreme and years living in Green Bay and other parts Nebraska. So I don't think has visibility all the way out to the about, but I, we need to kind of network monitoring and what we're calling observability demo. I am nodding along because absolutely we do that sometimes in our pursuit of the, no pun intended, cutting edge latest top thing.

We tend to forget about the basics on which all of that is built. So yeah, I think if we're not taking things like latency and network performance into account, then nothing that gets built on top of that is, is going to function optimally. And Mitch, to your gaming point, hell, heth no fury, like the wrath of a 13-year-old whose PlayStation game is not loading fast enough.

Ask me how I know Mom, we need to change internet providers again. I know. So yeah, I don't think most people can do that.

This three a lot more insights into this than I do. But I never know what any given goal, which those three don't. So kind of randomly see how it goes.

Well, and there's, you know, I, I'm not currently doing this, but I did it during covid, I was running two network service providers and there's a device on the front of it that looks at mm-hmm, which, which network's performing better and which has a lower latency or whatever. It might be more throughput to, to go across multiple or one or the other. Um, I mean there, there is that, that's why I kinda laugh at the 5G argument of this is changing the way how the applications that we're gonna be we're building and I mean it, it's all increasing.

It's not just the cellular network that's increasing, right? The throughput of it. So I think we have multiple options I guess is where I'm going with this is, you know, whether using in a 5G hotspot at home or you're connecting up to a 5G device or using fire or using xis over cable, um, infrastructure, whatever it might be, we've got fast enough speeds.

Now, if you can afford it and does it reach you is a whole nother challenge, right? Because that's, that's not equitable either. So it, you we're, we had the luxury in our office in Boulder of having multiple providers, but the fact that you have to switch over to see if one's better than the other, which means the one I'm on is not very good and I need to, something's happening.

I need to find something better. I need to go surfing for a better network. I mean, it was typically fine at 10 o'clock in the morning, then by two weeks it be be something's happen down the because a bunch other people are somewhere and it's all congested.

But we don't have a lot of visibility into this today. So I how critical mean, get to the point where I don't need a network and I want it to dynamically when I need it. It's not ubiquitous, right?

I mean as much as we and, and part of town, I live in great example, right on the edge of the cellular side side of it, but you know, in fiber or a coax, you know, we have great access. So that's one of those days, Mike, where you hop in the car head home 'cause I got a better network at home. I let those, uh, production guys, you know, push as much video and stuff across the network as they want because you have other options Working from home network.

See what I did there? Uh, I think, uh, watch out for Devon and uh, check your network speeds and argue for working from home. Those are my thoughts.

Here's your takeaways. Well, you know, it's, it's interesting the things that we're talking about are how is technology changing, but more importantly, how do we need to adapt to it on all those topics, right? Whether it's about Devon or where we work or you know, the kinds of applications being run at the edge.

And I think that's the part to always remember. I think there, there have been several instances the last month where it's like, you know, it's not actually the technology that's the question. Yeah, we know it can do it, but how do we, how do we do what we need to have done in order to make that happen, right?

Do we have to rethink how we're doing a little thing, a big thing, how we work? Whatever it might be. So don't, don't forget ourselves or the people element.

'cause that's probably the most important factor whenever we're adopting something new or trying a new challenge to be able to fully, uh, deploy it or leverage it to our benefit. We where you working from home.