1 00:00:01,000 --> 00:00:04,759 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05,320 --> 00:00:09,880 Become a patron For just five dollars a month you get access to a private 3 00:00:10,000 --> 00:00:14,359 RSS feed where all the shows have no ads. Twenty dollars a month will 4 00:00:14,400 --> 00:00:18,800 get you that and a special dot net Rocks patron mug. Sign up now 5 00:00:18,839 --> 00:00:23,679 at Patreon dot dot net rocks dot com. Hey Carlin Richard. Here. 6 00:00:24,000 --> 00:00:29,199 As you may have heard, NDC is back offering their incredible in person conferences 7 00:00:29,239 --> 00:00:33,119 around the world, and we'd like to tell you about them. NDC Oslow 8 00:00:33,159 --> 00:00:36,880 will be made twenty first through the twenty fifth. Go to NDC Oslo dot 9 00:00:36,920 --> 00:00:42,840 com to register. NDC Copenhagen is happening August twenty seventh through the thirty first. 10 00:00:42,880 --> 00:00:48,079 The early bird discount for NDC Copenhagen ends June second. Go to NDC 11 00:00:48,200 --> 00:00:54,200 Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the 12 00:00:54,240 --> 00:00:58,799 twentieth. The early bird discount for dc Porto ends July twenty first. Go 13 00:00:58,880 --> 00:01:03,439 to EDDC Porto dot calm to register and check out the full lineup of conferences 14 00:01:03,679 --> 00:01:22,239 at NDC Conferences dot com. Hey, guess what it's Dot and Net Rocks. 15 00:01:22,239 --> 00:01:26,840 I'm Carl Franklin and I'm Richard Campbell. And this is the beginning of 16 00:01:26,159 --> 00:01:33,040 a long run over a few days of show recordings that we have to get 17 00:01:33,040 --> 00:01:34,719 in the can because we're gonna be busy, we're gonna be traveling again, 18 00:01:34,799 --> 00:01:38,040 and so it's good too. I sort of organize it. I think I 19 00:01:38,079 --> 00:01:41,319 said to you in between recordings last week, because we're just doing like a 20 00:01:41,439 --> 00:01:42,959 show or here, or they're just staying a week or so ahead. It's 21 00:01:44,000 --> 00:01:47,359 like, I'm gonna load up a bit. We'll see what happens here. 22 00:01:47,359 --> 00:01:52,439 I've got a few emails going out, and then in fairly short order I 23 00:01:52,560 --> 00:01:55,599 kind of said, hey, sorry, this is a lot of shows. 24 00:01:56,000 --> 00:01:59,200 But yeah, it's also fun. Yeah, sure is, you know, 25 00:01:59,400 --> 00:02:05,319 to just sort of focus and have intense conversations about great technology. So I'm 26 00:02:05,359 --> 00:02:08,840 really looking forward to this flurry. And then we'll be doing some on stage 27 00:02:08,840 --> 00:02:14,000 and live shows and in person shows coming into spring conferences. That's right, 28 00:02:14,319 --> 00:02:17,159 Techarama for one yep around, we'll be one of them. Yeah, And 29 00:02:17,520 --> 00:02:22,280 when is dev Intersection again? The next dev Intersection is the first week of 30 00:02:22,400 --> 00:02:27,199 December in Orlando, Ah that's gonna be fun. So we're going back to 31 00:02:27,319 --> 00:02:32,560 Orlando. We're in the Swan and the registration's opening up shortly. Still working 32 00:02:32,599 --> 00:02:37,080 on some curriculum and stuff, but you know, we got some time. 33 00:02:37,680 --> 00:02:40,599 I got some crazy keynotes because you know, you think about how much has 34 00:02:40,599 --> 00:02:46,599 happened since chat GPT in November. Oh, I know, yeah, crazy, 35 00:02:46,680 --> 00:02:49,879 and here we are in April. Now, think about what it's going 36 00:02:49,919 --> 00:02:52,919 to be like by the end of the year. It's gonna be insane. 37 00:02:53,280 --> 00:02:55,080 I mean, it already is insane. I don't know, it could go 38 00:02:55,159 --> 00:02:59,680 either way. This is quite the hype cycle. Yeah, well, let's 39 00:02:59,759 --> 00:03:01,680 get things started with a little thing we call a better note a framework. 40 00:03:01,800 --> 00:03:13,639 Awesome, all right, man, what do you got? Speaking of chat 41 00:03:13,719 --> 00:03:17,199 GPT and all that great stuff and hype cycle and the hype cycle and the 42 00:03:17,280 --> 00:03:23,319 hype never ends. Everybody's jumping on the hype bandwagon. Here Google announces AI 43 00:03:23,479 --> 00:03:29,680 features in Gmail docs and more to rival Microsoft. This is an article in 44 00:03:29,719 --> 00:03:35,319 The Verge March thirtieth. Google will soon offer ways to generate text and images 45 00:03:35,400 --> 00:03:38,919 using machine learning and its workspace products, as part of a scramble to catch 46 00:03:39,000 --> 00:03:44,120 up with rivals in the new AI race, right, Yeah, this is 47 00:03:44,159 --> 00:03:47,680 the logical hit back, right of course, because Microsoft goes after search with 48 00:03:47,840 --> 00:03:54,599 being AI, so Google goes after office with features in Google Docs, yeah, 49 00:03:54,680 --> 00:03:59,479 sheets, etc. That's one of the few places that Google can really 50 00:03:59,520 --> 00:04:01,960 scare Mike or soft right. Yeah. Yeah, one would argue everything to 51 00:04:02,000 --> 00:04:05,240 happen in office. Three sixty five, now, m three sixty five was 52 00:04:05,280 --> 00:04:13,439 about competing with Google's docs online Google Docs. Yeah, yeah, I use 53 00:04:13,479 --> 00:04:15,519 it all the time. Yeah, just because it's easy. Well, I 54 00:04:15,519 --> 00:04:19,000 think about the number of times you and I have been writing simultaneously in a 55 00:04:19,079 --> 00:04:25,480 Google Doc for like an ad script or any sorts of things. And I 56 00:04:25,560 --> 00:04:30,240 even use that feature in our admin app. Yeah. Yeah, that same 57 00:04:30,240 --> 00:04:33,120 affect good old signal arm. Man. The thing that's the thing it interests 58 00:04:33,160 --> 00:04:39,279 me is is this, like Bard, is this a forever beta a Gmail? 59 00:04:39,360 --> 00:04:41,839 What's beta? Forever? Wasn't it? Yeah? For sixty years? 60 00:04:41,879 --> 00:04:45,319 Seven years? Like six years? Yeah? You crazy? I get that, 61 00:04:45,360 --> 00:04:46,920 they're responding. It's the question is when are you going to release it? 62 00:04:46,959 --> 00:04:49,839 Because I'm in Canada. You can't use Bard in Canada. It's not 63 00:04:50,000 --> 00:04:51,839 can't even take it out for his bit. I gotta tell you, I 64 00:04:51,920 --> 00:04:58,000 was talking to one of my customers just a few days ago, and he 65 00:04:58,160 --> 00:05:01,120 said, uh, boy, tell you what, man, chat CHPT is 66 00:05:01,160 --> 00:05:06,319 just saving my butt, saving so much time, you know for little syntactical 67 00:05:06,399 --> 00:05:10,800 things like how do I do this? How do I do that? Yeah, 68 00:05:10,839 --> 00:05:14,600 it's pretty good. Just make sure you test it thoroughly. It's actually 69 00:05:14,680 --> 00:05:17,920 correct. And the question is is that special chat GPT or if he'd bought 70 00:05:18,000 --> 00:05:20,800 grammarily, would he have gotten the same thing. Oh, I don't think 71 00:05:20,800 --> 00:05:26,839 grammarly can do link queries, but certainly chat gpt ken. Yeah, that's 72 00:05:26,839 --> 00:05:30,879 true if he's writing code versus writing copy. Yeah, yeah, code. 73 00:05:30,879 --> 00:05:32,920 It's really great for code. Yeah, you just got to make sure that 74 00:05:33,399 --> 00:05:36,639 you know it's good. Is it big? Is it better than get hub 75 00:05:36,800 --> 00:05:40,839 copie? Yeah? I don't know. That's a man, what a great 76 00:05:41,240 --> 00:05:45,439 comparison to do. Yeah, we ought to do that. There's so many 77 00:05:45,639 --> 00:05:48,279 believe me, and I don't want to make this the all large language model 78 00:05:48,360 --> 00:05:50,439 show. No, no, no, no, this is just the intro. 79 00:05:50,600 --> 00:05:54,519 Here. There's lots of there's lots of talk about Brown. He's coming 80 00:05:54,600 --> 00:05:58,600 right up here. But before we bring him on, who's talking to us? 81 00:05:58,680 --> 00:06:01,839 Richard grabbed a Comma Top of Show seventeen ninety. That's the one we 82 00:06:01,879 --> 00:06:08,720 did with Chris Kluge when we were talking about his experiences doing experiments with different 83 00:06:08,720 --> 00:06:15,360 infrastructure as code Solutions, Terraform and BICEP and Pullumi, and of course that 84 00:06:15,480 --> 00:06:19,199 had that ended up in a conversation about the DevOps cycle as whole automating of 85 00:06:19,360 --> 00:06:24,920 builds and so on, which is really you know, part and parcel with 86 00:06:25,000 --> 00:06:29,560 trying to make your software better and Devil Goel had this great comment from last 87 00:06:29,639 --> 00:06:31,959 year. He said, my hot take on DevOps is that too many practitioners 88 00:06:32,000 --> 00:06:35,759 start off with rigid, preconceived notions of what they want to do. This 89 00:06:35,879 --> 00:06:40,439 is normal. Our decision making is always going to be shaped by our scars. 90 00:06:40,959 --> 00:06:46,199 We've used that line before. Oh yeah, old favorite. Yeah. 91 00:06:46,240 --> 00:06:49,439 However, it helps to approach devots technology, like any technology, with an 92 00:06:49,439 --> 00:06:53,800 open mind, start by looking at whether or not the out of box functionality 93 00:06:53,839 --> 00:06:57,759 is sufficient and if not, why, Yeah. You know, we always 94 00:06:57,800 --> 00:07:00,199 tend to want to mold the tools to our vision of what it's going to 95 00:07:00,240 --> 00:07:03,439 be, rather than just use what's there. And here's a line that I 96 00:07:03,480 --> 00:07:10,279 loved, are the scars running the show? Wow, there's always going to 97 00:07:10,319 --> 00:07:13,000 be some amount of custom work that needs to be done, But our first 98 00:07:13,040 --> 00:07:15,519 step is always start figuring out how to get the pipeline to run a custom 99 00:07:15,600 --> 00:07:21,360 Bash or PowerShell script. You're probably doing something wrong. You aren't that special. 100 00:07:24,040 --> 00:07:27,319 If the canned features can get you most I done all the way there, 101 00:07:27,399 --> 00:07:30,720 you should start with those. They almost always are going to provide decent 102 00:07:30,759 --> 00:07:33,959 air handling, logging, and parameter checking, especially if their first party offerings. 103 00:07:34,319 --> 00:07:36,839 Keep in mind that there are going to be differences between green Field and 104 00:07:36,879 --> 00:07:40,959 Lift and Shift that might require some extra work. I like to think this 105 00:07:41,000 --> 00:07:44,800 way in any cloud project. If step one's great an Azure VM and install 106 00:07:44,800 --> 00:07:55,319 a sequel server, you're probably doing it wrong. Devon's gotten gotten. I 107 00:07:55,439 --> 00:07:59,600 checked back and saw we've exchanged a few emails before. He's received music code 108 00:07:59,639 --> 00:08:03,160 By before. But Devin's such a great comment man, so thanks so much 109 00:08:03,199 --> 00:08:05,040 for commenting. If you'd like a copy of Music go By, I write 110 00:08:05,040 --> 00:08:09,160 a comment on the website at dot at Rocks dot com or on the facebooks. 111 00:08:09,199 --> 00:08:11,680 We publish every show there, and if we comment there and I read 112 00:08:11,680 --> 00:08:13,279 it on the show, we'll send you a copy Music go By. And 113 00:08:13,480 --> 00:08:16,800 you know you can follow us on Twitter, but we'd really like you to 114 00:08:16,839 --> 00:08:20,199 follow us on Mastodon. I'm at Carl Franklin at tech Hub dot social, 115 00:08:20,360 --> 00:08:24,839 and I'm Rich Campbell at mastodon dont social and send us a two we'd like 116 00:08:24,920 --> 00:08:31,360 to see there. My tutors are growing. Let me say that. Can 117 00:08:31,439 --> 00:08:35,480 you say that you need to bleep that? No, I don't think so. 118 00:08:35,240 --> 00:08:43,240 Tutors man, your tutors, my minions of tutors, well, you 119 00:08:43,320 --> 00:08:46,879 know that they're just followers like two thing else. I started this just at 120 00:08:46,919 --> 00:08:52,879 a couple of months ago maybe and got about twelve hundred followers now, so 121 00:08:52,039 --> 00:08:56,480 that's really good. And I always follow whoever follows me. That's just the 122 00:08:56,559 --> 00:09:01,480 way it goes. Well, anyway, let's bring on Rony Roni Dover is 123 00:09:01,519 --> 00:09:07,480 a holistic developer and builder with a passion for development processes and practices. Afflicted 124 00:09:07,600 --> 00:09:13,000 by an acute product manager slash developer split personality disorder that was never treated. 125 00:09:13,080 --> 00:09:16,000 There a cream for that. I don't think there is. I don't think 126 00:09:16,039 --> 00:09:20,039 so. You got to go into the office. Currently CTO and co founder 127 00:09:20,120 --> 00:09:26,080 of Digma Digma dot ai, an ide plug in for code runtime AI analysis 128 00:09:26,159 --> 00:09:31,360 to help accelerate development in complex codebases. A big believer in evidence based development 129 00:09:31,480 --> 00:09:37,720 and proponent of continuous feedback in all aspects of software engineering. Welcome Ronie. 130 00:09:37,720 --> 00:09:41,480 Hello, Hello, great to be here. When I hear continuous feedback, 131 00:09:41,600 --> 00:09:46,120 you know, that's one of the features of being in a state of flow, 132 00:09:46,559 --> 00:09:50,039 isn't it. Yeah. We heard about this great book Flow by Mehi 133 00:09:50,159 --> 00:09:54,159 Chicks and me Hi from Mark Sieman many years ago, and you know they 134 00:09:54,240 --> 00:10:00,879 talked about people fileting fish, you know, all day long at the market 135 00:10:01,080 --> 00:10:03,080 a Pike's Market. You know, the guys who are just like fileting salmon 136 00:10:03,639 --> 00:10:07,480 and they're just in the zone. But that state of flow gives you this 137 00:10:07,720 --> 00:10:16,960 continuous feedback and that really allows you to go fast. Yeah, and maybe 138 00:10:18,159 --> 00:10:20,799 before I dived right into it, I just want to touch on your previous 139 00:10:20,840 --> 00:10:24,480 discussion about AI and AI systems. Oh sure, Yeah. I was just 140 00:10:24,879 --> 00:10:31,039 having a casual conversation with a friend and we were trying to estimate just how 141 00:10:31,200 --> 00:10:37,679 much code exists today in production systems. That was written by AI and maybe 142 00:10:37,919 --> 00:10:43,919 nobody even took a look at it, like no no human intervention. And 143 00:10:45,240 --> 00:10:48,360 you know, you could say the same about tack overflow. Or you know, 144 00:10:48,519 --> 00:10:54,399 they said back then, coppy taste that type of development. But the 145 00:10:54,559 --> 00:10:58,879 more abstract the AI. And I'm a big proponent of AI, and I'm 146 00:10:58,000 --> 00:11:05,480 using it a lot myself, But the more you kind of abstract the request 147 00:11:05,639 --> 00:11:09,480 from the AI and kind of remove yourself from the generated code, it becomes 148 00:11:09,559 --> 00:11:16,879 less about snippets or regular expressions or linqueries and you can actually, you know, 149 00:11:16,039 --> 00:11:22,879 request entire business logic being implemented. That's right, and and that's amazing 150 00:11:22,960 --> 00:11:26,639 to me, and to me it's also very poignant and relevant to the to 151 00:11:26,759 --> 00:11:31,519 the topic of feedback, because essentially, you have a bit of code here, 152 00:11:31,559 --> 00:11:35,519 and it doesn't matter if somebody else wrote it, or I wrote it 153 00:11:35,639 --> 00:11:39,600 a year ago, or maybe I'm just kind of trying to make my to 154 00:11:39,720 --> 00:11:45,080 make kind of this opaque piece of code a little more transparent to me, 155 00:11:46,240 --> 00:11:50,759 and it seemed like without that type of visibility, we kind of have a 156 00:11:50,919 --> 00:11:54,759 problem on our hand. And it's the kind of problem that you don't notice 157 00:11:54,879 --> 00:12:00,399 until you do. And we were kind of chatting before, and you guys 158 00:12:00,440 --> 00:12:03,879 said that over twenty years year on the air, which is amazing. And 159 00:12:05,000 --> 00:12:07,480 I've been a developer for more than twenty years and when I got started, 160 00:12:09,240 --> 00:12:13,399 at least in the culture of the organizations that I worked around, there was 161 00:12:13,480 --> 00:12:18,639 no continuous testing. And I remember it very well, and it was you 162 00:12:18,720 --> 00:12:22,960 know, that's what that's what we knew. There was some testing that you 163 00:12:22,200 --> 00:12:26,000 had, out of the kindness of your hearts to run every now and then, 164 00:12:26,080 --> 00:12:30,960 but that was just about it. Hopefully you had testers or some sort 165 00:12:31,000 --> 00:12:35,679 of QA in your organization, yeah, or QA department. Yeah, But 166 00:12:35,960 --> 00:12:39,080 essentially, but that's not continuous, right, They're still taking a bite and 167 00:12:39,200 --> 00:12:41,840 you're right, like it it comes down to how how do you describe continuous 168 00:12:41,960 --> 00:12:48,200 Like I would argue that intellisenses continuous for sure, for sure. So so 169 00:12:48,480 --> 00:12:54,639 essentially I was we were kind of running blind like today for me, like 170 00:12:54,799 --> 00:12:58,159 pushing changes without running tests. As you know, you must be a very 171 00:13:00,440 --> 00:13:05,519 brave and I don't know, desperate soul to actually do something like that, 172 00:13:05,720 --> 00:13:11,120 but you know that it's it's crazy, or so it seems today. And 173 00:13:11,279 --> 00:13:16,799 at the same time, once kind of you you start understanding that feedback is 174 00:13:16,360 --> 00:13:22,399 really essential. Coding without feedback, I kind of feel the same type of 175 00:13:22,679 --> 00:13:30,840 blindness that I felt when there was no kind of infrastructure of tests to support 176 00:13:30,919 --> 00:13:33,240 me. So what do you mean when you say feedback, Like what are 177 00:13:33,279 --> 00:13:41,759 you looking for there? So essentially, today we're pushing code, we're running 178 00:13:41,799 --> 00:13:48,799 code, and that code, especially with recent kind of leaps and observability technology, 179 00:13:48,879 --> 00:13:52,559 has a lot to say about how it's functioning and how it's running. 180 00:13:52,240 --> 00:13:56,080 There is a lot of data. Bit the question is are we looking at 181 00:13:56,120 --> 00:14:01,919 that data? And when are we looking at at data? So let's say 182 00:14:03,080 --> 00:14:09,679 I just got um. I pushed an upgrade to the doll system, like 183 00:14:09,879 --> 00:14:15,200 I A to the doll or that access. I added that some caching and 184 00:14:15,360 --> 00:14:20,879 some other features around it. I was shocked how many developers, when given 185 00:14:22,000 --> 00:14:26,960 such a feature to develop, would go ahead, developed a feature, maybe 186 00:14:28,039 --> 00:14:31,960 run a few times, deploy, and let's move on to the next feature, 187 00:14:33,840 --> 00:14:37,840 without, for example, examining they did it make life better for everyone? 188 00:14:39,080 --> 00:14:43,360 Did it improved the state of the system? And there are many reasons 189 00:14:43,440 --> 00:14:45,799 for that, And you know, I just give one example, but you 190 00:14:45,919 --> 00:14:48,559 know I could look at numerous cases. And this is something I noticed while 191 00:14:48,600 --> 00:14:56,480 working alongside was very commented developer. And they were given a feature, they 192 00:14:56,679 --> 00:14:58,600 developed it, they wrote the test, they did everything. Today you know, 193 00:14:58,720 --> 00:15:03,039 they even wrote the helm file or the terror form to deploy it. 194 00:15:05,279 --> 00:15:11,679 They pushed that merge to master button and then they they moved on to the 195 00:15:11,799 --> 00:15:16,440 next feature. And I asked them, you know, is your code even 196 00:15:16,600 --> 00:15:20,440 getting executed in production? Can you tell me even that maybe you made uh 197 00:15:20,879 --> 00:15:24,600 you know, maybe there's one bad IF statement preventing your code from ever being 198 00:15:24,759 --> 00:15:28,279 run. I mean presumably they you know you even described it this way. 199 00:15:28,360 --> 00:15:31,080 They ran it themselves. Right, You write some code, you run it, 200 00:15:31,600 --> 00:15:35,559 like there's your feedback, the compiler compiled it, and it showed up 201 00:15:35,600 --> 00:15:39,399 on the screen or showed up, you know in some way. But I 202 00:15:39,519 --> 00:15:43,840 think about point of now you push it out, you know, put it 203 00:15:43,879 --> 00:15:48,279 into the pipeline, it goes out of the production. When is the next 204 00:15:48,399 --> 00:15:54,679 time it actually those lines of code get executed exactly exactly? And uh, 205 00:15:54,919 --> 00:15:58,919 this is something that's uh that's been bugging me. Um. And you know 206 00:16:00,559 --> 00:16:07,279 you're right that there is some information that you get out of let's say your 207 00:16:07,600 --> 00:16:11,000 debt system, and maybe some feedback you get back from the test, which 208 00:16:11,080 --> 00:16:17,759 is mostly kind of limited because it's not qualitative. It's more true false as 209 00:16:17,840 --> 00:16:23,919 failed kind of thing. But when it comes to more non functional feedback and 210 00:16:25,080 --> 00:16:30,960 more kind of feedback that has to do with the quality of the code and 211 00:16:30,360 --> 00:16:34,120 the impact of your changes. There's very little of that, both from CRI 212 00:16:34,279 --> 00:16:40,279 and production and even in Devon. I'll tell you another story. I caught 213 00:16:40,960 --> 00:16:48,879 a developer in my team adding a console log statement to a background service. 214 00:16:49,279 --> 00:16:55,600 And I noticed it because I'm looking at my code and I'm saying it was 215 00:16:55,720 --> 00:17:00,759 just printing the amount of time that that kind of loop iteration took. And 216 00:17:00,039 --> 00:17:03,480 you were you were, you were running your code. You have to call 217 00:17:03,639 --> 00:17:07,319 his code and now you're seeing stuff show but your console exactly. Now, 218 00:17:07,599 --> 00:17:11,720 First of all, I would like to command that developer because a lot of 219 00:17:11,839 --> 00:17:15,440 developers would not do that right, they would not even check for that. 220 00:17:15,759 --> 00:17:19,920 It shows that he had the kind of insight to say, this is important 221 00:17:19,960 --> 00:17:26,640 to notice as I'm making changes, did this kind of U the discycle increased 222 00:17:26,720 --> 00:17:30,640 dramatically in terms of performance? Why because maybe I made a mistake. It's 223 00:17:30,720 --> 00:17:36,359 the wrong technology to do it. Yeah, like he probably a console log 224 00:17:36,680 --> 00:17:40,599 would kind of you know, he probably not noticed it forever and it doesn't 225 00:17:40,599 --> 00:17:45,799 become a part of it. Have methodology beyond just that one time that that 226 00:17:47,000 --> 00:17:52,480 that he added, the console log is the er debug tool for JavaScript, 227 00:17:52,640 --> 00:17:57,440 isn't it exactly? But at the same time, I completely sympathize with the 228 00:17:57,519 --> 00:18:03,720 sentiment, and I want, without thinking about adding a console long, for 229 00:18:03,880 --> 00:18:10,559 that information to be very as we said before, continuous and proactive, so 230 00:18:10,720 --> 00:18:15,519 that I don't need to think about it immediately. Because my code is running 231 00:18:15,559 --> 00:18:19,440 and because I made some changes, and because things are now worse or even 232 00:18:19,519 --> 00:18:26,799 better, like I'm I like to get positive feedback as well, that feedback 233 00:18:26,799 --> 00:18:30,240 will start streaming to me as a developer, and that becomes kind of my 234 00:18:30,440 --> 00:18:34,519 eyes and ears about how my code is running and whether it's running, and 235 00:18:34,680 --> 00:18:37,920 again, what is the impact of my change it Because so it's part of 236 00:18:37,960 --> 00:18:42,079 what you're saying there reminded me of this is stuff we catching code review that 237 00:18:42,559 --> 00:18:47,799 if you're pair programming, or if you do a code review like I don't 238 00:18:47,799 --> 00:18:51,079 know if any other way that really assesses code quality other than other pairs of 239 00:18:51,200 --> 00:18:53,519 eyes on it saying you know, there's a more reliable way to write this. 240 00:18:53,920 --> 00:18:59,559 You know that that kind of mentality of just like making higher quality code 241 00:19:00,160 --> 00:19:03,119 because the law of volvers are still very much in the place of hey, 242 00:19:03,200 --> 00:19:07,359 you know what it runs like, that's good enough. There's no concern about 243 00:19:07,440 --> 00:19:11,880 quality. The main quality is it functions exactly. So did this issue UM 244 00:19:12,440 --> 00:19:18,839 ultimately leads you to Digma? And yes, yes, exactly. And and 245 00:19:18,039 --> 00:19:22,680 did you look for other tools out there? You said, there isn't anything 246 00:19:22,720 --> 00:19:26,000 out there that does it. But what does DIGMA do that's so different from 247 00:19:26,400 --> 00:19:30,400 you know, other telemetry products, let's say so, Actually, the origin 248 00:19:30,559 --> 00:19:37,359 story is is that I was looking at the DevOps loop, a diagram that 249 00:19:37,680 --> 00:19:41,799 by now become you know, completely overused michiels look whatever, you've foreign it, 250 00:19:41,880 --> 00:19:45,680 but it's still kind of a good model of the profit UM. And 251 00:19:45,839 --> 00:19:49,279 I was noticing in that particular diagram I was looking at it, it had 252 00:19:49,359 --> 00:19:53,319 like at different tools associated was each that was kind of like an equosystem long 253 00:19:53,359 --> 00:19:56,720 break now, but you saw the build tools of diploy tool, of continous 254 00:19:56,720 --> 00:20:02,920 integration tools, and there was a actually an arrow leading in the other direction. 255 00:20:02,960 --> 00:20:07,000 There was an arrow leading from production back into death and it said continuous 256 00:20:07,039 --> 00:20:10,440 feedback. That's what that's what their name said. Yes, and they went 257 00:20:10,480 --> 00:20:14,359 out tools associated with that particular error, and that kind of blew me off 258 00:20:14,400 --> 00:20:18,160 because I was looking at this Stagram, and there's so many CI tools, 259 00:20:18,240 --> 00:20:21,920 so many build and deployed tool, so many monitoring tools. All of these 260 00:20:22,000 --> 00:20:26,039 exists. How come when you looked at continuous feedback, what was supposed to 261 00:20:26,079 --> 00:20:30,079 bring the information back to the developer. Now we could talk in terms of 262 00:20:30,759 --> 00:20:33,680 was that feedback supposed to go back to the developers? That feedback supposed to 263 00:20:33,720 --> 00:20:38,319 go back to the to the pms, as this health features were used, 264 00:20:38,720 --> 00:20:42,440 here are the but the errors that we're seeing and then it gets fed into 265 00:20:42,480 --> 00:20:48,559 the sprint pipeline as remediations and people aren't using as the way we thought. 266 00:20:48,920 --> 00:20:53,519 You know that kind of thing like there is tools and the ear right, 267 00:20:53,759 --> 00:20:59,680 but I think that we need to separate the types of feedback. And as 268 00:21:00,039 --> 00:21:03,039 I was saying before, and you actually mentioned it in the most accurate intro 269 00:21:03,160 --> 00:21:07,839 that was ever a clearly written about me that I have a split personality between 270 00:21:07,960 --> 00:21:14,079 being a product manager and a coder. And at putting on my product manager 271 00:21:14,160 --> 00:21:17,240 had for a second, there are graduals as a product manager to understand what 272 00:21:17,359 --> 00:21:21,119 my users have gen So from a product perspective, I have, you know, 273 00:21:21,599 --> 00:21:26,480 the analytics, the tools that gave me feedback about how the product is 274 00:21:26,519 --> 00:21:30,839 doing. From a developer perspective, there is no Google Analytics for developers. 275 00:21:30,960 --> 00:21:34,759 I don't know which parts of my code are being used and how, and 276 00:21:36,640 --> 00:21:42,359 I don't understand that this specific area of the code is a major a nexus 277 00:21:42,440 --> 00:21:48,039 bubbleneck area that is being used by multiple flows in the system that the routing 278 00:21:48,160 --> 00:21:52,759 so much traffic, and I need to think about concurrency here. It kind 279 00:21:52,799 --> 00:21:56,799 of becomes trivling knowledge. So, if anything, I think there is a 280 00:21:56,880 --> 00:22:03,119 big gap between that kind of of elegance and richness of the ecosystem available to 281 00:22:03,400 --> 00:22:08,920 product managers and the technical feedback that I want to receive, both as requirements 282 00:22:10,039 --> 00:22:17,160 as and as kind of or feedback back on my work that's available from a 283 00:22:17,200 --> 00:22:21,359 technical perspective to the perth. So ray gun doesn't do that. For example, 284 00:22:21,359 --> 00:22:23,720 I'm just thinking off the top of my head, you can't tell raygun 285 00:22:23,799 --> 00:22:30,799 to analyze bottlenecks and report back to me timings and things like that. Sure, 286 00:22:30,920 --> 00:22:34,319 there are a lot of technologies, but what I found out when I 287 00:22:34,640 --> 00:22:41,400 to developers is that montyas feedback is not something they past meaning when you talk 288 00:22:41,480 --> 00:22:48,160 to most developers. Although there are many dashboards and many kind of nice ways 289 00:22:48,200 --> 00:22:55,519 to visualize the data and you know, and to be frank, this caught 290 00:22:55,599 --> 00:22:59,880 me so off guard as a developer that I spent half a year just research 291 00:23:00,119 --> 00:23:03,279 this. And by researching, I de meant talking to as many people as 292 00:23:03,359 --> 00:23:07,559 I could, and you know, trying to get to the rook of the 293 00:23:07,720 --> 00:23:11,240 problem. And I found out two very simple things. First of all, 294 00:23:11,839 --> 00:23:18,079 developers are busy, mostly over work, and they don't go looking for trouble. 295 00:23:18,359 --> 00:23:22,039 This is why developers did right out of the kindness of their heart, 296 00:23:22,599 --> 00:23:26,359 unless it became continuous and it became something that had to happen. And in 297 00:23:26,480 --> 00:23:30,480 the same way, developers won't go looking for trouble in the dashboard if it 298 00:23:30,599 --> 00:23:33,960 means another kind of headache that they need to fix. Right, you work 299 00:23:34,000 --> 00:23:40,200 your burn down chart, and if you've got somebody in forcing code coverage, 300 00:23:40,240 --> 00:23:42,400 then you do enough code coverage to keep you out of trouble. That that 301 00:23:42,640 --> 00:23:48,839 is such a true statement there. Developers don't go looking for trouble. So 302 00:23:48,240 --> 00:23:52,160 talk about security like, we don't like security. That's just telling me what 303 00:23:52,279 --> 00:23:56,599 I can't do. We don't like somebody telling us, oh, this code 304 00:23:56,680 --> 00:23:59,799 could be improved if you just did this and that you're like, yeah, 305 00:24:00,039 --> 00:24:02,960 yeah, get around to that. Shut up, you know, get a 306 00:24:03,000 --> 00:24:07,559 little fragile ego. Well, mostly because I benefit from shipping features. Yeah 307 00:24:07,759 --> 00:24:11,359 right, right, But but you know we've said this before on the show 308 00:24:11,400 --> 00:24:14,240 many times, Richard, if you want to be a good developer, lose 309 00:24:14,279 --> 00:24:18,440 your ego, right, because it's all about having the best code and having 310 00:24:18,559 --> 00:24:22,759 tools that point out you know, this could be better. It's actually making 311 00:24:22,839 --> 00:24:26,240 you a better programmer and making your products better for sure. So yeah, 312 00:24:26,519 --> 00:24:32,440 truer words were never spoken. Developers don't like to go looking for trouble being. 313 00:24:32,519 --> 00:24:36,079 And by the way, I completely shared that sentiment, you know when 314 00:24:36,240 --> 00:24:41,319 when when when I stopped talking on podcasts and I start coding. Uh, 315 00:24:41,680 --> 00:24:45,119 it's it's the same thing, you know, I feel and what I like 316 00:24:45,400 --> 00:24:49,240 moving forward to the next new feature. Uh, you know, I like, 317 00:24:49,599 --> 00:24:56,519 um kind of a feeling progress. And and if I get sucked into 318 00:24:56,680 --> 00:25:00,519 these issues and it just slowed me down, and I'm right consciously motivated to 319 00:25:00,759 --> 00:25:07,599 kind of not necessarily invest in these areas. And this is a problem, 320 00:25:07,079 --> 00:25:11,119 and it also requires cognitive effort. And this is the other thing that I 321 00:25:11,240 --> 00:25:15,319 know this so you get to some of these realizations like, you know what, 322 00:25:15,519 --> 00:25:19,599 as of my last commit, this and this change, this timeout error 323 00:25:19,720 --> 00:25:25,000 rate is different than it was before, and this API that I'm using or 324 00:25:25,039 --> 00:25:30,880 whatnot? Right, I need to have some cognitive effort and tools and expertise 325 00:25:30,519 --> 00:25:34,039 that not all the developers have. And as a result, you know, 326 00:25:34,160 --> 00:25:40,920 my statistics one on one is pretty kind of not as up to date, 327 00:25:41,039 --> 00:25:45,720 and many developers kind of well try to ignore it because it's not in their 328 00:25:45,799 --> 00:25:49,960 conflicts, I mean, not something that they know and practice every day. 329 00:25:51,119 --> 00:25:53,119 And that makes a lot of sense to That's why we have tools. You 330 00:25:53,240 --> 00:25:59,279 talk about cognitive effort, it's when you have that feed, that typical debop 331 00:25:59,319 --> 00:26:03,039 feed backside. All that lands back on the pms and the feature designers, 332 00:26:03,079 --> 00:26:06,759 the business analysts and so forth. The way it trickles back to the developer 333 00:26:06,960 --> 00:26:11,400 is, yeah, the apps too slow, Like that's some cognitive effort like 334 00:26:11,559 --> 00:26:15,920 to try and address that problem, say, okay, well where is it 335 00:26:15,000 --> 00:26:19,119 too slow? How is it too slow? Like to just decompose these sorts 336 00:26:19,160 --> 00:26:25,680 of broad statements into actionable code. That's a lot of effort. You can 337 00:26:25,720 --> 00:26:29,039 spend a long time trying to break that down enough to go. This is 338 00:26:29,079 --> 00:26:32,839 the piece of code we need to optimize. You're absolutely right, and time 339 00:26:32,960 --> 00:26:37,200 is key here because it takes a long cyc of those context of what you 340 00:26:37,279 --> 00:26:41,079 were doing your contact switching. You need to there is this issue, but 341 00:26:41,200 --> 00:26:45,160 now it goes back need more information and then develops guys way in and then 342 00:26:45,920 --> 00:26:51,799 the IT guy's way in and you go back to the customer and eventually kind 343 00:26:51,839 --> 00:26:56,559 of it becomes a very inefficient process. So how does digma address this issue? 344 00:26:56,839 --> 00:27:00,759 Yeah, so the premise of Digma was very simple. It was all 345 00:27:00,799 --> 00:27:07,680 of the information is there. The problem is making it proactive and reducing the 346 00:27:07,759 --> 00:27:11,880 cognitive effort and making it something that's continuous that fits into my DARE workflow. 347 00:27:11,680 --> 00:27:17,039 And if we can use AI to generate code, there is no way we 348 00:27:17,119 --> 00:27:22,640 can't use AI to evaluate the code at frontime. And essentially what Tigma is 349 00:27:22,160 --> 00:27:27,319 is a way to is a platform that evaluate the code in WRON time and 350 00:27:29,759 --> 00:27:34,000 kind of like a linterm maybe but not for static analysis or dynamic analysis. 351 00:27:34,680 --> 00:27:40,519 And it can give you that indication straight away in depth than in test and 352 00:27:40,640 --> 00:27:48,160 in production about specific issues that you should notice in your code, specific parameters 353 00:27:48,240 --> 00:27:52,799 that you need to know in order to better design it and and and the 354 00:27:52,920 --> 00:27:56,319 concept is that we didn't invent the profiler. We didn't you know, have 355 00:27:56,480 --> 00:28:00,920 to add some weird reflection into the code to make it happen. We just 356 00:28:02,079 --> 00:28:07,519 used the existing technologies. And actually dot net made it amazingly easy by incorporating 357 00:28:07,640 --> 00:28:12,640 hotel into the standard library. As far as System Diagnostic, which you know, 358 00:28:12,759 --> 00:28:17,400 to me as as a dotnet developer, was was great. It was 359 00:28:17,480 --> 00:28:21,559 great news because it just made it I'm a lot easier to support it within 360 00:28:21,640 --> 00:28:23,839 doctor. So what's built in the dot net that makes your life easier? 361 00:28:25,119 --> 00:28:29,279 So as of dot Net, I think it's four point six to eight. 362 00:28:29,480 --> 00:28:36,119 They back that they added it backwards or something like that. Un System Diagnostics 363 00:28:36,240 --> 00:28:41,799 now supports open telemetry right open telemetry for those who are not familiar with it 364 00:28:42,200 --> 00:28:49,559 is a great step forward with observability. And the reason is not that it's 365 00:28:49,640 --> 00:28:56,519 doing anything groundbreaking, but that everybody agrees on it and it's open source. 366 00:28:57,319 --> 00:29:03,440 So the combination of these two, you know, it's understated here, but 367 00:29:03,599 --> 00:29:08,720 it really becomes a game changer in terms of observability because suddenly, a you 368 00:29:08,799 --> 00:29:12,519 can rely on an open standard, then you don't need to kind of support 369 00:29:12,640 --> 00:29:19,039 one APM or another APM and their proprietary kind of finicking abstraction. But you 370 00:29:19,160 --> 00:29:26,920 have this open source, by the way, very staggeringly popular across different platforms 371 00:29:26,960 --> 00:29:32,319 and languages javan js, dot net. You can be a polyglot developer and 372 00:29:32,440 --> 00:29:37,759 kind of benefit from it across your distributed micro services and multiple languages. And 373 00:29:37,200 --> 00:29:41,359 it's open and very easy to kind of create an ecosystem around it. And 374 00:29:41,519 --> 00:29:51,359 because it's so widely agreed upon, support started kind of becoming standard for any 375 00:29:51,559 --> 00:29:55,519 library platform. So aspeed, dot neet, NBC NAT supports it. You 376 00:29:55,559 --> 00:29:56,960 don't need to do anything, you just need to turn it on. It's 377 00:29:56,960 --> 00:30:03,559 an on switch. If you're using any inframwork, it supports it. If 378 00:30:03,599 --> 00:30:07,960 you're using an adapter for posters, it probably supports it. If you're using 379 00:30:07,480 --> 00:30:12,559 mass transit to work with a rabbit and queue or something like that, it 380 00:30:12,680 --> 00:30:19,880 supports it. So that means that taking a project from having zero visibility about 381 00:30:19,960 --> 00:30:23,119 what it does in terms of traces, metrics and logs to having almost too 382 00:30:23,240 --> 00:30:29,720 much data is a matter of flipping a switch rather than kind of, oh, 383 00:30:29,839 --> 00:30:34,279 let's kind of think about it, create a producag the philosophies for like 384 00:30:36,279 --> 00:30:41,200 two months about what we want to capture, then implement the let the infrastructure 385 00:30:41,200 --> 00:30:45,200 team work on some infrastructure for that. No, it's it's already kind of 386 00:30:45,279 --> 00:30:51,720 out of the bat, and that's a big game changer that makes technologies like 387 00:30:51,799 --> 00:30:56,920 what we're doing with stigmas very easy because now we have the data very easy 388 00:30:56,960 --> 00:31:00,359 for the user to turn it on, and then it's just a matter of 389 00:31:00,480 --> 00:31:04,119 how do we process it and make it relevant. And to make it relevant, 390 00:31:04,200 --> 00:31:10,279 we understood that our front end needs to be not a nice dashboard, 391 00:31:11,000 --> 00:31:18,519 but the developers tooling, which is the ide the get tops process, this 392 00:31:18,799 --> 00:31:22,480 is where he'll need that information. And so it becomes this kind of a 393 00:31:22,559 --> 00:31:30,400 living documentation and something that kind of becomes embedded within the code in so that 394 00:31:30,640 --> 00:31:36,839 I kind of take even that cognitive effort of taking opening another tab in my 395 00:31:36,960 --> 00:31:44,200 browser and and looking up a dashboard just because I thought I should check instead, 396 00:31:44,279 --> 00:31:47,880 it becomes something that just like a lintern, becomes embedded in my it. 397 00:31:48,480 --> 00:31:52,440 Well, now that you've completely piqued her and just we're going to pause 398 00:31:52,559 --> 00:32:00,119 for this very important message or too, we'll be right back and we're back 399 00:32:00,200 --> 00:32:05,960 for talking Roney about DIGMA. And now that we know what it is, 400 00:32:06,319 --> 00:32:12,119 and apparently that you just have to turn it on and magic happens. Is 401 00:32:12,160 --> 00:32:15,480 it really that easy? Yes, but I can take no credit for that. 402 00:32:16,240 --> 00:32:22,000 The open telemetry and open telemetry and how easy it is to integrate with 403 00:32:22,160 --> 00:32:28,480 dot was a very strategic decision by the dot back team and there you know 404 00:32:28,799 --> 00:32:34,559 so many different examples online. It is that easy to get some data out 405 00:32:34,640 --> 00:32:39,680 of your application, and there is also so much more depth to that data 406 00:32:39,759 --> 00:32:45,039 because now it's not just about logs, it's about logs and metrics and traces 407 00:32:45,119 --> 00:32:50,799 and inter correlating them. So it's it's very very easy to get very rich 408 00:32:50,920 --> 00:32:55,680 data and start making evidence based decision about your code and knowing what to focus 409 00:32:55,799 --> 00:32:59,799 on and what you need to improve. And it can see back to their 410 00:33:00,039 --> 00:33:04,200 product managers who now know that they need to prioritize something because they know it's 411 00:33:04,279 --> 00:33:08,839 impact. Give me a typical example of something that a developer might do that 412 00:33:09,279 --> 00:33:13,039 UM DIGMA would pick up on and say, hey, you should do it 413 00:33:13,119 --> 00:33:16,759 this way instead. Sure, UM, I'll give you a few. One 414 00:33:16,839 --> 00:33:24,480 example that I noticed is especially working with enemy firm work and these kind of 415 00:33:24,519 --> 00:33:31,839 absumptions, is you often fall into some coat smells inadvertedly just because of leaky 416 00:33:31,880 --> 00:33:37,400 abstractions and such, where you might create let's say an end plus one query 417 00:33:37,720 --> 00:33:43,799 or some kind of inefficient query that can be picked up if we analyzed what 418 00:33:44,079 --> 00:33:49,839 was actually happening when you when you're runner. And this is something that's easily 419 00:33:49,920 --> 00:33:52,480 picked up, like if you look at the choice, it will immediately jump 420 00:33:52,559 --> 00:33:57,160 at you. But to look at it and to know how to do that 421 00:33:57,440 --> 00:34:00,480 as a novel, right, and it could be something that has to do 422 00:34:00,720 --> 00:34:07,559 with basically how, let's say, how the quode is being used. So 423 00:34:08,559 --> 00:34:12,840 let's say I want to make a change in a particular area, and I'm 424 00:34:12,880 --> 00:34:19,559 working in a complex environment. So finding static usages is one thing, but 425 00:34:20,119 --> 00:34:23,880 understanding who's using this code in run time is another. And why is that 426 00:34:24,000 --> 00:34:28,280 important? Because those are the areas I want to test that I didn't break 427 00:34:28,400 --> 00:34:30,519 their flows, I didn't break their APIs and so on. That this is 428 00:34:30,559 --> 00:34:34,400 from a usage perspective, Well, that's ultimately what matters. It is not 429 00:34:34,559 --> 00:34:37,239 what you thought they were going to query from the data, it's what they 430 00:34:37,320 --> 00:34:42,639 queried from the data exactly. You're taking in a parameter from a user and 431 00:34:42,719 --> 00:34:46,920 they're searching on something horrible, but that's what they're searching on, so you 432 00:34:47,000 --> 00:34:50,119 know, how are you going to deal with this? On top of that, 433 00:34:50,599 --> 00:34:54,119 the you know, the any framework context could be could be described as 434 00:34:54,159 --> 00:35:01,280 a wrapper around leakey abstraction and so many ways you can go wrong, especially 435 00:35:01,360 --> 00:35:07,239 when you apply it to the Web. Definitely, definitely. And the idea 436 00:35:07,360 --> 00:35:14,679 is once you start getting those types of feedbacks, you start coding a bit 437 00:35:14,880 --> 00:35:20,119 more confidently because it's kind of like how then tests behind you. You know 438 00:35:20,719 --> 00:35:23,280 that there is something that's actually checking what's happening. And if I change the 439 00:35:23,400 --> 00:35:29,039 quarry and I forgot to add an index, I'll see those effects immediately. 440 00:35:30,559 --> 00:35:34,960 I'll see them and get notified about them and be able to do something about 441 00:35:34,960 --> 00:35:37,480 it. So rather than wait for that report up the stack of this the 442 00:35:37,559 --> 00:35:42,199 app is too slow. I mean, what I find very cool about this, 443 00:35:42,280 --> 00:35:44,840 and I'm just looking some of the screenshots and things, is you're you're 444 00:35:44,920 --> 00:35:49,360 in studio, you're looking at your code, but highlighted beside it is how 445 00:35:49,559 --> 00:35:55,199 this code ran in production from open telemetry data. So you can see that 446 00:35:55,320 --> 00:36:00,639 the fifty percent case took this long. The ninety percent case the slowest cases 447 00:36:00,719 --> 00:36:05,039 to take this long, so you see the variability in that, like you're 448 00:36:05,119 --> 00:36:12,239 kind of being guided to your problem children exactly exactly. And actually comparing those 449 00:36:12,360 --> 00:36:17,079 environments is also really critical. So knowing that let's say this area where I'm 450 00:36:17,119 --> 00:36:22,320 having major issues in one environment, visit project production is not getting hit at 451 00:36:22,360 --> 00:36:27,719 all in my testing environment, for example, would be some some other insight, 452 00:36:27,800 --> 00:36:31,800 and that's an interesting insight. That's kind of barress environment, just because 453 00:36:31,840 --> 00:36:39,199 we have the various different content, right, So all in all, I 454 00:36:39,360 --> 00:36:44,800 think that the one way to see how valuable it is for me it was 455 00:36:44,840 --> 00:36:49,280 just to turn it off because and you can see that in the screenshot like 456 00:36:49,440 --> 00:36:52,559 on the website where you kind of see these code lands and highlights all around 457 00:36:52,599 --> 00:36:55,679 your code telling you what's going on here. And then the first thing I 458 00:36:55,760 --> 00:37:00,880 do is I turn it off, and and suddenly you know that it's still 459 00:37:00,960 --> 00:37:04,679 there. You just can't see it because that data we didn't invent, We 460 00:37:04,840 --> 00:37:07,719 just analyzed the existing one. Yeah, so immediately there Now there seems to 461 00:37:07,800 --> 00:37:14,920 be a sort of excuse him here between servicing the open telemetry information and the 462 00:37:15,840 --> 00:37:20,000 AI part of the equation. I hesitate to even say that because is it 463 00:37:20,079 --> 00:37:23,360 actually a recommendation engine for how to treat it. So the AI is used 464 00:37:23,719 --> 00:37:27,960 to do a lot of thang. Now we're getting a lot of data, 465 00:37:28,239 --> 00:37:30,920 and the first things and the need to we need to do is make it 466 00:37:30,079 --> 00:37:35,239 useful and data is there's a lot of instances. This took this, this 467 00:37:35,400 --> 00:37:37,760 took that. But now you need to start to break it down to clustery 468 00:37:38,639 --> 00:37:43,280 in order to understand the main flows that are going through the system. Then 469 00:37:43,360 --> 00:37:46,840 to start understanding changes. What constitutes a change. You know, production environments 470 00:37:46,880 --> 00:37:53,679 look like a very abstract kind of wall where you just scattered paint all over 471 00:37:53,840 --> 00:37:58,159 it. It doesn't look like a nice graph where you can say, oh, 472 00:37:58,360 --> 00:38:02,079 here is that area where the change happened. In order to kind of 473 00:38:02,360 --> 00:38:09,000 start analyzing that, you need to make very advanced kind of data processing to 474 00:38:09,320 --> 00:38:15,599 understand which variables are related. For example, so I can't just say this 475 00:38:15,760 --> 00:38:20,599 is slow. This is not slow, because maybe it's low when a lot 476 00:38:20,679 --> 00:38:23,320 of users are online right right, So that's where are the open tell emergy 477 00:38:23,400 --> 00:38:28,039 data comes into play. Yeah, so you need to correlate those that data 478 00:38:28,119 --> 00:38:31,559 and to start coming to conclusions about what's the root cause, where where is 479 00:38:31,599 --> 00:38:36,840 the bottlenetwork when did this problem happen? And what is it related to? 480 00:38:37,880 --> 00:38:42,559 And all of these questions are great questions that require a lot of heavy lifting 481 00:38:42,679 --> 00:38:45,800 or cognitive efforts to answer. So how does it and that's where AI comes 482 00:38:45,800 --> 00:38:50,440 into play. How does it integrate with visual Studio for example, like what 483 00:38:50,559 --> 00:38:53,760 are the kinds of things that a developer can count on? So regarding Visual 484 00:38:53,800 --> 00:39:00,599 Studio, the idea and we haven't launched our Visual Studio play and yet right 485 00:39:00,639 --> 00:39:06,559 now we have a base cut plug in and the Visual Studio plug in is 486 00:39:06,639 --> 00:39:12,960 end development. We just support Rider from jet Brink. But the idea is 487 00:39:13,079 --> 00:39:19,599 that it integrates into both the interface of the visual studio itself, so you 488 00:39:19,639 --> 00:39:23,199 can always click to see what's happening in this area of the code. It 489 00:39:23,400 --> 00:39:29,519 integrates into the functions so that you can see highlights if there's something critical to 490 00:39:29,679 --> 00:39:36,199 know about the specific area, and it can show you immediate feedback when you're 491 00:39:36,239 --> 00:39:39,719 debugging or troubleshooting, so you can take an action and immediately see, Okay, 492 00:39:39,880 --> 00:39:44,599 this action has happened, and these are the code locations that we're triggered 493 00:39:44,760 --> 00:39:49,519 by my action. So it's kind of a mapping or a map between the 494 00:39:49,599 --> 00:39:52,880 observability and the code. It's just where the machine learning model really comes into 495 00:39:52,920 --> 00:39:57,360 play is being able to make sure it's associating with the right code, so 496 00:39:57,440 --> 00:40:00,079 it's steering you to the right place. Yeah, Yeah, it's machine learning 497 00:40:00,119 --> 00:40:05,159 helps with a lot of problems. It helps with a normally detection, prediction, 498 00:40:06,199 --> 00:40:12,079 trend analysis, clustering, and also correlating the code to specific issues and 499 00:40:12,320 --> 00:40:15,119 right, and I'm nothing. Yeah, I mean a number of times I've 500 00:40:15,119 --> 00:40:19,280 been I've been handed at performance report on something and said, now, go 501 00:40:19,480 --> 00:40:23,559 find the code it's causing this and fix it. You know that those are 502 00:40:23,679 --> 00:40:28,000 much more difficult problems to try and get it to try and have tools and 503 00:40:28,119 --> 00:40:30,159 help you get to the right association. I think make your life a heck 504 00:40:30,199 --> 00:40:32,679 of a lot easier. Yes, you feel like you look at the right 505 00:40:32,719 --> 00:40:36,679 place. I don't know if you are. I don't know how often this 506 00:40:36,920 --> 00:40:40,239 is wrong and you're putting in the wrong place. But certainly I've gone and 507 00:40:40,320 --> 00:40:44,800 fit I've gone an optimized code that made no difference to the problem whatsoever. 508 00:40:45,440 --> 00:40:51,239 Yeah, and and there is a problem here because these performance records tend to 509 00:40:52,880 --> 00:40:57,480 miss a lot of the context. So I got the filming a developers ask 510 00:40:57,599 --> 00:41:01,519 me, I saw there's one hundred per sensipin utilization? That bad or good? 511 00:41:01,880 --> 00:41:06,639 Like? Could I be happy that that that I actually managed to scale 512 00:41:06,679 --> 00:41:10,119 things and parallelize them. So I'm using all of the CPU or am I 513 00:41:10,239 --> 00:41:15,559 being an inefficient There are ways to answer that question, yeah, but they 514 00:41:15,639 --> 00:41:21,239 require more contact or somebody is asking me, you know this process, I 515 00:41:21,320 --> 00:41:30,599 see it's taking forty millisecond. Great? Is that a friend from your takeline? 516 00:41:30,719 --> 00:41:35,920 We should address is it impacting a thing separation and asynchronic separation? What's 517 00:41:35,960 --> 00:41:40,079 going on here? And this is exactly that type of contact that when handed 518 00:41:40,159 --> 00:41:45,599 a performance report, you know, a developer would often shrunk because it's it's 519 00:41:45,719 --> 00:41:49,559 very hard to contextualize it and realize what it means. Sure, And as 520 00:41:49,599 --> 00:41:53,039 a result, we have what we call some sometimes these silos called you know, 521 00:41:53,199 --> 00:41:58,880 the performance expert guys who who know their data dog and graphs and and 522 00:41:59,280 --> 00:42:02,679 you know whatever or two of the d're using and they're great at authorizing that. 523 00:42:04,280 --> 00:42:10,039 But in my mind, this should be democratized with by using these types 524 00:42:10,239 --> 00:42:15,960 of our technologies lack ours like other technologies in our in the market that make 525 00:42:15,000 --> 00:42:21,719 it very accessible for developers, So I don't need to know about graphs and 526 00:42:21,880 --> 00:42:29,159 and plus one the felly and and P ninety five and metingons and what I 527 00:42:29,239 --> 00:42:31,840 can or cannot do about that in order to understand the significance of the of 528 00:42:31,920 --> 00:42:36,519 the data point. Well, you know, often we have exactly the situation 529 00:42:36,760 --> 00:42:40,159 with profilers are complicated enough that you tend to have a team who specializes in 530 00:42:40,320 --> 00:42:44,480 using it. But it would be nice to have everything, you know open 531 00:42:44,519 --> 00:42:47,159 telemeratary city sets is up to the place where we're always telemetrying everything. So 532 00:42:47,360 --> 00:42:51,480 just to be told, hey, this software is not particularly this chunkle codes 533 00:42:51,480 --> 00:42:53,960 ow particularly fast, but it doesn't run very often, so it doesn't matter. 534 00:42:54,840 --> 00:42:58,920 That's fine. As you know, the old forty millisecond one is great. 535 00:42:58,920 --> 00:43:00,480 You know, if you're running something one it's forty mile seconds is awesome. 536 00:43:00,719 --> 00:43:05,880 If you're running a billion times forty miles, is that that good? 537 00:43:07,039 --> 00:43:10,599 Exactly? And you know what this is something I was talking to somebody who 538 00:43:10,599 --> 00:43:15,400 actually works and someone who actually works in an observability company, ironic as it 539 00:43:15,480 --> 00:43:19,920 did, and he told me, look, I manage the king of developers, 540 00:43:20,400 --> 00:43:25,239 and my number one issue is that I see them spending so many cycles 541 00:43:25,320 --> 00:43:31,119 just optimizing for the wrong thing. They go and micro optimize the heck out 542 00:43:31,199 --> 00:43:36,719 of a piece of code that gets called once in a blue moone and does 543 00:43:36,800 --> 00:43:42,000 this set up process that nobody cares if it takes forty minutes or sixte this 544 00:43:42,280 --> 00:43:45,840 other piece of code that's right there. That's kind of every set in mill 545 00:43:45,960 --> 00:43:52,320 second you and you add there will have kind of a ripple effect across every 546 00:43:52,440 --> 00:43:55,679 microservice service and nicolusten because I don't know it's decoding some string or something like 547 00:43:55,840 --> 00:44:00,559 that, and they don't realize it, so they don't And an extra thought 548 00:44:00,840 --> 00:44:07,679 as they add that on the code addition will change his name. So it's 549 00:44:07,760 --> 00:44:12,920 that kind of this on end between you know, what some people might know 550 00:44:13,039 --> 00:44:15,239 about the code, but and what everybody should know about the code. In 551 00:44:15,320 --> 00:44:21,360 harder to to make a confident you're a good profile in getting you down to 552 00:44:21,840 --> 00:44:27,480 here is frequently called code that needs to be faster. That will make a 553 00:44:27,519 --> 00:44:30,239 difference in everybody's lives if it's if it goes quicker. Yeah, but think 554 00:44:30,280 --> 00:44:35,519 about profiling. Profiling is also not continuous. That's something that's usually kind of 555 00:44:35,760 --> 00:44:40,360 the interval thing. And yeast will work it's also constructive tests, so you're 556 00:44:40,440 --> 00:44:45,559 often testing against bad data, right, You're you're building good tests is hard 557 00:44:45,639 --> 00:44:49,960 too, so it's like I have highly optimized this for this scenario that will 558 00:44:50,000 --> 00:44:52,639 never happen, But boy it goes fast when that thing that never happens happens. 559 00:44:53,079 --> 00:44:59,360 Exactly did the did the name digma? Is that kind of like a 560 00:44:59,440 --> 00:45:04,960 play on agma, Like it's not dogma, it's stigma. Uh, that's 561 00:45:05,000 --> 00:45:10,320 a good interpretation the but and it's not that farm. When I was thinking 562 00:45:10,320 --> 00:45:15,679 about the name, I'm mirabue origin and the word and Hebrew for paradilm is 563 00:45:16,800 --> 00:45:22,559 paradigma. I just remember and we got them because for me it's kind of 564 00:45:22,719 --> 00:45:30,760 sable. Right, Wow, that's cool. I this core idea that how 565 00:45:30,840 --> 00:45:36,679 your code random production always appears beside your code. I'm very much enamored of 566 00:45:36,760 --> 00:45:39,159 this. This is a healthy thing that if you are all, every time 567 00:45:39,239 --> 00:45:43,840 you look at code that's been out in the wild, you also see what 568 00:45:44,079 --> 00:45:47,440 happened that this is what it looks like in a while, Because just that 569 00:45:49,039 --> 00:45:52,119 gardening aspect of as your group grew me through the code, you could see 570 00:45:52,159 --> 00:45:57,480 something that would make just draw your attention long enough to make the small optimizations 571 00:45:57,519 --> 00:46:00,880 that might make a difference. It doesn't become a big optim zation ritual just 572 00:46:00,000 --> 00:46:07,199 becomes gardening. And I think that it also goes hand in hand with developer 573 00:46:07,280 --> 00:46:14,639 responsibility is becoming different than they used to. The code ownership is growing, 574 00:46:15,360 --> 00:46:19,800 you know, and and this is something I think we're seeing across the industry. 575 00:46:20,400 --> 00:46:24,760 Developers are doing more and owning more. It's not like it's no longer 576 00:46:24,880 --> 00:46:29,400 a handover process. You mentioned before the QA team from twenty years ago, 577 00:46:29,960 --> 00:46:32,559 where it was Okay, I'm done, you guys take it from here, 578 00:46:32,599 --> 00:46:37,039 and then it's kind of like yeah, and then they do their QA opposite 579 00:46:37,039 --> 00:46:43,119 their OPS and and kind of somehow this tack makes its well way to production. 580 00:46:43,719 --> 00:46:47,159 So continuous means that everybody's doing a little bit more. And developers today 581 00:46:47,320 --> 00:46:52,840 do some QUA under code right, They're doing at testing, they're they're they're 582 00:46:52,880 --> 00:46:57,480 aware of at least of the deployment aspects of it, so they know how 583 00:46:57,519 --> 00:47:01,199 to kind of what resources to require and so on, and how where they 584 00:47:01,280 --> 00:47:06,920 wish to deploy it, what they need from an authorization or in a different 585 00:47:07,440 --> 00:47:12,000 perspective that are more holistic about their code and how to use it and as 586 00:47:12,039 --> 00:47:15,599 a result they become they own it much more. And the question is, 587 00:47:16,199 --> 00:47:22,280 how can you as a developer be expected to own your code when you don't 588 00:47:22,320 --> 00:47:25,440 have the data to do it? Like, how can I ask you? 589 00:47:27,159 --> 00:47:32,599 You know, Richard, it is now your responsibility to own this feature that 590 00:47:32,679 --> 00:47:36,719 you developed it. This is yours. If if this breaks, it's on 591 00:47:36,880 --> 00:47:39,400 your head. And then on the other hand, the moment you released it, 592 00:47:39,599 --> 00:47:44,039 you know nothing about what's going with it. How will I know when 593 00:47:44,119 --> 00:47:50,440 it broke? Yeah? Yeah, So so being aware and involved in those 594 00:47:50,519 --> 00:47:53,559 things is critical in my mind to being Yeah, I just love the idea 595 00:47:53,599 --> 00:47:58,280 that you're always reminded that your code is being used by others. Yeah, 596 00:47:58,400 --> 00:48:00,360 Like, that's that's very That's going to keep you in the right head space 597 00:48:00,760 --> 00:48:05,800 certainly for sure. And and we think about the negative or we mentioned the 598 00:48:05,880 --> 00:48:08,760 negative, but there is a lot of positive feedback as well. Oh yeah, 599 00:48:09,360 --> 00:48:14,559 this, you know, people are using this. I'll give you an 600 00:48:14,639 --> 00:48:17,440 example. We one of the things that we added and thinking about was finding 601 00:48:17,519 --> 00:48:22,599 scaling issues. That's not not not rocket spines, but there's something that's hard 602 00:48:22,639 --> 00:48:28,679 for somebody to do manually, which is basically correlate let's say concurrency was performance, 603 00:48:28,719 --> 00:48:31,960 and say, you know what, whenever this code is being called uh 604 00:48:32,599 --> 00:48:37,320 with the concurrency of let's say eight request per second, uh, this is 605 00:48:37,679 --> 00:48:40,280 how it performs to request per second, this is how it performs. And 606 00:48:40,599 --> 00:48:44,480 and this is how it performs. And we can start seeing the trend and 607 00:48:44,599 --> 00:48:47,840 tell you the scale factor of this code is is nuts or horrible? Or 608 00:48:47,880 --> 00:48:52,639 we can say after after x amount, there's a lot in or and it 609 00:48:52,719 --> 00:48:58,400 breaks down company causes problems. Yeah, and that's that's important to know as 610 00:48:58,400 --> 00:49:01,480 a negative impact. But then we add the positive feedback as well. People 611 00:49:01,519 --> 00:49:06,960 are using this code. Yeah, this code slaps you know if you actually 612 00:49:07,280 --> 00:49:14,239 I've discovered it will it's one of the most performance scalable areas in the code 613 00:49:14,320 --> 00:49:19,679 so far because you you've done your job right. So if in my mind, 614 00:49:19,719 --> 00:49:23,960 if if you don't also provide positive feedback, it becomes that looking for 615 00:49:24,119 --> 00:49:30,000 trouble sure paradigm where yeah where Yeah, I'm not going to glance in there 616 00:49:30,079 --> 00:49:37,079 because I'm afraid what I'm going to find. Versus this is actually giving me 617 00:49:37,159 --> 00:49:38,960 good feedback about the things that I do. And when I improve things, 618 00:49:39,119 --> 00:49:45,480 then I feel good about it because I can see it as well. So 619 00:49:45,639 --> 00:49:52,239 what's next for Digma. Yeah, so we're not launched yet. We're going 620 00:49:52,320 --> 00:49:58,599 to launch officially in more August, but until then we're running a closed data 621 00:49:59,239 --> 00:50:06,960 So anybody who's interested in more joining at the close beta UM is more than 622 00:50:07,039 --> 00:50:10,360 welcome. We love develop our feedback. This is what we're basing our own 623 00:50:10,800 --> 00:50:16,679 I know feature set on UM and we'd love to have more developers get their 624 00:50:16,719 --> 00:50:20,800 hands on the product and tell us what they like and what they don't. 625 00:50:21,119 --> 00:50:24,119 Awesome, I've already signed up. I can't wait. Yeah, that's great, 626 00:50:24,280 --> 00:50:29,599 Ronie, Thank you very much. It's it's a great, great concept 627 00:50:29,840 --> 00:50:34,199 and I'm looking forward to seeing the execution. It looks great. Thank you. 628 00:50:34,320 --> 00:50:36,840 It was really great being on the show. You bet. Yeah, 629 00:50:36,960 --> 00:51:01,440 and we'll talk to you next time on dot net rocks. Dot net Rocks 630 00:51:01,559 --> 00:51:07,119 is brought to you by Franklin's Net and produced by Pop Studios, a full 631 00:51:07,199 --> 00:51:12,519 service audio, video and post production facility located physically in New London, Connecticut, 632 00:51:12,800 --> 00:51:17,239 and of course in the cloud online at pwop dot com. Visit our 633 00:51:17,280 --> 00:51:23,199 website at dt n et r ocks dot com for RSS feeds, downloads, 634 00:51:23,400 --> 00:51:28,320 mobile apps, comments, and access to the full archives, going back to 635 00:51:28,400 --> 00:51:31,880 show number one, recorded in September two thousand and two, and make sure 636 00:51:31,920 --> 00:51:36,599 you check out our sponsors. They keep us in business. Now go write 637 00:51:36,639 --> 00:51:40,440 some code. See you next time. We got Van do