Techstrong Gang – December 9, 2024

Happy Monday, everyone. If you are working from home, are you actually working Ghost Engineers in the Machine on Text? Drunk Gang.

Happy Monday, everyone. This is Alan Shimel for Techstrong and through the magic of Internet Time Dilation. I am still in Las Vegas, been in Las Vegas for a week, and anyone who goes to Vegas for conferences and work will tell you that a week is too long to stay in Las Vegas.

But I'm here. But hopefully by the time you're all watching this, I, I will be back home and, and recovering, taking a really, really hot shower to get kind of Vegas off me. But, um, I'm joined here today by a great group of, uh, gang members.

We'll start off with, uh, he looks like he's home in Alabama. It was. Saw him though over Thanksgiving.

Our resident AI Professor, Professor, Professor John Willis. That's Not going too far here. Let's, Okay.

Hey John, how are you man? Yeah, Great to be here. Great to be here with the gang.

Well, I don't think there's any licensing or special test to take to become a professor. This is true. So, Yeah.

So we wanna call you the professor. Fair Enough. It's good enough.

We, we anoint czar, so what the hell's a professor? Yeah. What the heck?

This, the professor's minor. That's kind of Alright. I gotta work my way up to Czar.

So, yeah. Uh, Joining John and I from Futurum and Visible Impact, it's our own analyst here. Guy Currier.

Hey, guy. How are you? I'm great.

Good to be here. What? Good to have you on.

I did not, I did not have to go to Vegas, so, um, my showers have been normal. Yeah. I don't blame you.

I wish. Well, no, you know what? I, in all honesty, I don't mind coming to Vegas.

I just like to spend three days, two nights here and gone. Um, so, but that being, yeah, I, I, I actually love productive, I, and I love the AWS uh, reinvent show. Yeah.

Last week and, you know, um, and all of that. But, um, also, it's just great to be home sometimes. Yes, it is.

Yes, it is. Joining Sometimes. Sorry.

Yes. Speaking from home, our own Tracy Ragan got her internet straight here and ready to rock and roll. Hey, Tracy, how are you?

I'm doing great, and I like being home too. It's something to, I also like Vegas though, if I was going to go to a show, Vegas or, or New Orleans would be my two favorite places to go to a show. Fair enough.

Fair enough. All right. And then home from Vegas himself, our Chief Content Officer, Mike Vizard.

Hey, Mike, how are you? I'm well. I did the two days and left, so, you know, you should have come home with me.

That's all there is to it. You know, I was thinking about it the other day though. It's like, on average for over the course of 30 years now, I think I've been in Las Vegas about once a month.

So there you go. That's, that's a lot of Vegas. And I don't think I've been there for more than three days at any time.

And not even a statue. A little, a little godfather reference there. All right.

So guys, we, we've got a lot to talk about. Today. We're gonna talk about is there such a thing and what is it, an AI engineer.

We're gonna talk about CrowdStrike crowing a little bit, but before we get into those, Mike, we were gonna talk about ghost engineers. Yeah. It seems like this past week was the time everybody decided that it was good time to kick those remote workers.

There's a report outta Stanford saying something like 10% of, uh, software engineers are ghost engineers, and that they don't contribute much to any project. And just to add a little fuel to the fire, I think it was, uh, Senator Jody Ernst Ernst has a, has a report out, uh, given the government workers a hard time for being remote workers and not being productive. And of course, it's always easy to kick the government workers these days.

There are some folks who think that that whole report is a political stunt, but I know you've had some opinions about remote workers over the past year. So, you know, as you look at all of this, what's going on? So let me, let me preface everything I'm gonna say by pointing out that you, you could be a ghost engineer and be in the office, you know, that class, classic office, office space line.

Mm-hmm. You see a 25 years, what exactly does he do? Um, right.

There are plenty of people who make themselves busy in an office, but when you look at their output, they're, they're not real productive. They're just not real productive. And so, um, this isn't aimed strictly at at home workers, but I, I think, you know, call, call it what it is.

This overwhelmingly it, it's at home workers. And look, I know, I know people myself who've called me up for advice about what to do. They have two full-time jobs because there's just, you know, short of being big brother and watching every keystroke and what your fa you know, your time on your computer is, and all of these things, it, it's very hard to track one's, you know, what one does with their time, uh, from an at home or remote job.

Um, and, and quite frankly, if you're really good at generating code, even even tracking it by, you know, amount of code written is not necessarily indicative of how many hours you're working. And one could say, well, if I get enough code written, what, what do you care whether I work four or eight hours? Well, if you could get that much code written in four hours, think about how much you could get done in eight hours.

And as an employer, I'm paying you for eight hours. I should get my eight hours of work. I'm not asking you to gimme eight and a half or nine, but if it's eight or seven or whatever it is, you know, work the day.

And it's a tremendous, you know, we, we talk about when, when Covid first came out, a lot of people started working remotely and they had never worked remotely before and they didn't have an off switch. And these guys were working 12 hours a day and 10 hours a day, and they were just always on. And that's not sustainable.

Right? But there were a lot of employers that were rubbing their hands saying, oh boy, I am getting my pound of flesh outta these people. Right?

And my money's worth. Well, that, you know, but that, I think that sort of has passed. And now I, I think if you ask most employers, yeah, there is some, not a majority maybe, but that it is a majority.

I think the majority of workers who work remote give you an honest day's work, and they work. It may not be nine to five or the times you're on because they may run out to do something for their kids or their spouse or parent, or they got something going on and what have you. But they give you a full day's work.

But there are a percentage that don't, whether they're working two jobs or they just don't work very much during the day, that just, you know, they're, they're, they're fat on the, on the griddle, on, on the machine. And, you know, I, I'm not pointing fingers at government workers. I think for the most part, government workers are actually overworked and underpaid.

