Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads?
Speaker 2: Easy?
Speaker 1: Become a patron for just five dollars a month. You
Speaker 1: get access to a private RSS feed where all the
Speaker 1: shows have no ads. Twenty dollars a month. We'll get
Speaker 1: you that and a special dot net Rocks patron mug.
Speaker 1: Sign up now at patreon dot dot NetRocks dot com. Hey,
Speaker 1: get down, rock and roll build, We're here. It's dot
Speaker 1: net rocks.
Speaker 2: I'm Carl Franklin, average cap.
Speaker 1: And the end of the second day of recording for us.
Speaker 1: So you know, it's been a good two days so far.
Speaker 2: I got another one to go today. I've been knocking
Speaker 2: out run as, having a good time doing it. Awesome.
Speaker 1: I've already done a couple of Blazer puzzles and Jeff
Speaker 1: Fritz is chock full. I saw our friend Beth outside
Speaker 1: just now. Yeah, so who used to be Massy? And
Speaker 1: now I can ever remember her new last name is?
Speaker 2: It? Didn't change it? Oh? Okay, okay, did the wedding?
Speaker 1: Well, that's true, I was there and I don't remember.
Speaker 1: I don't even remember what I have for breakfast. That's
Speaker 1: good because I didn't have breakfast.
Speaker 2: Okay, here we go.
Speaker 1: Before we start, let's talk about nineteen fifty five. Episode
Speaker 1: nineteen fifty five. This episode nineteen fifty five. So we've
Speaker 1: been talking a little history about what happened. Okay, here,
Speaker 1: What do you like about nineteen Well, I just know
Speaker 1: a couple of things significant, you know, cultural, political, and
Speaker 1: social events. The first McDonald's restaurant opened there. It's definitely
Speaker 1: a cultural event. Yeah, yeah, fast food, right, Disneyland debuted,
Speaker 1: and The McKey mouse Club premiered on TV.
Speaker 2: Coincidence, I don't think so. No.
Speaker 1: Politically, the Warsaw Pact was formed and West Germany became
Speaker 1: a sovereign state. On the social front, Rosa Park's arrest
Speaker 1: sparked the Montgomery Bus boycott, and the racially inspired murder
Speaker 1: of Emmett Till caused national outrage. There's a lot more,
Speaker 1: for sure. What are you thinking about computer tech wise
Speaker 1: or science wise?
Speaker 2: The first atomic clock, which was measuring the frequency of caesium,
Speaker 2: so it was an incredibly precise clock. Wow, it was
Speaker 2: the beginning of the atomic age. Nineteen fifty five, right,
Speaker 2: But more importantly Velcrow now Velcrow and the Big Mac
Speaker 2: in the same year, and the first wireless television remote
Speaker 2: the Zenith flash Omatic. You know. I called it the
Speaker 2: flash omatic because it used light. It used light. They
Speaker 2: put a sensor in each corner of the screen, and
Speaker 2: depending on what corner of the screen you pointed at,
Speaker 2: it either turn channel up one or the channel down one,
Speaker 2: or the volume up one or the volume down one.
Speaker 1: Isn't that?
Speaker 2: It was simply cool. And before that there was you
Speaker 2: had a remote, but it was wired and people didn't
Speaker 2: like the wire So this was the first wireless, just
Speaker 2: with a flashing light. Yeah.
Speaker 1: I was the remote from my older brother. Yes, let's
Speaker 1: get up and change a channel. I'll smack you right.
Speaker 1: Were you the remote for your older siblings? Is that
Speaker 1: why you play?
Speaker 3: I'm the oldest, but I was definitely the remote for
Speaker 3: my dad.
Speaker 2: For your dad, I will have children except stupid.
Speaker 1: I tried to train the dog to do it, but
Speaker 1: never never work. It doesn't work out, all right, So
Speaker 1: I guess it's time now for better Now a framework?
Speaker 1: All right?
Speaker 2: Okay, dude, what do you got? All right?
Speaker 1: So I went looking on what's trending in GitHub and
Speaker 1: again for repos and.
Speaker 2: There's a lot of AI weird trending and here we are.
Speaker 1: Yeah, it's an AI world, So this one is awesome.
Speaker 1: Chat GPT prompts. This repo includes chat GPT prompt curation
Speaker 1: to use chat, gipt and other LLLM tools better so
Speaker 1: they chatpt but works with these prompts, work with other
Speaker 1: AI models. Claude Gemini, hugging Face, jet Lama, mister Roll
Speaker 1: and Moore. Thank you, thank you very much.
Speaker 2: Yeah, that's not going to show up all the ship.
Speaker 1: No, probably not, but Brandon, if it does, I would
Speaker 1: like to say thank you.
Speaker 2: Okay.
Speaker 1: So yeah, so that's it. I mean, it's it's kind
Speaker 1: of a long read me because there's a lot of
Speaker 1: stuff there. Oh yeah, but here's just a couple. Act
Speaker 1: as Ethereum developer, nice, act as a Linux terminal, act
Speaker 1: as an English translator and improver, act as a job interviewer,
Speaker 1: act as a JavaScript console, as an Excel sheet. So yeah,
Speaker 1: some very creative prompts there. I'm sure people are finding
Speaker 1: good use. So that's what I found. Who's talking to
Speaker 1: us today.
Speaker 2: Richard Gravin Kalinov Show fourteen twenty five, So going back
Speaker 2: to New York, have a little bit. That was March
Speaker 2: of twenty seventeen. We talked to our friend Damian Brady
Speaker 2: about Brownfield DevOps. Yes, I happen to know Nicole has
Speaker 2: done a little bit of DEVO related stuff over the years.
Speaker 2: And this particular, this is when we're sort of talking
Speaker 2: about bringing the DevOps practice of that sort of automation
Speaker 2: and controls over an existing application.
Speaker 1: Right, was Damian with Octoplus back then?
Speaker 2: I think he might have been Actually, yeah, of course
Speaker 2: he's a cloud advocate these days. And so our friend
Speaker 2: Hilton ge Is now commented on that show. Yeah, and
Speaker 2: he said, I was listening to the Brownfield devop show
Speaker 2: and realize some things. One, A green field is actually
Speaker 2: when it's lush and growing. Well, I'm thinking, say, like
Speaker 2: a cornfield or something, it's actually about to bear fruit.
Speaker 2: As contrast to Brownfield is one, it's just the start
Speaker 2: of the process. There's sort of a file new project. Right,
Speaker 2: So he's totally clipping the concept on his head. Right,
Speaker 2: he's not wrong, Yeah, you know. And then two if
Speaker 2: one things of financial services or wealth management firms is
Speaker 2: the idea of quote unquote building a legacy is a
Speaker 2: tremendous need to be proud of. It's something valuable lead behind.
Speaker 2: Whereas the software development is concerned to all something old,
Speaker 2: rotten and tarnished. It's definitely something you left behind because
Speaker 2: you changed jobs.
Speaker 1: Yeah, so I'm thinking of ways that brown field could
Speaker 1: be a bad thing. You know, I'm not so sure
Speaker 1: I would want to walk through a green field, but not.
Speaker 2: Through a brown field because yeah, you getr shoes to money. Yeah,
Speaker 2: it's not a good thing. It's not a good thing.
Speaker 2: So I mean it is possible. As an industry, we've
Speaker 2: actually got these terms flipped around, and you should start
Speaker 2: fresh with brownfield projects and build a legacy system to
Speaker 2: be proud of.
Speaker 1: It's really smart.
Speaker 2: Oh, Kilton, you're so clever. But you know, the.
Speaker 1: Planting grass, it's got to be brown before.
Speaker 2: It becomes green, and then the birds are gonna eat
Speaker 2: the seeds. You're gonna have to plant it again. Ask
Speaker 2: me how I know, Hilton. Thank you so much for
Speaker 2: your comment, and a copy of music Goba is on
Speaker 2: its way to you. And if you'd like a copy
Speaker 2: of music kobay I, write a comment on the website
Speaker 2: at dotnet rocks dot com or all the facebooks we
Speaker 2: publish every show there, and if you comment there and
Speaker 2: ever read on the show, we'll send you a copy
Speaker 2: of music Goby.
Speaker 1: Music to Code by the Flack version is now the
Speaker 1: most popular downloaded version.
Speaker 2: Yeah, because Flack play on everything, I presume it does well.
Speaker 1: But what most people do is they download them and
Speaker 1: Flack and then they convert them to wave right and
Speaker 1: they you know, you get the same quality, but it's
Speaker 1: half the size. It's like a zipped wave. Oh so
Speaker 1: flat the flat smaller.
Speaker 2: The wave is big.
Speaker 1: But yeah, yeah, Flack is half the size, but it's lossless.
Speaker 1: Good anyway. Music to Code by dot Net there's twenty
Speaker 1: two tracks. Go get them there. They'll help you focus
Speaker 1: and they'll help you be a better programmer. Okay, let's
Speaker 1: bring back Nicole Forsgren. She's a DevOps and developer productivity
Speaker 1: expert who thrives on helping large organizations reshape their culture, processes,
Speaker 1: and technology to improve their business and enhance the developer experience.
Speaker 1: She combines AI tools with developer expertise to help teams
Speaker 1: unlock productivity in innovation. And I know this isn't one
Speaker 1: of those bios that you feel you had to sneak
Speaker 1: AI in there just to be relevant.
Speaker 3: Because we know you really do that, I actually do.
Speaker 1: You're an AI person.
Speaker 2: Oh my goodnessess, well, I need wear on Donna rocks
Speaker 2: back in twenty seventeen with our friend Jas Humble in
Speaker 2: the day, the Dora days and a regular on run.
Speaker 2: Ass know, half a dozen times over the years, starting
Speaker 2: with that in person interview at the CHEF conference. I
Speaker 2: think it was. I think so it was a long
Speaker 2: time ago. Good to see you again, Good to see
Speaker 2: you having a good build, I mean love.
Speaker 1: Yeah, it's historic in my mind, this period right here.
Speaker 2: Yeah, really crazy emerging technologies. But you've moved on from Dora.
Speaker 2: It got acquired by Google, didn't it.
Speaker 3: We were acquired by Google.
Speaker 2: Congratulations, thank you?
Speaker 3: It was it was great. Yeah, the team that I
Speaker 3: got to work with there was wonderful. And the Dora
Speaker 3: team continues now.
Speaker 2: Sure they still do the report every year. I read it. Yeah,
Speaker 2: and then ever.
Speaker 1: Can you tell me just what is Dora and what
Speaker 1: was it? Or what is it?
Speaker 2: Yeah? What's the shorthand for Dora? Yeah?
Speaker 3: Absolutely So. Dora was a multi year now at this point,
Speaker 3: over a decade research project that looked into, you know,
Speaker 3: kind of investigating the types of things that can improve
Speaker 3: software delivery performance and organizational packed and output. So things
Speaker 3: that now everyone jumping the way back machine. Imagine being
Speaker 3: the late two thousands, early twenty tens, when we weren't sure.
Speaker 3: We were hearing stories that things like CICD were important,
Speaker 3: that things like continuous integration were important, you know, in
Speaker 3: particular automated testing cloud. So you know, discussions would come
Speaker 3: up with leaders and organizations or managers and they'd say, oh, well,
Speaker 3: you know that won't work here, or well that doesn't
Speaker 3: work like this, or we're a different organization, or even well,
Speaker 3: what do you mean by CI? What do CI even mean?
Speaker 3: Because you know at that point also everyone's just redefining
Speaker 3: it constantly, and so the research program kind of broke
Speaker 3: all of these pieces down and tested statistically across the
Speaker 3: whole industry. I mean, we had thousands, tens of thousands
Speaker 3: of responses and so we could and data points that
Speaker 3: we could really test on. So that's so DORA was
Speaker 3: originally short for DevOps Research and Assessment and it was
Speaker 3: the State of Develops reports. He originally started with the
Speaker 3: Puppet team and then broke out and did it through
Speaker 3: DORA well, and that led to the book Accelerate, So
Speaker 3: some folks know Accelerate. Accelerate is kind of it yeah,
Speaker 3: synopsis and summerization of the first several years of work.
Speaker 2: I always felt that you were the person who brought
Speaker 2: the real rigor to analyzing the results of these product
Speaker 2: teams to show that when they followed these practices, the
Speaker 2: results were substantial. They were orders of magnitude productivity increases.
Speaker 2: Like it seems so anecdotal until you started writing those reports,
Speaker 2: where now it's not acdotal, it's completely scientific, like, here
Speaker 2: are the numbers, here's what you do, and you two
Speaker 2: can have this experience, your teams can perform like that.
Speaker 2: You know.
Speaker 3: The other thing that I think was great, you know,
Speaker 3: I really value the partnerships that we had with you know,
Speaker 3: Jess Humble, Gene Kim Puppet, a lot of Brown, Nigel Kurston.
Speaker 3: I was this cute little baby faculty member and I
Speaker 3: walked in and I'm like, I would like to help
Speaker 3: you with some of your data. Oh, by the way,
Speaker 3: let's also really rethink the research design here so we
Speaker 3: can test some of these relationships out. And so, you know,
Speaker 3: to their credit, they were like, yeah, let's go for it,
Speaker 3: and so everyone kind of jumped in, and you know,
Speaker 3: Papa had been getting some really interesting results before and
Speaker 3: Alana Brown was the first person to really see that
Speaker 3: this was kind of an emerging field and deserve some
Speaker 3: kind of study. But by having this kind of research design,
Speaker 3: we were able to also do things like what pieces
Speaker 3: of continuous integration are important for performance and predictive with performance. Right,
Speaker 3: So for example, it's three things. That's when you check
Speaker 3: in code, you automatically get a build it, automa kicks
Speaker 3: off build it automatically kicks off tests, and you have
Speaker 3: to keep the build green.
Speaker 2: Right.
Speaker 3: And for some people that was you know, like they'd
Speaker 3: have two of the three because you know, it's same.
Speaker 3: I think it's same thing with AI right now. Right,
Speaker 3: it's all about the tech. It's like about the yes
Speaker 3: and the culture and what you prioritize and the decisions
Speaker 3: that the teams and the processes around that. So the
Speaker 3: nice thing is we had kind of the statistical significance,
Speaker 3: but also the research design helped provide direction regardless of
Speaker 3: whatever technology stack you were on.
Speaker 2: Yeah, that was the thing that was so cool for
Speaker 2: me reading all this. It's like it doesn't matter, right,
Speaker 2: like you if you follow these practices and grow this
Speaker 2: culture mindset, it doesn't matter what jewels you use. You
Speaker 2: can get these kinds of results. You know, there's obviously
Speaker 2: things ultimately need to build, but there's no secret sauce
Speaker 2: other than making the effort.
Speaker 1: Yeah, and now you don't even really need to make
Speaker 1: the effort. I mean, so many of these processes are
Speaker 1: built in, you know, get up actions and things like that.
Speaker 1: I mean, you have to set them up and turn
Speaker 1: them on. But it's trivial compared to what it was.
Speaker 3: Yeah, the world, the world's different. But I would also
Speaker 3: say that, you know, a bunch of this is table stakes.
Speaker 3: Now it's super important, and if anything, it's more important
Speaker 3: now that AI's here. Yeah, because now people are just
Speaker 3: making code and innovating, experimenting super super fast, and you
Speaker 3: know it just frustration and sadness and using computers and
Speaker 3: anger if you can do all of this incredible coding
Speaker 3: and prototyping and then you're stuck behind this giant wall
Speaker 3: of waiting for build and integration and slow feedback and
Speaker 3: flicky tests and nothing else works.
Speaker 2: Yeah, yeah, waiting for iety to heat to bloy. And
Speaker 2: remember build servers back in the nineties, build servers yeah yeah,
Speaker 2: well and the build.
Speaker 3: Master yeah oh yeah, what's old is new again?
Speaker 1: Yeah, and one person that was the only person allowed
Speaker 1: to do the build. It's like build, we did that
Speaker 1: on Fridays. But why we would do that on Fridays
Speaker 1: before going home from the weekend, I don't know.
Speaker 3: Because sometimes it took forty eight hours to round.
Speaker 2: Yeah, that's true. Yeah, no question or was that it
Speaker 2: was bunch like? So now a new book coming, Yes,
Speaker 2: And I saw on LinkedIn you had a vote for
Speaker 2: the title. Yeah, and I think Frictionless is such a
Speaker 2: good title, Like it just gives me chills.
Speaker 3: That's the one we had it on. So shout out
Speaker 3: to LinkedIn folks. Thank you.
Speaker 2: It's a good name. What are you talking about?
Speaker 3: So the book is about developer experience, right, and how
Speaker 3: it's important, why it's important, how you can make the
Speaker 3: business case, but especially, and I think most importantly, how
Speaker 3: you can improve developer experience yourself.
Speaker 2: We have you know, as a developer as the leader.
Speaker 3: Yes, right now, it's probably going to be easiest or
Speaker 3: most straightforward for someone who is the head of a
Speaker 3: developer productivity team or an infrastructure team or a DEVX
Speaker 3: team or you know, pick the word that your company loves.
Speaker 3: But there are still some really cool, good tools and
Speaker 3: tips and tricks that anyone could use. You know, it's
Speaker 3: almost like the old DevOps days, right, Sometimes you had
Speaker 3: exec support, sometimes it was uh grassroots.
Speaker 2: Yeah, just you know, I remember we told the story
Speaker 2: of this one person walk around asking questions. It's just
Speaker 2: sort of surfacing areas really of friction, yep. And and
Speaker 2: as the conversations start, it's like, hey, you know I
Speaker 2: could build you a tool that would make that piece easier,
Speaker 2: or you know, we can I could deal with this piece.
Speaker 2: You know, the folks and OPS were able to do
Speaker 2: certain things that was tough for DEV, and there were
Speaker 2: things that DEV could build and made life easier for OPS.
Speaker 2: And as soon as those conversations started bearing, things started
Speaker 2: moving faster.
Speaker 1: Yeah.
Speaker 3: And you know, so I'm writing the book with Aby Noda,
Speaker 3: who is you know, founder and CEO of d X
Speaker 3: and he's also you know, we're both but you know,
Speaker 3: having all of these conversations with technology leaders and developers
Speaker 3: and you know, finding the best you know, the best
Speaker 3: practices that we have right now around developer experience, what
Speaker 3: it means in traditional systems, how to improve it, what
Speaker 3: it means for AI right now. Like I said, if anything,
Speaker 3: it's even more important.
Speaker 2: Yeah, yeah, I'm just thinking about how because again you
Speaker 2: and I've had this conversation many times. How different is
Speaker 2: dev ops today? Admittedly, as car brought up, the tooling
Speaker 2: is better, but the asks are different now too. Everything's
Speaker 2: going to the cloud. People expect you to iterate very quickly.
Speaker 2: There are almost no version numbers per se anymore. You
Speaker 2: just supposed to the scale.
Speaker 3: The scale and the speed and the size are really no,
Speaker 3: they're almost On the one hand, I want to say
Speaker 3: they're changing things, but really they're not. I think they're
Speaker 3: amplifying things. Right, The fundamentals and the principles are still there.
Speaker 3: And to be fair, I'll say that every you know,
Speaker 3: I used to say every year or two. At this point,
Speaker 3: every three or six months or so, I kind of
Speaker 3: sit back and I say, has anything fundamentally changed? Is
Speaker 3: something that used to be important no longer important? And
Speaker 3: so far the answer is no. Right, we still need
Speaker 3: to have fast bills, we still need to have good tests,
Speaker 3: we still need to have good disaster recovery. We still
Speaker 3: want to, you know, think about security. How that's implemented
Speaker 3: might look a little bit different. And again, right, it's
Speaker 3: at scale, and now we have AI not only are
Speaker 3: things happening faster, they're happening larger, right, like our dicks
Speaker 3: are much much bigger. So how do we think about
Speaker 3: approaching that? So I think, you know, like I said,
Speaker 3: on the one hand, it hasn't changed at all because
Speaker 3: the fundamentals are there. And on the other hand, it's
Speaker 3: very much changed because we're kind of dealing with different
Speaker 3: technologies and new technologies and again different scale and size
Speaker 3: and reliability and security. I mean, yeah, the world has changed.
Speaker 2: Yeah, yeah, without a doubt. And then yeah, I just
Speaker 2: think about you talked about the repository of prompts, Carl,
Speaker 2: and oh, yeah, like the prompts are becoming code.
Speaker 1: Yeah, that's right. They're becoming sort of the lingua franca
Speaker 1: of you know, instead of I can imagine like a
Speaker 1: sub stack where you're you know, publishing prompts, yeah, or publishing.
Speaker 3: So a colleague of mine at MSR ben Zorn, has
Speaker 3: been working on a project around you know, how prompts
Speaker 3: are code and you need to be thinking about saving
Speaker 3: them and versioning them because also as our models change,
Speaker 3: different prompts will be differently effective, right.
Speaker 2: Yeah, yeah, they won't be. It's actually from a historical purpose.
Speaker 2: Interesting if they take this prompt and just run it
Speaker 2: on all these different models and see how they're evolving too.
Speaker 2: People keep telling me the new models are better, and
Speaker 2: I keep asking them, how do you know? Well?
Speaker 3: And also define better? Yeah, it's like define quality exactly,
Speaker 3: so many different ways to think about it and define it.
Speaker 1: And everything getting a little meta. You know, it probably
Speaker 1: won't be long. Probably doing it now, you know, people
Speaker 1: asking their AI to help them with their prompts for
Speaker 1: other AI.
Speaker 3: Oh, it's happening, Yeah, it's happening.
Speaker 1: Yeah, Like, what would the best prompt be for you
Speaker 1: to have this outcome?
Speaker 3: And then well, especially an agentic right, because sometimes a
Speaker 3: role is to execute something, but a role can also
Speaker 3: be to write and craft and tune the prompt right.
Speaker 1: Yeah, So why didn't you give me that in the
Speaker 1: first place? You didn't ask?
Speaker 2: Yeah, yeah, yeah, we're talking about this like rapid iteration.
Speaker 2: It's going to be the iterating of prompts as much
Speaker 2: a it's going to be the iterating of any given
Speaker 2: piece of code. Yeah, and how that stuff ultimately gets generated.
Speaker 3: Well, and then I think also not just iterating on
Speaker 3: the prompts, but understanding and tracking the quality of cops. Right,
Speaker 3: what does testing look like across different props, across different models?
Speaker 2: Sure? Yeah, well let software behave the way the customers back. Yep.
Speaker 2: That is a very broad principle. There's just a lot
Speaker 2: of ways to get to that point that had come
Speaker 2: close to a yes or with some degree of certainty,
Speaker 2: just like my software is secure to some degree of certainty.
Speaker 2: Does is this ux coherent? I mean, we usually don't
Speaker 2: directly articulate those sentiments. We work towards them, but now
Speaker 2: with prompt behavior, I think we tend to say them
Speaker 2: out loud now because we have to feed them to
Speaker 2: the machine. Yeah, to get it to start moving down
Speaker 2: that path.
Speaker 1: I had my first experience today with agent mode in
Speaker 1: the Evisual studio.
Speaker 2: Yeah, you've been busy, Not really.
Speaker 1: I just took it for a spin and I asked
Speaker 1: to do things that I knew how to do, and
Speaker 1: it did them, except it got hung up on one
Speaker 1: little thing. Okay, So here's the thing. Blazer has these
Speaker 1: edit forms and there's an input text that subclasses the
Speaker 1: HTML input so it can support validation rules and things
Speaker 1: like that. And I asked it to make a form
Speaker 1: and it did, And then I said Okay, I want
Speaker 1: you to do the validation on every keystroke. And when
Speaker 1: you do that with an input tag, you use the
Speaker 1: event on input right to handle the binding the bind event.
Speaker 1: But you can't do that with an input text. It
Speaker 1: doesn't support that out of the box. But the agent
Speaker 1: didn't know that, and so it tried twice and I said, no,
Speaker 1: that didn't work.
Speaker 2: You're going to have to subclass that control. And it
Speaker 2: did well.
Speaker 1: I was the one that knew what it should do,
Speaker 1: and it actually did it in a way that's different
Speaker 1: than I'd done it. So I actually learned something and
Speaker 1: it worked, and it worked.
Speaker 2: But you still had to give it the hints. You
Speaker 2: still had to tell it. Just speak to the role
Speaker 2: and expertise in all of this though, absolutely, yeah, yeah,
Speaker 2: that's why I told the story. Yeah, no, I appreciate that.
Speaker 2: And at the same time, it's like, it's not enough
Speaker 2: to write the prompt, it's also to evaluate the results.
Speaker 3: Absolutely, you know, is.
Speaker 2: This good enough? Should it be better? Like you'd almost
Speaker 2: have a default that says you should improve that, just
Speaker 2: to see if it does well.
Speaker 3: And you know, it's interesting because now when you write code,
Speaker 3: you write generate code and review the code as you go,
Speaker 3: So we're sort of introducing another early layer of review
Speaker 3: code review.
Speaker 2: Yeah.
Speaker 1: Yeah, especially when you tell your agent to handle this
Speaker 1: handle this issue on your Kidhub repo, for example, and
Speaker 1: it creates a full request and documents it.
Speaker 2: Yeah, better than you. Better than you would.
Speaker 3: Have that, right, especially documents.
Speaker 1: But you know you're doing a code review of the
Speaker 1: agent and you have to figure it out. You're the
Speaker 1: one that approves it ultimately.
Speaker 3: Yeah, it's going to give us some really good questions
Speaker 3: to think about because as we are evaluating, you know, reviewing,
Speaker 3: validating code and pull requests that are entirely generated from
Speaker 3: someone else something else, right, we need to have a
Speaker 3: good mental model of the code base and the architecture
Speaker 3: in our head to understand how it fits in with
Speaker 3: how it interacts everything else like that, and moving forward.
Speaker 3: I think that's going to be a really interesting question
Speaker 3: and challenge because now none of my code is operating
Speaker 3: production right now, but it used to, and I know
Speaker 3: that that's how I built up my mental model, and
Speaker 3: I kind of like feel of the system was doing
Speaker 3: that coding and writing that code, and you know, running
Speaker 3: these tests, and it'll be really interesting to see how
Speaker 3: we can help support the building of mental models, the
Speaker 3: evolution of mental models of how the back end code
Speaker 3: base works because agents can and then agents will probably
Speaker 3: also you know, evolve to be able to handle more
Speaker 3: of that. But at the end of the day, you know,
Speaker 3: developers are still deciding and approving and orchestrating all of
Speaker 3: these systems.
Speaker 2: Yeah. Yeah, absolutely so.
Speaker 3: Sorry that was real meta.
Speaker 1: Yeah, but we can also end that with for now
Speaker 1: right for now.
Speaker 3: Wow, someone tried telling me something was going to It's
Speaker 3: just impossible, and I'm like, m is it though? Things
Speaker 3: are moving way too fast right now to say anything
Speaker 3: definitively Yeah.
Speaker 2: Yeah, And then at the same time with like, I
Speaker 2: don't think the innovation is particularly wildly new. It's not exponential,
Speaker 2: but we're very much in an engineering cycle where we're
Speaker 2: finding ways to slip these new tools in and starting
Speaker 2: to think about how they fit together and what they
Speaker 2: could do for us. And it does feel like we're
Speaker 2: really changing the development workflow, even though the principles are
Speaker 2: still the same. Yep. We're still trying to deliver value
Speaker 2: to customers and trying toterate quickly get those those features
Speaker 2: out as soon as possible. Take feedback from their use
Speaker 2: and shape the next versions something I guess it's an
Speaker 2: area I haven't explored much yet.
Speaker 3: Well, and version code. You know, before it was versioning
Speaker 3: code and understanding tests and you know, building out the
Speaker 3: build graph. Well, now when lms are at the heart
Speaker 3: of a lot of work, now we need to be
Speaker 3: thinking about data and data versioning and model and model versioning,
Speaker 3: and so you know.
Speaker 2: It'sa do you know they're getting better when you make
Speaker 2: the new version?
Speaker 3: Yep, exactly, And then how would you roll back or
Speaker 3: shift to a model or a model version or to
Speaker 3: a to a different data set, right, And so, I
Speaker 3: you know, that's another thing that I think comes to
Speaker 3: mind to some folks are like, well, you know, we
Speaker 3: won't need developers anymore, there's no junior devs. And I'm like, no,
Speaker 3: we're creating an entirely new class of development. That's important.
Speaker 3: If we think about the earliest days of you know,
Speaker 3: before it was DevOps, we didn't really have infrastructure teams
Speaker 3: the way we do now, and they weren't we didn't
Speaker 3: understand the whole industry, didn't understand how important it was
Speaker 3: from a leverage standpoint, just like right now, right for
Speaker 3: mL developers out there. You know, it's been kind of
Speaker 3: a challenge. And now that skill set is super important,
Speaker 3: and that skill set you know, plus plus plus plus plus.
Speaker 2: Sure, well, and there isn't I don't feel like there's
Speaker 2: consistent patterns to making of those things right now. It's
Speaker 2: very wild westy.
Speaker 3: Oh, because we're all still figuring it out.
Speaker 2: Yeah right, and so we don't. I really haven't seen
Speaker 2: a set of practices that make me feel like that's
Speaker 2: a way that's going to be successful. These new tools
Speaker 2: every day, and they're you know, moving the goalposts all
Speaker 2: the time, so it's hard to try and come up
Speaker 2: with a set of practices that are really going to
Speaker 2: be consistent.
Speaker 3: This is a fun time to be in tech.
Speaker 2: Oh yeah, well, I'm kind of excited for a junior
Speaker 2: to imagine a junior developer just coming up now where
Speaker 2: you're always going to have a prompt like, how much
Speaker 2: of our time is now scraping off the craft of
Speaker 2: our old coding practices because we have all these new
Speaker 2: possibilities in front of us, right well.
Speaker 3: And how much time can you save by chasing down
Speaker 3: a problem that's just kind of silly and nonsense. I
Speaker 3: was right, Well, you know, TPD on this term. You know,
Speaker 3: some people love it, some hate it. It's vibe coding
Speaker 3: the other day and writing up I know, right, I
Speaker 3: don't know if you've heard it's vibe coding thing or
Speaker 3: you know, I was just yollowing it.
Speaker 1: Is vibe coding a pejorative to you.
Speaker 3: I think it is to some people. I joke when
Speaker 3: I chat with my team, I tell I'm just yellowing it, right, Yeah,
Speaker 3: I mean I still check the code sometimes. Every once
Speaker 3: in a while, I've done something just to see how
Speaker 3: far it can go. And I've been like, I've set
Speaker 3: up a condition where I'm not allowed to change the code.
Speaker 3: If I were someone who didn't understand any of this
Speaker 3: and I only had the prompt, what would I do?
Speaker 2: Anyway?
Speaker 3: I was, Yeah, I was working on this thing and
Speaker 3: it kept breaking, and I was like, okay, well i'll
Speaker 3: i'll you know, relax that constrain. I'll go figure it out. Listen.
Speaker 3: I spent a couple hours like going through every forum
Speaker 3: and googling everything I could, and finally I was like,
Speaker 3: this is dumb. Please fix What does this error message mean?
Speaker 3: Please fix it for me? And I think probably because
Speaker 3: I've done this before, I will ask it first because
Speaker 3: it like loads into context what it needs to know.
Speaker 3: And then fris that Listen, that was fixed in thirty seconds,
Speaker 3: and it was it was an obscure configure error that
Speaker 3: like I wouldn't have found for another couple hours. And
Speaker 3: as a junior dev, those were the types of things
Speaker 3: that I hit, especially my first six months or a year.
Speaker 2: Yeah, right, that were just showstoppers.
Speaker 3: And to understand this, yeah, it would take hours because
Speaker 3: I didn't want to ask someone or I would and
Speaker 3: then like and then I'm interrupting someone. I think this
Speaker 3: is one of the great unlocks where junior developers are
Speaker 3: going to be so productive. I'm super impactful, and honestly,
Speaker 3: I was a professor for years, you know, Richard, Sometimes
Speaker 3: junior folks have the best ideas because they aren't they're
Speaker 3: not constrained, they're not hardened by all of the broken.
Speaker 2: Deaths stuff that we've been doing.
Speaker 3: They don't have the scars, and so now they can
Speaker 3: actually surface these ideas in like very visible productive ways.
Speaker 2: This is what I'm thinking, is that junior is going
Speaker 2: to come up whose reflexes to prompt again, Yeah, that
Speaker 2: reflex we don't have yet. And things in those terms.
Speaker 2: How do I deal with this from a prompt perspective
Speaker 2: rather than our visceral reaction would be get under the hood.
Speaker 2: Look at the code I've changed?
Speaker 3: Well, both and both right, because sometimes we need to
Speaker 3: tell it. You have to break down a problem a
Speaker 3: couple of times.
Speaker 2: So I think, just like you said, you need to
Speaker 2: subclass that.
Speaker 1: Yeah, well yeah, I think imprompts now all the time.
Speaker 1: If I'm spending more than you know, thirty seconds scratching
Speaker 1: my head about something, it goes right into an agent
Speaker 1: or a chat, GPT or something. Take a screenshot. What
Speaker 1: does this mean? If I don't know?
Speaker 2: Yeah, you know?
Speaker 1: Yeah, Well it's time to take a break. We'll be
Speaker 1: right back after these very very important messages don't go away.
Speaker 1: Did you know? You can easily migrate asp net web
Speaker 1: apps to Windows containers on Aws. Use the app to
Speaker 1: container tool to containerize your IIS websites and deploy to
Speaker 1: AWS Managed Container service is with or without Kubernetes. Find
Speaker 1: out more about app to container at AWS dot Amazon
Speaker 1: dot Com, slash, dot net, slash modernize, and we're back.
Speaker 1: It's dot in a rocks. I'm Carl Franklin as Richard Campbell,
Speaker 1: either and we are talking about AI with Nicole, and
Speaker 1: we're talking about DevOps in AI. We started on the
Speaker 1: DevOps thing got sidetracked into AI. But how does how
Speaker 1: do AI tools make their way into the DevOps architecture infrastructure?
Speaker 3: I love this question right in part because I think
Speaker 3: it's something we're still discovering, like we were kind of,
Speaker 3: you know, chatting about, and also I think it's important
Speaker 3: because it's something that is not on everyone's radar right
Speaker 3: right now, everyone is super excited about Copilot and you know,
Speaker 3: all of these tools that you can use to write code.
Speaker 2: Yeah, this is on.
Speaker 3: The ninety and you know we all know this because
Speaker 3: we're developers or you know, we're developers. In my case,
Speaker 3: there's a lot more to software engineering and building great
Speaker 3: product and building great systems than just writing code. There's
Speaker 3: this review, there's pr there's integration, there's release, there's so
Speaker 3: many things, and so I think there's just a world
Speaker 3: of possibility for AI and AI agents to be able
Speaker 3: to help out. Now that also comes with you know,
Speaker 3: but wait, right, what do we think about hallucinations or
Speaker 3: correctness or all of these other things, which also introduces sorry,
Speaker 3: I'm gonna harp on this because I have heard too
Speaker 3: many people say that the junior dev is dead. We've
Speaker 3: now created and introduced entirely new skill sets, right, how
Speaker 3: do we validate this? What does testing look like across
Speaker 3: all these different stages for non deterministic systems, you.
Speaker 1: Almost have to test a junior developer's creativity and their imagination, because,
Speaker 1: let's face it, that's what's holding the old guys back.
Speaker 3: I woul gonna say, I think juniors are some of
Speaker 3: the best equipped here because now seniors will have some
Speaker 3: great experience in architectural design limitations and trade offs involved,
Speaker 3: but also we're just so ingrained in the way things
Speaker 3: work and the way things look and how to build
Speaker 3: a thing and not okay, what if we flipped the
Speaker 3: entire thing on its side differently exactly?
Speaker 2: Well, and then we're also at a time where nobody
Speaker 2: has a decade of experience with all alabas. Right, that's right,
Speaker 2: we're all juniors effectively. Yeah, this is a question of
Speaker 2: how much bag did you bring to the table. But
Speaker 2: at the same time, you know, hopefully you've gone through
Speaker 2: a few iterations like this over the years, you have
Speaker 2: a bunch of sort of standards that you go by
Speaker 2: about quality and approaches to things so forth that are
Speaker 2: beyond any given tool. Yeah, it helps me. I want
Speaker 2: to jump back onto the frictionalist side of things because
Speaker 2: I think we've focused too many on the tools and
Speaker 2: not enough on the culture.
Speaker 3: Absolutely right. So as we you know, Auby and I
Speaker 3: have been going through the book, there a not insignificant
Speaker 3: part of the book that isn't about tools at all, frankly, right,
Speaker 3: It's about understanding what devex is and why we need
Speaker 3: to remove friction and communicating that to others in the company.
Speaker 3: Whether that's you know, making the business case you can
Speaker 3: kick something off, or whether it's once you're starting to
Speaker 3: deploy a technical solution or something. Right that frankly needs
Speaker 3: a COMMS plan because internally we need to communicate to
Speaker 3: several audiences. We need to identifiers stakeholders. We need to
Speaker 3: tell developers why it's valuable and why they should use it.
Speaker 3: We need to tell engineering managers why it's valuable and
Speaker 3: why they should care about it. We need to be
Speaker 3: telling executives and leaders across various disciplines, you know, our
Speaker 3: CIOs and our CTOs, but also HR and finance why
Speaker 3: this is important what they should care about and all
Speaker 3: of those messages are going to be different, and how
Speaker 3: do we remove blockers and barriers, and how do we
Speaker 3: reduce whendn't they remove fear because a lot is changing, right,
Speaker 3: and so I think, you know, the cultural and the
Speaker 3: people in the communication part is is huge. And also process, right,
Speaker 3: we say.
Speaker 2: That's the old DEVO process tools.
Speaker 3: Absolutely, you know, yeah, exactly, well, and we were chatting
Speaker 3: with some of our earliest you know, reviewers and interviewers,
Speaker 3: and you know, the point kept raising up that sometimes
Speaker 3: the best DEVX change you can make is to a process. Right,
Speaker 3: Sometimes you can just clean up a process and it's
Speaker 3: a huge significant impact across an entire organization. Tools weren't involved,
Speaker 3: or maybe like tools were minimally involved.
Speaker 2: They weren't the deciding factor.
Speaker 3: Yep, exactly.
Speaker 2: Yeah.
Speaker 3: And then we also go through, you know, how to
Speaker 3: collect early data, how to more rigortory collect data so
Speaker 3: that you can get good signal into what's happening to
Speaker 3: make you know, decisions for maybe some of the obvious
Speaker 3: problems and then communicate those across. But then also how
Speaker 3: to prioritize and choose next projects as you continue on this.
Speaker 2: Journey yeah, the feedback side. Yeah, exactly, the cycle. And
Speaker 2: I wonder if jenerative AI is going to pay more
Speaker 2: of a role in that, doing a better job of
Speaker 2: trying to pull the signal out of the noise of
Speaker 2: telemetry to let us to let us see people are
Speaker 2: struggling with the app this way, or you know, these
Speaker 2: features aren't being utilized, Like all of that data is
Speaker 2: in the telemetry, but it sometimes it's really hard to see.
Speaker 1: Yeah.
Speaker 3: Well, and I will say frankly, there are a lot
Speaker 3: of times where the data doesn't exist, right, and so
Speaker 3: I have Yeah, and so I think this, you know,
Speaker 3: this DEVS journey or the journey to improve developer experience
Speaker 3: right includes both identifying friction points and improving them and
Speaker 3: also identifying where you have gaps in the data what
Speaker 3: you can do in the interim until you have something
Speaker 3: instrumenttic because by the way, don't start or don't wait
Speaker 3: to start until you've instrumented your entire stack, because that's
Speaker 3: never happening. Part of it is not just using AI
Speaker 3: to kind of evaluate the telemetry, but it's also understanding
Speaker 3: what data and what telemetry we need. Right, many times
Speaker 3: we have gaps in our data, and so it's part
Speaker 3: improving tools and process and communicating and culture, and sometimes
Speaker 3: it's prioritizing investments in instrumenting systems. Right, so what does
Speaker 3: that look like? I will say one area that I
Speaker 3: think AI can make a huge impact it already is
Speaker 3: is you know what I just talked about. We need
Speaker 3: to communicate to different stakeholders. Right now, we can pull
Speaker 3: together a bunch of data. I can have a very
Speaker 3: rough list of bullet points and findings, and I can say,
Speaker 3: help me rewrite that.
Speaker 2: Can you tune this for the C suite?
Speaker 3: Tune this for the C suite?
Speaker 2: Right?
Speaker 3: Also, you know we know ask it politely. This is
Speaker 3: what I want you to do. Can you please help
Speaker 3: me write it this way?
Speaker 1: Okay?
Speaker 3: Now write it for engineering managers? What am I missing
Speaker 3: if I'm writing this for HR? Can you help me
Speaker 3: generate a list of you know, starter questions for conversation
Speaker 3: in a workshop I'm going to run. That has gotten
Speaker 3: so much faster.
Speaker 2: That's really interesting, you know, I love it. I did
Speaker 2: very well as a product manager going through the logs
Speaker 2: and writing up a post factor report and a version
Speaker 2: like two weeks after a going through to see if
Speaker 2: we worry about to tip over and when we weren't
Speaker 2: just saying, hey, here's how a bouch of new features
Speaker 2: being used and things like that, Like it made a
Speaker 2: lot of people happy. What it didn't have was time
Speaker 2: to write it for all of those audiences. Yep, that's
Speaker 2: something in LLM is genuinely good, at at.
Speaker 3: Least for a first draft, right, because then you can
Speaker 3: go through and you can check a couple of things.
Speaker 3: But I don't know about you. I am faster at
Speaker 3: editing than I am writing totally, and so if I
Speaker 3: can give it a bunch of information, a few cues on,
Speaker 3: you know, this leader really cares about these one or
Speaker 3: two things. How can we frame it this way? It
Speaker 3: you know, I'll change a couple of sentences, I'll add
Speaker 3: a couple data points. But it's so much faster.
Speaker 2: Yeah.
Speaker 1: Do you see there's a place in the DevOps tool
Speaker 1: stack for agents, for ani agents to actually you know,
Speaker 1: do things of their own volition with your various resources,
Speaker 1: even if it's notifying you or sending communications to stakeholders
Speaker 1: or you know, do you see that there's a place
Speaker 1: in the tool chain for that.
Speaker 3: I think there will be a place. I think it's
Speaker 3: still you know, so early and you know, a gentic
Speaker 3: development and use that. Like, we're still kind of seeing
Speaker 3: where to best deploy them, how to best use them.
Speaker 3: What does what does autonomous mean?
Speaker 1: Right?
Speaker 2: How autonomous is autonomous exactly?
Speaker 1: Well, you know, you you develop a prompt for your
Speaker 1: agent to say, you know, I'm not I don't even know.
Speaker 1: I'm just thinking. Well, so for example, you can tell
Speaker 1: it how to behave when a certain something arises, and
Speaker 1: it does.
Speaker 3: Sure, but as an example, and I'm just going to
Speaker 3: use the reporting one because sure, I think it's one
Speaker 3: that's going to be obvious to everyone. I can have
Speaker 3: a whole bunch of data come in, I can have
Speaker 3: it generate a draft of report for everyone. The reports
Speaker 3: could be perfect. I personally would never have an agent
Speaker 3: automatically send the executive report to the CEO on the board.
Speaker 3: That's not a risk right now.
Speaker 1: To some of our get up pull request model, right.
Speaker 1: You know, it sends it to you. You can send
Speaker 1: it on after an edit or two or whatever.
Speaker 3: But I also might have it go ahead and send
Speaker 3: it automatically to all of the developers because they may
Speaker 3: be expecting it on a monthly or a quarterly cadence. Now,
Speaker 3: executives might be expecting it on a six month cadence,
Speaker 3: but if I know they're in an off site or
Speaker 3: something just blew up, I'm not sending it that day.
Speaker 3: I will go ahead and wait forty eight hours, and
Speaker 3: I want it to come from me, right, I mean, yes,
Speaker 3: I know we can configure things so that it looks
Speaker 3: like it comes from someone, but that's you know, I
Speaker 3: do think there are cases where we're going to start
Speaker 3: feeling out what that looks like.
Speaker 2: Right, I'm pretty comfortable idea that we're going to want
Speaker 2: entities for each of these bits and software. So it's
Speaker 2: very clear that this was generated by an LM's analysis,
Speaker 2: and oh.
Speaker 3: My gosh, yes, please. You know, there's also a big
Speaker 3: open question around how do we evaluate and think about
Speaker 3: the downstream outcomes of code, because if we think about it,
Speaker 3: very few systems currently have let's say key logger level
Speaker 3: tracking or per character tracking, and so you know, right now,
Speaker 3: the question is often did you use AI or did
Speaker 3: you not use AI? That is such a yeah exactly
Speaker 3: grammar check or qualifying right, or like did I use
Speaker 3: AI and it like helped kickstart my brain and then
Speaker 3: I deleted everything it suggested except for like some set
Speaker 3: up comment something.
Speaker 2: Right stimulated an I and you ran with the idea.
Speaker 3: But then like downstream, which portions of the code perform well,
Speaker 3: Which portions of the code are more readable and so
Speaker 3: they do well in code review, Which portions of the
Speaker 3: code are challenging in build or integration, Which portions of
Speaker 3: the code have long term viability and success in production?
Speaker 3: And right now we just I'll say, we generally just
Speaker 3: don't have that level of granularity again, introduce new opportunities.
Speaker 2: Memory for me of what code reviews well versus what
Speaker 2: performs well, because I've done a lot of web performance
Speaker 2: optimization over the years that always reviewed poorly because it's
Speaker 2: on obvious code and looking at it and going why
Speaker 2: are you doing this? It's like because in a multi
Speaker 2: re entry, high velocity environment, this code is safe even
Speaker 2: though it's obtuse.
Speaker 3: Right exactly well? And then there's even i think really
Speaker 3: interesting open questions. Sorry, this is like researcher hat. We
Speaker 3: know that many times reviewers will react differently to code
Speaker 3: written by different people. Sure it's a junior reviewer, it's
Speaker 3: someone on another team, it's someone who probably isn't familiar
Speaker 3: with your codebase, or you think is not familiar with
Speaker 3: your code base. How are going to how are people
Speaker 3: going to react differently to code that is entirely written
Speaker 3: by AI? What conventions can we use so that it's
Speaker 3: more readable, so it's no more understandable, so it's more trustable?
Speaker 3: And in which case you know, like in your example,
Speaker 3: does it just need to be hard to understand? But
Speaker 3: it's okay because we know that that's what's happening.
Speaker 2: Yeah, and I used to write those comic blocks off.
Speaker 2: This is this code look stupid to you. Don't touch it.
Speaker 2: It is a hard, one fought over piece of code
Speaker 2: for a very difficult problem. Yes, I wish it would
Speaker 2: be simpler, but it cannot be.
Speaker 1: Just to get back to the term AI and what
Speaker 1: does that mean? We go through these cycles where the
Speaker 1: public blombs onto words that they think means something and
Speaker 1: that means something else. Like your clock radio now has
Speaker 1: artificial intelligence.
Speaker 3: Right, It's like, I mean, if you put that sticker
Speaker 3: on the box, it's going to sell the more money.
Speaker 2: Yeah, of course, but I'm sorry clock radio, clock radio.
Speaker 1: Algorithm sort of thing, right, Yeah, oh that was an
Speaker 1: algorithm that did that.
Speaker 2: What does that mean?
Speaker 1: Or let's go to the world of food. Enzymes is
Speaker 1: a great one, and enzymes a protein, but it sounds
Speaker 1: like it's doing something you know, enzyme. Well, there is
Speaker 1: an enzymatic act. Okay, yeah, okay, but but you know, yeah,
Speaker 1: people just throw these terms around.
Speaker 2: Well, I've certainly been big on the fact that our
Speaker 2: official intelligence a term coined for raising money. It was
Speaker 2: a marketing strategy that then got hijacked by science fiction,
Speaker 2: and so of course everybody has a bad perception of it.
Speaker 2: We've had sixty years of abusing that term.
Speaker 3: And it very legitimately means several different things.
Speaker 2: Yeah.
Speaker 3: Sure, given the context, given the discipline, given the background,
Speaker 3: it's a blacking technology. They're all AI. And also depending
Speaker 3: on what your assumption is, it's definitely not AI.
Speaker 2: Well, I've always said if you still call it a
Speaker 2: dais because it doesn't work. As soon as it does work,
Speaker 2: it gets a new name. It becomes image recognition or
Speaker 2: you know, sentiment analysis or large language model. But if
Speaker 2: you only can call it AI, it's because you haven't
Speaker 2: figured it out yet.
Speaker 3: Yeah, I think it's also Yeah, I mean sometimes it's
Speaker 3: also the underlying technology, right, Like we've had AI for
Speaker 3: years and it's one thing. Now, lllms use a different
Speaker 3: type of math.
Speaker 2: Yeah, there's always been that schism between the decision tree
Speaker 2: systems and the neural net systems, the neats and the scruppies. Yep,
Speaker 2: going back to Minski terms, which is really old school,
Speaker 2: so fun. Even when you actually are talking about the
Speaker 2: technological side of this, there's been two totally different sets
Speaker 2: of philosophies. Yeah, but then throw hal and Ultron on
Speaker 2: the top of that, and no wonder people are confused always. Yeah,
Speaker 2: I appreciate it though, but I also appreciate that we're thinking,
Speaker 2: in the terms with all of these technologies about the
Speaker 2: development experience could be better from this Not only could.
Speaker 3: Be, but I think it now. I've always said it
Speaker 3: needs to be, But now with a lot of teams
Speaker 3: and organizations that I talk to, we're really saying that
Speaker 3: where a subpar I won't even say bad, a subpar
Speaker 3: developer experience, the wheels are falling off. Yeah, things are
Speaker 3: just breaking because now we're trying to move so fast
Speaker 3: and generate so much, and so what does that mean
Speaker 3: for everything downstream? We have to figure out how to
Speaker 3: review it, we have to figure out how to test it,
Speaker 3: We have to figure out how to do building integration.
Speaker 3: We have to figure out how to release these huge
Speaker 3: amounts of code in compressed timeframes. And so you know, Richard,
Speaker 3: you know we've been saying for a while that, you know,
Speaker 3: DevOps or whatever you want to call it, Yeah, is
Speaker 3: table stakes. Oh listen, it's the bar is.
Speaker 2: There's a whole set of conversations you didn't get to
Speaker 2: have if you haven't figured this part out yet.
Speaker 3: And now for teams that have been organizations who have
Speaker 3: been winging it well enough, they are no longer. Yeah,
Speaker 3: we're going to see a lot of sprinting and burnout
Speaker 3: and or hopefully right improved systems that improve devs well.
Speaker 2: And recent convinced that software was eating the world. And
Speaker 2: now you know your your companies are more and more
Speaker 2: dependent on it. If you haven't solved these problems, you're
Speaker 2: not going to be able to build the software.
Speaker 1: Or you will.
Speaker 3: But now that things are moving so incredibly fast, you
Speaker 3: won't be able to keep up, right. I mean, it's
Speaker 3: always been a challenge of competitive advantage and who can
Speaker 3: build faster, And before it was maybe a difference of
Speaker 3: like six months and nine months or one year and
Speaker 3: one year and a half, which like isn't great but
Speaker 3: kind of fine. Well, now it's like weeks and if
Speaker 3: you're pulling in at a year plus for you know,
Speaker 3: a solid feature set or new product or something, and
Speaker 3: all of your competitors and brand new competitors because the
Speaker 3: industry is just yeah, it's like a bunch of weeds.
Speaker 3: Everyone's popping up everywhere. If they're coming out with something
Speaker 3: in six to eight weeks with a really solid tech
Speaker 3: preview or beta.
Speaker 1: Yeah, your toast.
Speaker 2: Yeah, you have troubles. I remember they accelerate. You were
Speaker 2: talking about the fact that version over a version you
Speaker 2: should be getting faster, but you found a lot of
Speaker 2: organizations at version over version were actually getting slower. Like
Speaker 2: you get mired in the croft and can't ship.
Speaker 3: The next version exactly, or you know sometimes the reflexes
Speaker 3: we shipped and we had some outages. So now what
Speaker 3: we're going to do is we're going to slow down
Speaker 3: and we're going to do a more thorough review, which
Speaker 3: then means you have even more code to try to
Speaker 3: push and integrate into PROD, which you know now you've
Speaker 3: just had a huge blast radius. Yeah, so you have
Speaker 3: more outages and then sometimes the reflex is then to
Speaker 3: have a code freeze or wait longer and go even slower.
Speaker 2: Yeah. Those are anti patterns. Yeah, the opposite of limitless.
Speaker 2: It's very limited.
Speaker 3: Yes, and it's fairly predictable. We see it very very often. Now,
Speaker 3: for any you know, haters who are listening, we are
Speaker 3: not saying to just go as fast as possible, throw
Speaker 3: everything at the wall and run. No, that's also not good, right.
Speaker 3: We're definitely saying that we need the automated processes and
Speaker 3: tools in place to ensure that your code is safe, secure, reliable,
Speaker 3: performance correct. But without those things, without the automation in particular, Yeah,
Speaker 3: it's real tough.
Speaker 2: But the automation can't come first. You're still in this
Speaker 2: place of can we evaluate well enough to know this
Speaker 2: is where the bottom lick is and then try and
Speaker 2: solve the bottleneck exactly? Yeah, and that then maybe tool
Speaker 2: makes sense there, but only because you want to solve
Speaker 2: the problem. Yeah.
Speaker 3: And you know something I learned kind of early on
Speaker 3: in my career, or someone said this to me. I
Speaker 3: wish I remembered who. But we can't automate something until
Speaker 3: we understand it. Sure, there really is value in doing
Speaker 3: something manually. A handful of times. Yeah, so we understand
Speaker 3: it and then we can automate it. Because if we
Speaker 3: automate too fast, all we've done is sped up something
Speaker 3: that is likely wrong or incomplete.
Speaker 2: Right, But now it goes quickly.
Speaker 3: Yeah, but now go exactly.
Speaker 2: You applified stupidity instead of intelligence. Now it's faster.
Speaker 3: Well it can congratulations.
Speaker 1: It could have been too slow, but the fact that
Speaker 1: you're automating it, you won't notice that because hey, I'm
Speaker 1: not doing it, so it's faster.
Speaker 2: Than me doing it. Yeah, doing dumb faster.
Speaker 3: Yeah, but the solution is not to continue doing it
Speaker 3: manually forever.
Speaker 2: No, right, yeah, just because you do it dumb slow
Speaker 2: doesn't mean it's better. Right. But this is the consulting effect. Right.
Speaker 2: I never got hired to re engineer a business process.
Speaker 2: I got hired to automate. And my process of scrutinizing
Speaker 2: the workflow to make the automation re engineered the process.
Speaker 2: Like the two kind of go together that you have
Speaker 2: to you have to do what's acceptable to people as
Speaker 2: well to say I'm here to you know, make things better,
Speaker 2: make things better, and automation is safe. They're comfortable with that.
Speaker 2: But then in order to automate, you have to work
Speaker 2: through the manual process and understand it. And because you're
Speaker 2: the outside of you also get a point to go.
Speaker 1: I mean you're like Colombo out to Oh yeah, you
Speaker 1: get just one more question about this process.
Speaker 2: It's kind of inefficient.
Speaker 1: Do you mind if I just take a look at that?
Speaker 2: It's a good Columbo, thank you, good Peter Fox there go.
Speaker 2: But yeah, when do we scrutinize? I mean, it doesn't
Speaker 2: have to be an external like I definitely seen folks
Speaker 2: who've embarked on that sort of DevOps mindset where they
Speaker 2: just start talking to more people and they ask a
Speaker 2: lot of whys and often run into it's the way
Speaker 2: we've always done it right, So yeah, you know, we
Speaker 2: believe that that was necessary.
Speaker 3: Ye change, and we're seeing a lot of that now. Yeah,
Speaker 3: because everything's changing and we need to rethink or at
Speaker 3: least revisit how our systems are working.
Speaker 2: Yeah, you think we would do that routinely, but we
Speaker 2: don't because there's so many other things to do. Anyway,
Speaker 2: that idea of just taking the step back and looking
Speaker 2: through the processes again and say is this the right process?
Speaker 3: Well, and it's really hard to articulate the importance or
Speaker 3: the value of cleaning up systems and clearing up tech dead.
Speaker 2: Sure, it's better if you.
Speaker 3: Can talk about and tie it to outcomes. You know,
Speaker 3: we need to make sure that we can improve the
Speaker 3: consistency and the predictability and the reliability of the software,
Speaker 3: and so we yeah, we carve out a portion of
Speaker 3: our time to ensure that is happening right and over
Speaker 3: the past period of end months and years, we can
Speaker 3: show that these investments are paying off. And the times
Speaker 3: when we haven't because of whatever reason, you know, a
Speaker 3: race to push something, we tend to see these you know,
Speaker 3: negative outcomes. So like that can help, but it's it's
Speaker 3: tough to try to explain or you know, calculate an
Speaker 3: ROI for tech debt.
Speaker 2: That's not no, I mean I think a lot of
Speaker 2: us just included it as like a ten percent rate
Speaker 2: or something like that. You do want to knock it down, Oh, absolutely.
Speaker 2: Argument has always been if we don't do this eventually,
Speaker 2: we can't shift anything.
Speaker 3: Exactly.
Speaker 2: We have to do an all tech at all tech
Speaker 2: debt sprints are multiple where if we just stay on
Speaker 2: top of it so that we're diminishing it, there's less
Speaker 2: of it than there was the next time. We're better off.
Speaker 3: Now keeping that you know goal of ten percent is
Speaker 3: or so it's great. It's really challenging when I chat
Speaker 3: with teams who they're booked up, their capacities one hundred percent,
Speaker 3: they're fully utilized, and then things start breaking. Yeah, and
Speaker 3: it's because and it's not that the developers ever, you know,
Speaker 3: don't want I mean, tech det isn't super fun, but
Speaker 3: they understand, you know, when codebase is it. When it's
Speaker 3: really hard to make a change, that's not fun, right,
Speaker 3: But it's hard to explain why the way a finger quilt, right,
Speaker 3: the way we've been working for the last and years
Speaker 3: isn't going to work anymore because we were basically sprinting
Speaker 3: and now we have to do things to harden our
Speaker 3: systems or make them more scalable or more reliable or
Speaker 3: easier to change and understand.
Speaker 2: Yeah, it's a different cycle, yep. The difference between getting
Speaker 2: that initial version of the door improving initial value exactly
Speaker 2: what is sustainable value?
Speaker 3: Yeah, And you know, I'm going to pull us back
Speaker 3: to that AI thing. I think this is also where
Speaker 3: we're going to have some big questions come up because
Speaker 3: you know your point when it's just about getting the
Speaker 3: next version out of the door. Okay, right now, some
Speaker 3: companies are releasing new products or new significant features every month, right,
Speaker 3: So how can we be thinking about code hygiene and
Speaker 3: system automation and hygiene and improvement when we are constantly
Speaker 3: moving this fast?
Speaker 2: Yeah? Yeah, Well, and I would always look at the
Speaker 2: delta trajectories there it's like, are we still able to
Speaker 2: move every month? Or we shipping a little less each month?
Speaker 2: Like are we decaying or are we strengthening? Yeah? I
Speaker 2: picked that number ten percent a little bit arbitrary. Like
Speaker 2: what I'm really looking for is the total amount of
Speaker 2: tech debt less this sprint than last print. So if
Speaker 2: we're accumulating more from the new things we're shipping, we
Speaker 2: actually have to fix more too, yeap. Otherwise we're just
Speaker 2: delaying the inevitable.
Speaker 3: Now, I love that you pointed that out right, if
Speaker 3: we look at the things we're accumulating from shipping. One
Speaker 3: reason I'm super excited about how quickly we can develop
Speaker 3: things now is we can do a lot of experiments.
Speaker 3: So hopefully we are not in a world where every
Speaker 3: single thing we build gets shipped.
Speaker 2: Yeah, hopefully it should be way more comfortable thrown away
Speaker 2: code to it.
Speaker 3: At least fifty percent of the things that we try
Speaker 3: sure should fail, and it should be done so quickly
Speaker 3: that like the business doesn't really it's just almost consequence exactly. Yeah,
Speaker 3: because you know, definitely to your point, code that doesn't
Speaker 3: do much at least it doesn't hurt the system.
Speaker 2: Oh you have.
Speaker 3: Added to tech debt.
Speaker 2: Yeah, yeah, you've loaded down. But I now feel like
Speaker 2: we're going to make more branches to do experimental coding
Speaker 2: these new tools and then make an assessment and go, okay,
Speaker 2: we've made a learning Now dump the branch. Let's try
Speaker 2: again with what we've now learned to see what we're
Speaker 2: going to make from the end YEP, and in relatively
Speaker 2: short periods of time we could spit a lot more
Speaker 2: code out. Now. The real question is isn't good yeah?
Speaker 3: Or you know, even if it's not the best design code,
Speaker 3: is that the functionality is that, the user flow is
Speaker 3: that the.
Speaker 2: Did we get it into thing that we want some
Speaker 2: kind of value? I appreciate that.
Speaker 1: Yeah, I'm just looking forward to things that I was
Speaker 1: never looking forward to. Right, merge conflicts, I think those
Speaker 1: will get easier to deal with having you know, an
Speaker 1: AI in visual studio for example. You know, just some
Speaker 1: of those things that that are cringe worthy, like oh,
Speaker 1: I don't want to go down that rabbit hole, but
Speaker 1: then you know, what do you got to lose? It's
Speaker 1: all about the prompt baby. Oh.
Speaker 3: I'll say, in some ways, I think technically get easier,
Speaker 3: but I think personally it will be challenging because right
Speaker 3: now merch conflicts is a person making. Now many times
Speaker 3: the system suggests the right answer. But what happens when
Speaker 3: we have many, many more merch conflicts to evaluate? And
Speaker 3: now you know the things I was talking about before?
Speaker 3: Did it come from an agent? Did it come from
Speaker 3: a person?
Speaker 2: I know you have that issue list clicking fire to copilot,
Speaker 2: which one of them spins up a branch to build
Speaker 2: that thing and sends you a pr and ten of
Speaker 2: them come to roost. I hope you get some time. Yeah.
Speaker 3: Yeah, Now, I will say I keep identifying like open
Speaker 3: questions and hard problems. I hope people who maybe are
Speaker 3: less familiar with me and my work means that this
Speaker 3: is a lot of excitement. There are a lot of
Speaker 3: really cool things to figure out, and there are a
Speaker 3: lot of cool things that don't have established best practice.
Speaker 3: So for anyone who's in the field now, whether you're
Speaker 3: junior or a senior, there is so much to do.
Speaker 3: You're so much to do, and AI can't fix that,
Speaker 3: and they can't solve it because it's pretty good at
Speaker 3: responding to a prompt, it's not creative.
Speaker 1: But also these sort of meta prompts. You know, here's
Speaker 1: a big problem I want to solve. What are the steps?
Speaker 1: You don't have to do them for me, but what
Speaker 1: are the steps I need to go through in order
Speaker 1: to achieve this goal? You know, organizing your thoughts and
Speaker 1: breaking big problems down into smaller problems. It's really good
Speaker 1: for that. Oh, it's so good.
Speaker 2: Yeah.
Speaker 1: Yeah, And whether you use it all the way through,
Speaker 1: that's another thing. But at least getting started, things that
Speaker 1: seem insurmountable can be made easier. So what's next for you?
Speaker 1: What's in your inbod?
Speaker 2: When are we going to see this book?
Speaker 3: End of year?
Speaker 2: Hopefully? So right now I already came out.
Speaker 3: We're working on it, So continuing to work on the book,
Speaker 3: doing some really exciting work at Microsoft around AI and
Speaker 3: systems and how we can improve and you know, what
Speaker 3: that looks like. I still occasionally find some time to
Speaker 3: talk to folks across industry and I love to learn,
Speaker 3: you know, from them and their experiences. So yeah, still,
Speaker 3: you know, it feels like the earliest deep off days,
Speaker 3: where like we're kind of identifying and finding patterns and
Speaker 3: sharing best practices and you know, connecting dots and connecting teams.
Speaker 3: So it's super fun.
Speaker 2: Yeah, that's alazing times. So good to talk to you again,
Speaker 2: and Bill, thanks, good to talk to you.
Speaker 3: Thanks for having me.
Speaker 1: Yeah, thanks for coming back, and we'll talk to you
Speaker 1: next time on dot net rocks. Dot net Rocks is
Speaker 1: brought to you by Franklin's Net and produced by Pop Studios,
Speaker 1: a full service audio, video and post production facility located
Speaker 1: physically in New London, Connecticut, and of course in the
Speaker 1: cloud online at pwop dot com. Visit our website at
Speaker 1: d O T N E t R O c k
Speaker 1: S dot com for RSS feeds, downloads, mobile apps, comments,
Speaker 1: and access to the full archives going back to show
Speaker 1: number one, recorded in September two thousand and two. And
Speaker 1: make sure you check out our sponsors. They keep us
Speaker 1: in business. Now go write some code. See you next
Speaker 1: time you got jack middle vans
Speaker 3: And