And I don't want to give any ammunition to Elon Musk and the other dude, I forgot his name, Vivek, whatever. Zai, yeah. Coming in, you know, and using that as an excuse to, to cut government to the bone.

So I, I don't buy that government workers or any better or worse than workers in general on this. But, you know, there's something we need, you know, but certainly we need a better way of saying, Hey, if you're gonna be remote, how, you know, how do we ensure we're we're getting the productivity we Need? I was thinking I wasn't gonna talk on this section, but I guess that never happens.

I, I, I wanna make a couple quick points. One is, you're right, Alan, that like, the productivity is not the covid night. How many of us have been in large organizations?

I remember being in a place one time that was designed by Ross Perot, so that you actually couldn't find your way around, uh, an EDS business, and you literally couldn't find the bathroom from the cubicle you are working on. And that was by design. This is designed was you'd look out a place if you weren't supposed to be there.

Right? But that wasn't the point. So I'd have to follow the windows, and every once in a while I'd go by somebody in Cube who'd freak out.

'cause all they were doing is playing games all day, right? And they expected nobody, 'cause they were in a corner window area that nobody ever passed by. But the real question is, let's not complain productivity and how we judge productivity of a worker with intellectual property.

'cause those are two distinct things in this topic, right? Productivity is productivity. Like, and your company should be responsible for gauging.

And, and, you know, and you know, I mean, the kind of contracts I've had, like Red Hat and places like that, right? Like, it's very clear what your goals and specifics are, and then it's really clear about IP and, and confidential information. So I think the, the real question then is, if, if you're gonna have 10 jobs, you gotta figure out how to get your productivity.

You gotta figure out what's in your contract. And if the, if the company isn't providing a very concise contract on what your contracts are, and then more importantly, um, you know, your liability as a person, a young person who thinks they can do this like 10 job stuff, and the minute your name gets attached to something that pops up as an ip right? Problem, all hell's gonna break loose.

Well, all of this annoys me. The one thing about the, the, the, the research and GitHub, when are we gonna stop measuring a person's productivity by GitHub? It is not the way to do it.

I, I mean, developers, I was a developer for a very long time. Did I spend all day coding like a machine? No.

You know, there were, I can, I can remember weeks that I was brought some kind of package in that we were trying to use and we couldn't find, figure out why it wasn't working. And I spent the entire week in a debugger. Did I, did I commit any code at that point during that week?

No, I didn't. I can think of days that I've spent in meetings with end users. So it's unfair to judge anybody's performance by GitHub.

In fact, we had a customer that added, added that to deploy hub, to try to track who was doing what, how many, how many, you know, how many pull requests were created. And we do that in the open source community too. But it's not a good judge of a person's productivity.

It's a care of Judge the way GitHub is being. Yeah. Tracy, the way GitHub is being used though here is as a, uh, um, to represent, uh, coding as a whole across Yeah.

But that's a, there's a crazy assumption that developers do nothing but code. Well, right? So, so, right.

And that's not, I think, I think problem level one is what you're describing, which is, is this data set representative, And I would say data set being, no, it's not. It is not. And the other thing is, is that what you'll end up with is you'll end up with a, in on a team, there's different personas.

There is the developer, male or female who doesn't wanna be in meeting. So all they'd wanna do is code. And they sit in the corner and they code like a machine, and they're really good at it, but they're terrible at doing other things.

They're, they're terrible at testing their code. They're terrible at even managing what they're putting in their code sometimes. And so you have to have somebody evaluating that code, doing, you know, doing code reviews.

So there's so many different roles at in the developer, uh, you know, yeah. World that you can't judge it. And it annoys me.

I get so annoyed with the Lennox Foundation because everything we do is based on GitHub requests. What about the people who doing are doing derail, who are writing blocks, who are going out and doing talks? Their developers are working really hard, but they get no credit because it's not in GitHub.

So this is a, a pain point for me, and it irritates me that this is being a judge for developers because it's simply wrong. Yeah. It's what strikes me about this, frankly, is, I mean, it's, it, it seems so obviously, uh, intended to grab headlines and notice, um, to get this headline number 10% of all software engineers suck, you know?

Um, and to be honest, but 10, but, But 10% of all people suck at something. That's what I was getting. Was 10% high or is it low?

To be honest, 10% actually. I mean, I worked at a large multinational company, and I would say one out of five people I worked with were just what I call pushing pixels around. They just, they, they, they, you know, the, the famous, uh, cases of people showing decks in meetings, um, no, no, no slides of which they created themselves.

So they're, they're, they're just sort of communicating from meeting to meeting, acting as though they're doing things when in fact they're not, they're just, you know, what, what they, they are, uh, they're people, people like, like in the office space analogy, I'm a people person, right? So 10% just honest face, even, even even to attract attention in the proverbial eyeballs into highlight Stanford University or whatever it is, or this particular research researcher, um, there's a few good things in here, but that headline number and this claim is not one of them. It's taken out of context.

We don't know if 10% is good or bad. They just make it out like it's bad. What do you want?

A hundred percent of software coders to be competent, capable, and productive? That's, you know, what percentage is good. Mm-hmm.

So, but let, let me be clear here. You know, we all have our God-given abilities and guy, you may be a better software engineer than me, and, and John Willis may be better than you. And so if we line up 10 of us, I may be in that bottom 10%.

And there are some organizations that say, Hey, you should trim the bottom 10% of your org every quarter and replace it so that you're constantly upgrading your team. That's not what I'm talking, I don't think that's what this is about. I don't think that's what these studies are about.

I'm talking about there is a group of people that are deceiving and taking money under, under false pretenses, right? Taking a full-time job when they already have a full-time job saying that they're working full-time, when in fact they are not working full-time. They're, they're, they actually spend three to four hours a day at most working.

And that's deceitful and that's stealing. That's not just being bet Then that's shame, shame on the manager. Right?

Right. If the manager hasn't seen that, I mean, especially in the remote situation, but I, you know, O Open makes software and deploy hub. We've always done remote.

We've never really o only for a very short curdy time. Did we think we should have an office? And then we got rid of it.

And yes, there were times I had to fire people who were working remote. 'cause I, they were not producing. But I knew what they could produce and I knew what they were producing, and I had to get rid of them.

Is it fun? No, but that's what the job of a, a manager is, is you have to make those calls. So are you making your deadlines?

Is the project on schedule? Do you have somebody that you're caring that you don't want to, that is the manager's job to sort out. And if a manager's not taking care of that, then it, it's certainly not the job of, you know, Elon Musk and Ramos Swami to do that.

And in that, in my opinion, that is the description of a deep state. Somebody who is taking a government role, who is not appointed or elected and is making massive changes to people's lives. That is deep state.

And I just wanted, why, why I started off with, I think the conflation. So this whole conversation, conflates productivity and intellectual property and leadership, to your point, productivity is productivity. And I think we went in the right direction of covering all the terrible ways, including the McKinsey report.

Um, you know, all the sort of DX stuff space, um, does not correctly measure productivity. We don't really have a good grasp on how to measure productivity and knowledge work. And then, um, but I think this conversation about fraud or Alan's point, dishonesty is also an intellectual property problem.

Again, who cares if you're productive and you don't, you don't like conflate uh, IP or confidential information. I mean, it's your time. It's your time.

Every contract I've ever written, it's very clear what I'm gonna do for you, what I'm, you know, and what my time and things. I, you know, the first thing I dissect a contract and everybody does, right. Dissect a contract.

That would be really clear that when I work for you, this is what I'm gonna do. And, but I'm gonna do other stuff as well. And you Don't know.

But, but that's a contractor, that's not a full-time employee. No. You, you, every employee has a contract.

It just Yes. Your question. And so when I have an employee with, so he, you know, this is something my kids would tell Me.

My son signed your contract. I Reviewed it. Yeah, no, I get it.

But, but, you know, but my kids would say, look, if I do the amount of work you expect me to do, and it only takes me three hours instead of seven hours, what difference does it make? You should be happy. I do it in three, and this way I have time to do other things.

But as an employer, I will tell you, Hey man, I'm paying you for seven hours, and if you finish that in three hours, again, shame on the manager for not giving you enough work. But I'm entitled to my seven hours. Mm-hmm.

Yeah. That's what I feel that I saw as an employer. That's how I feel about it.

Yeah. I think, I think, I think the challenges, the challenge is definitely on the managers. And there's a lot of managers who don't know how to manage a distributor workforce.

They're, they prefer to have everybody locally because, you know, it's easier for them to manage by walking around and kind of see what's going on, and they have a better feel for it. But the fact of the matter is, And if that's how they're managing, then they're not doing their job. Because they will make some, somebody who's really good at not doing work will make friends with that manager and get away with murder.

And that's happens. It happens all the time. This is true.

And the trade off for that is, look, the best talent isn't always gonna be within a two hour drive of your office. So, you know, you're limiting your pool. So at the end of the day, you've gotta kind figure out as a manager how to make all this stuff work and, you know, make sure everybody's putting in the full hours.

But this is called the modern world we live in. And if you can't cope with anything, I Mean, look, I I, I'll tell you, as, as an employer, right? And I've been an employer for many years, there's a balance.

'cause people are people. John has to take his wife to a doctor, God forbid, or the, you know, something's going on, especially when people are working remote, right? Um, I'm meeting my girlfriend for lunch.

I'm, I'm doing my laundry. I'm doing my laundry. Right?

And, and you could be like, oh, you shouldn't be doing your laundry on company time. Yeah. But yeah.

B******t. That's, that's not the way the world works today. Right.

But I, I think I've developed, and Mike, you and I have worked together a long time. Mm-hmm. I've developed a sense of, of who actually works full time and who frankly doesn't.

And, and I usually look to move those people out. 'cause I just don't feel like we're getting an honest days out of 'em. But here's what I'd like to ask John and, and, and Tracy, um, 'cause I think, I think it's what I would like the audience to this, the audience to understand, which is, which is a deeper question, which is why software engineering and app dev has been so obsessed for so long with productivity.

And I, I kind of mean obsessed. It's a constant topic. And all these kinds of metrics and measurements, lines of code is one of them.

This particular study provided some qualitative measurements. Okay. What is it that makes that, that creates this obsession?

'cause I don't really see it in other branches of engineering or for other job functions. Yeah. I mean, good because it's bits and bytes, it's, it's knowledge work, right?

It's the ki it's the industrial engineering, ver industrial economy work versus, um, knowledge economy work, right? Like, it is very hard to measure productivity and economy work, right? It to, to have, um, you know, quantitative metrics.

And again, we've, I, you know, I I just pinged Tracy on chat as you saw it. Like, you know, things like SpaceX from, from, from, you know, from GitHub, you know, I, they're terrible. They, they don't equate to the bottom line.

Um, so yeah, I mean, I think, you know, I I think like Nathan Harvey over GitHub who's inherited Dora, and, and like, every time I rant on Dora, uh, Nathan will grab me, and rightfully so, say John, we use these metrics to start conversations at Google. And I'm like, yep. Are you in, you know, I lose.

Um, so I, I think we're just, you know, I think we have to be better at understanding why we use quantitative. We don't use enough qualitative. And I'll say one last thing to Alan's point too, is that like, the world is changing, right?

I mean, a gig economy, it is gonna be more transactional. You're gonna find more workforce people. You're gonna hire that literally, you know, this is what you're going to want me to do, even as an employer.

I mean, workforce automation companies are gearing up heavily for gig economy workers and gig economy workers are gonna be transactional. So like, I, you know, this is what I got you to do. I'm gonna do, and if I sort of do it, I'm gonna get paid for it now.

And, uh, the relationship is going to change from our traditional, what are you doing now? And not you, I know, you know, I've worked for you. You're not like that at all.

But, um, the, you know, like that whole, what are you doing now? Where is, where is Susie on Wednesday? You know, like, who cares?

Right? So, anyway, I'd like to hear Tracy. So the, so John, to that point though, that's, so that's project oriented, right?

If I hire you to do a project and I say, this project's gonna done By X, I'm gonna forced to hire people in the future. Well, and maybe, maybe that's the thing to do. If you hire remote people, they're project oriented rather than just mm-hmm.

I think they're just be transaction oriented. Yeah. And I think that's gonna be the norm.

But, so my pet theory here is, and then I'd love to hear what Tracy's thought is, but my pet theory here is that too many of these managers over the decades have experienced millions of supply lines of code created that had no valued output, or died or crashed, and became obsessed and worried with hiring big teams because software cost is very front loaded and putting together stuff, and very worried that the stuff would just never release. Oh, I think that there was a period of time that we thought in, uh, especially in monolithic development, that we thought we could just throw people at the problem and more coding was better, right? And there's this, there really is this image that we all just have to be sitting in our computers and typing on the keyboard and creating some kind of code.

Um, and that's not always the best solution for getting a product out the door. Right? And I believe that we still have that image.

Uh, a lot of managers and, uh, middle managers, they're suspicious because they don't know. They don't know how to look at some code and understand if that code was, was written well, or if it was productive, or if the five lines that they produced was better than the 50 lines somebody else produced, right? So the five lines of code that was written beautifully, that has no bugs in it gets a lower value than the 50 lines of code that somebody wrote that somebody that five lines of code person's gonna have to go.

Correct. So throwing people at the problem has never been the, the way to solve, uh, product productivity. And this is some of my issues with like, co-pilot.

It's just like, we just wanna generate lots and lots of code, but that's not software development. It really isn't. Software development is so much broader than just writing code.

And we continue to look at it from a how many lines of code. And that is the dumbest way to look at it. And, and, you know, in terms of the remote, the government in particular, let's look at New Mexico.

We have Los Alamos and Sandia Labs here. We have Kirkland Air Force Base, who's got a huge, uh, business in Space Force. If they try to rely on the community of New Mexico alone, they would have to, they'd have to shut down Los Alamos, to be honest.

They, they would have to shut down Los Alamos because there's no way that they're gonna bring in the kind of specialized technologists that they need for those jobs from, from Santa Fe or Albuquerque. Not gonna happen. And not, and not everybody wants to move to Santa Fe or Albuquerque, and they'll pass up on those jobs.

So, and that's for every single employer. We want those specialized, uh, uh, technicians, those specialized engineers. But we don't, we can't force them to move to the place where the company is.

It just isn't gonna happen anymore. Agreed. Agreed.

Anyway, Hey, we've gone way over on this one. We've gotta talk about two other topics here today. So let's take a break here on Tech Drunk Gang.

We're gonna be back and we're gonna talk about AI engineering. You are watching Text on Gang Modernize your business to fuel innovation and elevate customer experiences with the builder community. Hub AWS and its partner network provide essential tools for transforming applications and infrastructure to fully leverage the cloud.

Discover free trials, in-depth demos and essential resources to empower DevOps engineers and developers to deliver value faster and more reliably. Visit the builder community hub to learn more. Hey, everybody, we're back.

And as Alan was saying, we're gonna have a little chat about, well, what does it mean to be an AI engineer? ai. We ask you all to go check that out.

But John, I'm scratching my head these days, and here's my dilemma. Um, everybody who's a software engineer is gonna wind up working with ai. So why would I have something that is distinguished as an AI engineer when I think every software engineer is gonna be an AI engineer, kind of, sort of.

So I mean, what's the difference between what we're calling software engineers slash DevOps engineers and AI engineers? So first off, let's say, this is why I have no hair. I've been scratching my head my whole career.

But anyway, um, no, I think this is really interesting. And I read that article, and I, and I, you know, I, I think he did a really good job, I guess is avatar. Hmm.

And I think, but like this, there's this whole swirling thing going on right now, and it sort of total relates to what Tracy said at the end of her thing about AI and how we bled into productivity. I think that, um, you know, the first sort of question is like, there's, there's also like three people are talking about the, the AI engineer, right? So that's the new, new sort of phrase, right?

There is an AI engineer, and, and, and I think the reaction of most people is either this is, you know, stay outta my way. I'm just gonna build stuff now because I can, there are people sort of in the middle who are trying to figure out, okay, what's the sort of balance here? Um, you know, there's things like DevOps, there's security, there's all this stuff, and then there's the people who like, I can't do that because it hallucinates, right?

And, and nobody's correct here. And, and so that article, one of the things it talked about is that it added some like glass half full, I believe, because okay, we can go fast. And one of the side effects is that we can be a more opinionated possibly about how we deliver stuff.

And he calls it, um, you know, the, the complex or condensing or collapsing the stack. And, and that's interesting. The collapsing the stack I think is, you know, we don't go all the way to no code, but we go to like, okay, do I really like Andrew?

ER always says, you know, um, let's make the right thing the easy thing or the easy thing that I think everyone, which one he starts with. But like, I think we have this opportunity to, to reduce technical debt. You know, platform engineering is going is clearly be, as I see people migrate from Jupyter Notebooks to platforms that's happening.

Um, and I think, so we get some productivity gains, but we still have this bigger question of like, okay, we're going fast. Um, we're getting people to consolidate maybe on languages and stacks, because now they're less concerned about, should I use Java? Should I use Stream?

Should I use, you know, what front end, what backend? Like the whole idea of having an organizational structure of like backend people being in Minnesota and front end people being in Dallas, right? That's gone right?

When we're no longer that nonsense. Alright? So that, that's one thing.

And then Patrick Debar has a great presentation he recently did for this, uh, AI devcon and, um, you know, how AI is changing products. And he makes this really interesting point that I think everybody's missing. The productivity, the tools in the productivity and the evolution of like things like copilot and, and cursor and, you know, ADA and all these tools now that clearly make it easier to write code, easier to write tests.

But he pointed out loud, there's sort of a, we're starting to see this evolution of these tools like saying, allowing to pull in the dock, the requirements, you know, so like in in cursor you can say at sign Jira, and you can pull the Jira tickets. And so there is this opportunity. So while this gentleman says it's about collapsing the stack, I say this sort of paradox here, it's actually about collapsing and expanding.

So now because we have these massive context windows, hopefully everybody's still with me. I cannot, you know, when I'm asking our code, I could in the context add the business requirements, the security requirements, the, the des all the design requirements, I can add in the documentation. I can even give some sense of how this services operated from the incidents and think of all the test requirements, not just testing, but code coverage.

And if I put that all in context, when I'm trying to ideate new code, this is a plus. I mean, it doesn't solve the, this stuff just generates code willy-nilly, but you know, the glass gets a little more than half full because all the things we've been terrible at, you know, the, um, the non-functional requirements and things like that, we sort of like DevOps has been screaming that you need to do now to, to, uh, you know, Andrews, you know, we make the right thing, the easy thing and what is the right thing? There's a collapsing of the stack RU'S technical debt, and we're building in sort of an invitation or even the tools recommended, Hey, have you pulled in the doc?

Have you pulled in the requirements? And again, I, you know, I, I know what Tracy's gonna say next, but, but, um, it is, but, but I, I don't say that that solves the problem. That isn't like check mark done.

But I do believe to Patrick's point, and I would, we should put a link to his presentation, I think we have this opportunity to clean some of the messiness that DevOps promised for developers and software engineering. And then the one last thing is, I think as we talk about the new AI engineer, we need not to forget about the best, the good or best practices that we've been proclaiming for at least 10 years about the best for a software engineer. Well, I think the interesting part of that article, the, what what caught my attention most was this idea that we ha as developers and maybe an AI developer has to be better at it as being, being more customer centric.

You know, really writing software with the, the, the customer in mind. If an AI developer is better at that, I'm so happy because as a software developer myself, I think I suck at it. I, you know, I get caught up in the tech and I forget about the who I'm writing it for.

So yes, let's be more customer centric and maybe AI developers need to be, because in that article, they, you know, we talked, it talked a little bit about whose responsibility was it if AI goes wrong, right? Where's the lawsuit? I always asked, you know, if the car, if a, if, if a, if you, Tesla, you're driving autonomously gets a ticket, whose responsibility is it?

Is it Elon Musk's responsibility? Is it Tesla's incorporation responsibility? Whose responsibility is it?

Is it, we, so AI will make us be more customer centric, huh? To a certain extent that question's been answered, right? If you, if you get a red light, uh, ticket, you know, from one of those remote cameras, the, the owner of the vehicle's responsible because the camera can't necessarily tell who's driving or know who's driving, but you as the owner of the vehicle are responsible and you get the ticket.

But that's a fall flag. So wait, John. Yeah.

Um, alright. I just wanna say something Mike real quick. Is that I, I don't, I the idea that like, AI software is gonna create new liabilities, software is creates liabilities.

I mean, the, the Air Canada, the one he quotes in the article that actually I, my guess based on some forensic, it happened two years. He, if they were using G GPT two Air Canada, I don't think that was, in other words, that was basically code that looked like a copilot. I don't think that was AI based.

And, and so the point was that was software. So her argument about AI causing this crazy thing that's gonna destroy the world because it's gonna create new liabilities. Software has been night capital, you know, night capital, somebody missed a comma.

And basically a company lost like $400 million in 45 minutes and was second largest high frequency trading. Al Gore on Nasdaq was outta business in a day, right? And there was no AI involved in that.

So I, I think we gotta be really careful. Will it create more opportunities for liability? Absolutely.

But software by itself creates liabilities. All right. I I thought that, uh, Tracy, wait, wait, wait.

We're, we're running time on short here and I gotta get this one in. Um, John, we spent most of this week with Amazon, and it was AI all the time. And as we look at this condensed stack, are any of the vendors getting better at providing that?

Or is it just a miosh of APIs and, you know, hope for the best? There's A great article, and I'll, I'll send it to you. I was gonna send it to you.

It's, it's basically a whole discussion about model wars and productivity of the model wars and, and the marketing involved. And even like is, um, is open ended gonna have to rename GPT because the next version won't be generalized pre-train and transformers, right? And then who's, how everybody's staging the delivery of their models.

So part of everything with Nova is a lot of marketing and, and, and I'm not saying the technology isn't solid, but like everybody is like this idea that we're faster and better today, like blink tomorrow, it doesn't matter because right now Google's like, if you read this article, Google's already like trying to figure out like, when's the best time? 'cause last time it didn't work out well. So even and GPT five, there's a whole article with Sam Altman about like the cat and mouse stuff they're playing on when to announce GPT five.

It has nothing to do with the technology, right? So, so when I look at what Amazon did last week, most of that is positioning of when do we announce, when do we do this? What was the best time?

There was a lot of work, but there are some technology substance behind it. One is their new chips and the new chip set that was in sort of stealth mode, the, um, the train heran, which tells you a little bit, yeah, yeah. Right.

So that's, you know, I mean I think that's fascinating, the guardrail stuff. And I know, like, I think the, the interesting thing that Joseph, me and Joseph Aax a sort of a tech strong, um, part of our tech strong, um, what we call the, the, the hackathon we did, um, you know, he's pointed out recently in an article about one of the biggest things he liked is this, um, FOL, this, um, you know, following logic. It's like predicate based stuff.

And so it's interesting that their guardrails might be better than the other, like the vertex, I, I don't know, because they've got, like, again, this, um, this, you know, the, this FOL stuff is really, really interesting for rag validation. So I think to me, the models are just noise. Yes.

Great. Um, bedrock, I don't stink has gotten any better. Um, you know, alright, they got models that are competing great.

Um, they're still confusing everybody with their relationship with Claude. But the real interesting thing is that, that the sort of the self chip stuff and this F-O-L-F-O-L stuff, this, uh, Let, let me step back here a second though. John Chay guy, everything you're saying, I'll give you a given.

Is AI real? Yeah. Is, is all of these things, it's a little bit of a one step forward, two step back, and there's a lot of smoke and mirrors.

Yes. com, there were a lot of people out there who were like, what the hell is this guy doing? And one of the questions of the day is, is there such a thing as a DevOps engineer?

Should that be a job DevOps engineer And people like Patrick, John and Andrew and yourself and Damon, you guys were weighing in, and I don't re it's too long ago for me to remember, but some of you said, yes, there is such a thing as a DevOps engineer. And a lot of people said bulk crap. There's no such thing as a DevOps engineer.

And why are all these people advertising for DevOps engineers? This is the same question to me, 10 or 11 years later, are we, should we start seeing jobs for people called AI engineers? I, I think, I think It's fine.

And I'm asking you, John. Well, Yeah, no, I think, I think I was, I was totally against because the silo effect, the whole idea of DevOps was unite, you know, the, the sort of the graphic as a developer in the operations having a wall in front of it, another Andrew cliche. Um, and like by calling it a DevOps group or a DevOps team, or a DevOps engineer, it sort of defeated the whole purpose of what we were trying to do is create collaboration.

And I think an AI engineer and, and like it worked, like it got everybody thinking about this. Patrick is writing articles about how he's gonna start under, you know, dis you know, figuring out productivity, which he's doing some, you know, god's work there. Um, so maybe sometimes even DevOps, should we even call it DevOps anymore?

So sometimes words work and sometimes words don't. I personally believe it's software engineer. I think software engineer is what we call it because it is software delivery.

And the tools we use pre J and I post gen AI and whatever the next, like Sam Altman ish non GPT version of this stuff's gonna look like. It's still gonna be software engineering. Well, A front end developer and a backend developer, um, are both software engineers.

What about a full, an AI engineer could be a kind of a software engineer. I, I think it runs across the stack. I don't know about it condensing the stack exactly.

But, um, this idea that the core, I thought, I thought the story, Barry, the lead, I thought it was an excellent ly written article, but I thought it Barry the lead. I thought Tracy hit it, which is this, is this, this function of being concerned about how the AI service or services fit into the, uh, the stack for a particular application or set of applications is one that has to be focused on the outcome. We have been saying for so long, you can't just run ai.

It needs human intervention, needs human review, and your user is your ultimate human reviewer. So if there is such a thing as a function of being concerned about ai, whatever you label it within the application, that is the right focus, what's the outcome? But he missed the point in that it isn't about the collapsing or condensing, it's about condensing.

And it's a paradox. The expansion is how do we use AI to include the other things like GRC, like requirements, like those things. And I think that's where he missed the point is that, you know, I mean, at the end of the day, how do you get, like it's, it's easy to ask a developer to say, I need customer success, or like, yeah, that's as easy as product, the developer productivity to figure out, like if you have the magic bullet for that one, you know, you're a trillionaire.

The, the real answer behind that, where he missed the boat, in my opinion, is the way they get customer sex. What is that? That's quality.

Where do you get quality? You get it from like your governance requirements, your, your GRC, your security, your performance. And like, if we can use AI to inform us that as, like I said, when Andrew says, make the right thing the easy thing, then we get, so if he tells a story of con condensing the stack, I don't agree with that.

I think it's a, you have to expand and collapse the stack. Well, everybody's a software engineer. Everybody starts as a software engineer.

And then we each gets, like we start specializing, um, somebody discovers they're really good at front end design, somebody's really good at understanding platform engineering. Somebody else is really good at understanding how to automate the, the factory floor. And then, you know, when I was, when I was working in industry, we all were on the same team, and suddenly we realized that some of those roles could be rolled up to a higher level.

But we're still all software engineers. Maybe we were doing change management at the time, which ended up becoming DevOps, or maybe we were, became operations, um, you know, people. But we were all in this, we're all software engineers that that is the truth of it.

And we all have different specialties, you know, just because, so, and, and to a point, uh, in our earlier segment, you know, somebody becomes a, a really good front end designer and they spend three weeks designing the system and use Figma and check in one, one file. They're gonna be seen as somebody who's not productive. So it's, it's all software engineering, but it's not all coding.

It's not all just just hands on the keyboard. There is so much to be done. And there's so many jobs around this process of in, of developing software and we are all software engineers that we don't necessarily have to identify each other as in particular areas.

Because in the end, we're all developing software regardless of we're doing a DevOps, we're, we're, you know, working on our Jenkins, uh, workflow, or we're working on Figma to design a beautiful system. And Amazon figured that out with the two piece team. And then, you know, I mean, you got, you know, like there's a number of really good Spotify and stuff, stuff Like that too.

Yeah. So, so yeah. I mean, so again, that, I think the idea is that it, there isn't really, and again, like I said earlier, I mean the idea, I, I don't think you're going to hear a company will say, oh, by the way, that floor is the, uh, backend engineers and for this, this team over here on floor 34 is the front end engineers like that.

I like it just, these tools are gonna make the blend so much. Does it mean that you need ux? I mean, again, look at the DevOps story, right?

Originally the, the concern was the testers were gonna hate DevOps 'cause they were left out. And I think what the community did really well is, no, no, no, come join us. We're not replacing you.

We want you to join in this sort of collaborative way of doing things. You know? 'cause it looked like it was just developers and operations originally.

And it wasn't, that wasn't, that was just sort of the poster trial for how to create collaboration. So, but I think, Hey, we're, We're, we're over time on this one though guys. And we still got one more to go.

So, uh, let's take a break here. I'm gonna be the break engineer and, uh, you're watching Textron Gang. We're coming back with our final, uh, segment of the day.

So stay tuned. Discover Textron Group, the epicenter of tech innovation. We are your go-to for reaching IT leaders and practitioners worldwide.

Our secret impactful content that sparks awareness, engagement, and top quality leads with us. You'll access editorial websites, streaming videos, virtual events, custom content analyst research, and more. Join our satisfied clients.

Let's revolutionize your tech journey. Contact us today and tell your story to the world in the most powerful way with Textron Group. Alright folks, we're back in this promise.

We're gonna talk about CrowdStrike, which is a bit of a follow up on a conversation we've had multiple times now. But CrowdStrike has revealed that it has retained 97% of its customers in the wake of that, uh, infamous outage. And guy, I'd love to get your thoughts on this.

'cause a lot of of us were saying at the time, you know, people are gonna flee and maybe not so much. And why did they stay? Well?

Um, I think that that's a good result for CrowdStrike. We'll start with that. It's defensively good.

5. That's what they say. 5, that's, that's not too bad.

Um, it, it was interesting that they positioned a, uh, uh, you know, an ultimately 12% loss in market cap as a good result. I think, uh, most people would prefer not to lose any market cap. It was down by 24%.

Um, and then, uh, rebounded. So that's kind of bad with their market cap. That's something like $9 billion in value lost.

That can't be good. But what really, uh, when I dug down into, uh, the release and what they were talking about, um, they may have retained customers, but they clearly lost in terms of renewals. Um, they clearly lost in terms of, uh, a certain amount of, um, position with their existing customers.

Um, they, uh, their growth slowed. And that's a loss of about $250 million when you do the math, um, of business that they would've had. All that said, that may not be so bad considering the incident.

And I really wonder if we might be reaching the point where perfection is no longer demanded of these cybersecurity companies, so to speak, where there's an understanding that these kinds of breaches and incidents, that it's an ongoing war with a back and forth of the, you know, a proverbial arms race with, with, uh, uh, just, just like military has been over the centuries, where defenses get better for a while and offense gets better for a while. Um, CrowdStrike is ultimately a defensive mechanism and a, and a leading one in the industry, um, against threats, attacks, risk on compliance and that sort of thing. Um, and, uh, they are exceptionally good at it.

And, you know, I note that they did three great things, um, which were, they admitted the problem immediately. They issued a fixed quickly and they made themselves publicly available, um, for comment and, you know, to the government. And because this was, you know, a serious problem globally.

Um, but they're not the first company to have done this. This is what every company has figured out, uh, every security company's figured out to do. Uh, be open and honest about it immediately.

'cause there is tons of expert scrutiny of the industry, um, issue of fix as quickly as possible, work with competitors as well as, uh, partners on continuing to strengthen the defensive side of this ongoing cyber war. They did all of that. I do feel that maybe the, there was a difference here.

I just don't know if that's an industry difference. It would be great if it was because in that arms race, there are times when the attackers are gonna win. Um, uh, their technology and capabilities and especially now with ai, um, are going to increase and the defenders are, are going to have to catch up to it.

And it would be great for the market as a whole to be a little bit more mature about this. One of the things that we've talked about, um, when it comes to cybersecurity and risk for many years is something called a LE, the Annualized Loss Expectancy. Um, rather than every organization either, you know, uh, being like the, the, you know, don't hear, don't see, don't, don't, you know, don't think about or care about low possibility risks of attack and, and, and breach, um, that they should think about it as an ongoing risk that has a loss that can be calculated.

The annualized loss expectancy is that calculation. I may not have an incident this year or next year, but like, given my chance of incident and the likely cost of the incident, I can just assume that I'm gonna lose X amount per year and invest accordingly to pre to lower that amount of loss. That's a mature way to look at it.

It's been around for 30 years, 40 years. It still isn't generally used. Instead, people either ignore the problem or expect perfect results.

And I like the idea that perhaps, um, the industry as a whole is getting a little bit more mature and a little bit more able to deal with serious problems and breaches. Like what happened at CrowdStrike with a little bit more finesse and a little bit better understanding. So I, I have some thoughts here.

Surprise. Um, first of all, look, kudos to George Kurtz and the whole CrowdStrike team. 'cause this was a poster child case of how to respond to an incident transparently timely transparency.

Timely, thoroughly, thoroughly. So kudos to them. Secondly, this was not a security incident.

Not a security incident. This wasn't North Korea breached them, or some hackers got in for some financial stuff or someone injected into their software supply chain, some malware. This was plain and simple sloppiness on testing an update that broke windows.

That, that's, that's what this whole CrowdStrike thing is. They didn't test their update. It made some, uh, not kernel that's kind of linuxy sounding, but it is.

They made it made kernel changes to windows. It's And those changes Yeah. Windows, correct.

Yeah. And it, and it broke it, it broke windows and, and caused the blue screen of death and made it a real son of a gun to try to back it out. You couldn't.

And, and Microsoft has taken steps now that security updates in the future won't be able to break the kernel and it will be easier to back out. So that's what we're dealing with here. This wasn't a, a security incident in the true sense of the word, but it was a bad software update.

It was bad behavior by our software companies. Every single one of you sitting here goes through this almost on a daily basis. Tracy, how many times do you sit at your desk and say, my God, Don bandwidth provider, it always works until I have to come on here.

And it wasn't, but how many times have you changed your bandwidth provider as a result of that? Well, people may, you may not have many choices, but you haven't changed your bandwidth provider. How many times have we gotten fed up with Outlook in Mac until I finally got rid of Outlook in Mac?

How many times does any piece of software or technology we've used Malfunctioned? And we said, g*******t, we're gonna change this. I'm throwing them out.

And how many times do you actually throw them out? I'll put forth the proposition that 97% of the time you don't throw 'em out and hence the CrowdStrike, 97% retention here. As long as they don't do it again, or too often, it'll stay that way.

Mm-hmm. But Alan, how was there, how was theory? Oh, go ahead, Tracy.

I was gonna say, there's, I think that CrowdStrike, I, you know, I was the one that said, Hey, CrowdStrike's gonna be fine. Remember when we first taught it, you know, everybody has some sympathy that as a software developer, what they went through, I felt really bad for them. Um, but I do believe that CrowdStrike should be looking at, uh, their model in a bit here, uh, because they probably shouldn't have the kind of access that they're asking for to these, uh, large companies.

It's not, it, it, it's probably a, an area that they need to review. Um, who again, who's responsible for that release, right? Did CrowdStrike follow that company's release, uh, process?

And are they do, are they, do they have somebody working for CrowdStrike that is supporting just that company? Is it a consultant in a box? If it's a consultant in a box, you probably are gonna have more issues like this and CrowdStrike will be blamed.

I still don't believe CrowdStrike was totally to blame for that process, because if they followed the, the release process of the customer, then the customer has some responsibility as well. So I really think if I was sitting on a CrowdStrike board right now, I would be asking, are we gonna continue having that kind of access to these enterprise, uh, production environment? But It, it's not a good idea.

But it wasn't to an individual, but Tracy, it wasn't to an individual customer, it was across the entire board. I know Windows, and so they have all of that access is a bad idea. No.

And so does every other app that, uh, that updates windows, that's, Yeah. I thought he was referring to Microsoft is Yeah, that's A Microsoft issue. Yeah.

I, the, the, the, it's a, it's a helpful correction to, to identify for this particular story where the source of risk was, which was not an attack. And, and I probably shouldn't have used the attack and defense words, but it is still the same fundamental issue. Maybe attack is the wrong approach, but the same fundamental of risk and defense against risk.

Risk of using these complex stacks to bring that word back. And, and the risk may be external from a level one actors. It may also be internal because of the complexity of the software development and integration process.

Either way, it comes down to the same basic point, which, which I mean, I kind, I kind of likened it in my mind to when we started using cell phones a whole lot and dropped calls where a lot more common. We were so used to plain old telephone systems where you always essentially got a dial tone. And then now there were times when you didn't, and the trade off that you made was that, uh, now you could walk around with the phone, but the trade off was that maybe the phone wouldn't work, and that was No, you would Work, I think, can you hear me now?

Can you hear me now? Yeah, you hear me now? Yeah.

Yeah. So it's gotten better. Many, but it's sort of the same thing.

Many Drove horizon Because of that. Yeah. But it's sort of the same scenario now where people maybe have the expectation that their window system is gonna boot properly and all that, or update properly and all that sort of thing.

But it doesn't, and it may not be an external risk. It may be an internal risk. Nonetheless, it behooves everybody to think about this and to keep it in their plans individually, that the things may just not work, including Tracy's, uh, uh, uh, uh, bandwidth.

You know, at times, John, Mike, you guys haven't weighed in here. Well, so, so I think that the points about the customers and the losses and those types of things, the glass is half full, right? It could have been a lot worse.

I think that, you know, they did okay and maybe they were prepared for things being a lot worse, and they're celebrating the fact that they just wasn't quite as bad as they thought it was gonna be. And maybe, I don't know, you know, if we get past this whole issue about how the Windows kernel gets updated, and I think Microsoft is trying to fix that. You know, they might actually get new customers in the future.

So I'm not quite, I'm, you know, I, I'm just, they're in the game And I only have one point. I just agree with everything everybody said in terms of all that. I don't think, I think a guy made a good point.

And I, I'm a real big fan of this, um, how to apologize correctly, how to be transparent, you know, uh, that, you know, this has been going on for quite a while. I, in fact, my friend Mark and Brachi, I think created this when he wrote the first public postmortem, um, back, you know, when he was 37 Signals, right? And, and he did it Heroku, and then Amazon started doing it for their outages.

So I, and then Capital One is a classic, you know, get in front of it, you know, don't go argue. Don't sort of defend yourself. Just be transparent, explain it.

And I think that has a lot to do with the, you know, why it's talents point. You're probably not gonna drop 'em, you know, I mean, capital One, I talked to people there and they said, you know, you know, we wanted this off of the front, the Wall, wall Street Journal. We wanted this off of that PA paper as quick as possible.

And the quick way to do it was take the hit, even though it was actually Amazon's, it was their metadata server. But, um, anyway, long story short, I think I'm, I'm, I'm laughing 'cause I worked for a publisher one time and she had this whole skit in her mind where she would say, I, I always apologize to the customer. I apologize that they feel that way.

I'm not apologizing for what we did. I'm just apologizing for the fact that they feel that way. Absolutely.

On that note, let, let's, uh, we gotta, we're at the top of the hour, man. This was an hour, an hour long, 45 minute show today. Um, so Guy, John, Tracy, thank you all for joining.

Mike and I here on the Gang. Uh, we'll be back tomorrow and hopefully I will be back in Boca doing this for tomorrow's show. Uh, but until then, this is Alan Shimel on behalf of Textron and the Textron gang, we've got a full day of, of Textron TV following this.

And we will have our Textron TV coverage from, uh, reinvent replaying next week or this week, excuse me, for you to watch as well. So, and have a great day, everyone. We're out.