How'd you like to listen to dot net rocks with no ads? Easy? Become a patron For just five dollars a month you get access to a private RSS feed where all the shows have no ads. Twenty dollars a month will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin Richard. Here. As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Oslow
will be made twenty first through the twenty fifth. Go to NDC Oslo dot com to register. NDC Copenhagen is happening August twenty seventh through the thirty first. The early bird discount for NDC Copenhagen ends June second. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. The early bird discount for dc Porto ends July twenty first. Go to EDDC Porto dot calm to register and check out the full lineup of conferences
at NDC Conferences dot com. Hey, guess what it's Dot and Net Rocks. I'm Carl Franklin and I'm Richard Campbell. And this is the beginning of a long run over a few days of show recordings that we have to get in the can because we're gonna be busy, we're gonna be traveling again, and so it's good too. I sort of organize it. I think I said to you in between recordings last week, because we're just doing like a show or here, or they're just staying a week or so ahead. It's
like, I'm gonna load up a bit. We'll see what happens here. I've got a few emails going out, and then in fairly short order I kind of said, hey, sorry, this is a lot of shows. But yeah, it's also fun. Yeah, sure is, you know, to just sort of focus and have intense conversations about great technology. So I'm really looking forward to this flurry. And then we'll be doing some on stage and live shows and in person shows coming into spring conferences. That's right,
Techarama for one yep around, we'll be one of them. Yeah, And when is dev Intersection again? The next dev Intersection is the first week of December in Orlando, Ah that's gonna be fun. So we're going back to Orlando. We're in the Swan and the registration's opening up shortly. Still working on some curriculum and stuff, but you know, we got some time.
I got some crazy keynotes because you know, you think about how much has happened since chat GPT in November. Oh, I know, yeah, crazy, and here we are in April. Now, think about what it's going to be like by the end of the year. It's gonna be insane. I mean, it already is insane. I don't know, it could go either way. This is quite the hype cycle. Yeah, well, let's get things started with a little thing we call a better note a framework.
Awesome, all right, man, what do you got? Speaking of chat GPT and all that great stuff and hype cycle and the hype cycle and the hype never ends. Everybody's jumping on the hype bandwagon. Here Google announces AI features in Gmail docs and more to rival Microsoft. This is an article in
The Verge March thirtieth. Google will soon offer ways to generate text and images using machine learning and its workspace products, as part of a scramble to catch up with rivals in the new AI race, right, Yeah, this is the logical hit back, right of course, because Microsoft goes after search with being AI, so Google goes after office with features in Google Docs, yeah, sheets, etc. That's one of the few places that Google can really
scare Mike or soft right. Yeah. Yeah, one would argue everything to happen in office. Three sixty five, now, m three sixty five was about competing with Google's docs online Google Docs. Yeah, yeah, I use it all the time. Yeah, just because it's easy. Well, I think about the number of times you and I have been writing simultaneously in a Google Doc for like an ad script or any sorts of things. And I even use that feature in our admin app. Yeah. Yeah, that same
affect good old signal arm. Man. The thing that's the thing it interests me is is this, like Bard, is this a forever beta a Gmail? What's beta? Forever? Wasn't it? Yeah? For sixty years? Seven years? Like six years? Yeah? You crazy? I get that, they're responding. It's the question is when are you going to release it? Because I'm in Canada. You can't use Bard in Canada. It's not
can't even take it out for his bit. I gotta tell you, I was talking to one of my customers just a few days ago, and he said, uh, boy, tell you what, man, chat CHPT is just saving my butt, saving so much time, you know for little syntactical things like how do I do this? How do I do that? Yeah, it's pretty good. Just make sure you test it thoroughly. It's actually correct. And the question is is that special chat GPT or if he'd bought
grammarily, would he have gotten the same thing. Oh, I don't think grammarly can do link queries, but certainly chat gpt ken. Yeah, that's true if he's writing code versus writing copy. Yeah, yeah, code. It's really great for code. Yeah, you just got to make sure that you know it's good. Is it big? Is it better than get hub copie? Yeah? I don't know. That's a man, what a great
comparison to do. Yeah, we ought to do that. There's so many believe me, and I don't want to make this the all large language model show. No, no, no, no, this is just the intro. Here. There's lots of there's lots of talk about Brown. He's coming right up here. But before we bring him on, who's talking to us?
Richard grabbed a Comma Top of Show seventeen ninety. That's the one we did with Chris Kluge when we were talking about his experiences doing experiments with different infrastructure as code Solutions, Terraform and BICEP and Pullumi, and of course that had that ended up in a conversation about the DevOps cycle as whole automating of builds and so on, which is really you know, part and parcel with trying to make your software better and Devil Goel had this great comment from last
year. He said, my hot take on DevOps is that too many practitioners start off with rigid, preconceived notions of what they want to do. This is normal. Our decision making is always going to be shaped by our scars. We've used that line before. Oh yeah, old favorite. Yeah. However, it helps to approach devots technology, like any technology, with an open mind, start by looking at whether or not the out of box functionality
is sufficient and if not, why, Yeah. You know, we always tend to want to mold the tools to our vision of what it's going to be, rather than just use what's there. And here's a line that I loved, are the scars running the show? Wow, there's always going to be some amount of custom work that needs to be done, But our first step is always start figuring out how to get the pipeline to run a custom Bash or PowerShell script. You're probably doing something wrong. You aren't that special.
If the canned features can get you most I done all the way there, you should start with those. They almost always are going to provide decent air handling, logging, and parameter checking, especially if their first party offerings. Keep in mind that there are going to be differences between green Field and Lift and Shift that might require some extra work. I like to think this way in any cloud project. If step one's great an Azure VM and install
a sequel server, you're probably doing it wrong. Devon's gotten gotten. I checked back and saw we've exchanged a few emails before. He's received music code By before. But Devin's such a great comment man, so thanks so much for commenting. If you'd like a copy of Music go By, I write a comment on the website at dot at Rocks dot com or on the facebooks. We publish every show there, and if we comment there and I read
it on the show, we'll send you a copy Music go By. And you know you can follow us on Twitter, but we'd really like you to follow us on Mastodon. I'm at Carl Franklin at tech Hub dot social, and I'm Rich Campbell at mastodon dont social and send us a two we'd like to see there. My tutors are growing. Let me say that. Can you say that you need to bleep that? No, I don't think so. Tutors man, your tutors, my minions of tutors, well, you
know that they're just followers like two thing else. I started this just at a couple of months ago maybe and got about twelve hundred followers now, so that's really good. And I always follow whoever follows me. That's just the way it goes. Well, anyway, let's bring on Rony Roni Dover is a holistic developer and builder with a passion for development processes and practices. Afflicted by an acute product manager slash developer split personality disorder that was never treated.
There a cream for that. I don't think there is. I don't think so. You got to go into the office. Currently CTO and co founder of Digma Digma dot ai, an ide plug in for code runtime AI analysis to help accelerate development in complex codebases. A big believer in evidence based development and proponent of continuous feedback in all aspects of software engineering. Welcome Ronie.
Hello, Hello, great to be here. When I hear continuous feedback, you know, that's one of the features of being in a state of flow, isn't it. Yeah. We heard about this great book Flow by Mehi Chicks and me Hi from Mark Sieman many years ago, and you know they talked about people fileting fish, you know, all day long at the market a Pike's Market. You know, the guys who are just like fileting salmon and they're just in the zone. But that state of flow gives you this
continuous feedback and that really allows you to go fast. Yeah, and maybe before I dived right into it, I just want to touch on your previous discussion about AI and AI systems. Oh sure, Yeah. I was just having a casual conversation with a friend and we were trying to estimate just how much code exists today in production systems. That was written by AI and maybe nobody even took a look at it, like no no human intervention. And you know, you could say the same about tack overflow. Or you know,
they said back then, coppy taste that type of development. But the more abstract the AI. And I'm a big proponent of AI, and I'm using it a lot myself, But the more you kind of abstract the request from the AI and kind of remove yourself from the generated code, it becomes less about snippets or regular expressions or linqueries and you can actually, you know,
request entire business logic being implemented. That's right, and and that's amazing to me, and to me it's also very poignant and relevant to the to the topic of feedback, because essentially, you have a bit of code here, and it doesn't matter if somebody else wrote it, or I wrote it a year ago, or maybe I'm just kind of trying to make my to make kind of this opaque piece of code a little more transparent to me, and it seemed like without that type of visibility, we kind of have a
problem on our hand. And it's the kind of problem that you don't notice until you do. And we were kind of chatting before, and you guys said that over twenty years year on the air, which is amazing. And I've been a developer for more than twenty years and when I got started, at least in the culture of the organizations that I worked around, there was no continuous testing. And I remember it very well, and it was you
know, that's what that's what we knew. There was some testing that you had, out of the kindness of your hearts to run every now and then, but that was just about it. Hopefully you had testers or some sort of QA in your organization, yeah, or QA department. Yeah, But essentially, but that's not continuous, right, They're still taking a bite and you're right, like it it comes down to how how do you describe continuous
Like I would argue that intellisenses continuous for sure, for sure. So so essentially I was we were kind of running blind like today for me, like pushing changes without running tests. As you know, you must be a very brave and I don't know, desperate soul to actually do something like that, but you know that it's it's crazy, or so it seems today. And at the same time, once kind of you you start understanding that feedback is
really essential. Coding without feedback, I kind of feel the same type of blindness that I felt when there was no kind of infrastructure of tests to support me. So what do you mean when you say feedback, Like what are you looking for there? So essentially, today we're pushing code, we're running code, and that code, especially with recent kind of leaps and observability technology, has a lot to say about how it's functioning and how it's running.
There is a lot of data. Bit the question is are we looking at that data? And when are we looking at at data? So let's say I just got um. I pushed an upgrade to the doll system, like I A to the doll or that access. I added that some caching and
some other features around it. I was shocked how many developers, when given such a feature to develop, would go ahead, developed a feature, maybe run a few times, deploy, and let's move on to the next feature, without, for example, examining they did it make life better for everyone? Did it improved the state of the system? And there are many reasons for that, And you know, I just give one example, but you know I could look at numerous cases. And this is something I noticed while
working alongside was very commented developer. And they were given a feature, they developed it, they wrote the test, they did everything. Today you know, they even wrote the helm file or the terror form to deploy it. They pushed that merge to master button and then they they moved on to the next feature. And I asked them, you know, is your code even
getting executed in production? Can you tell me even that maybe you made uh you know, maybe there's one bad IF statement preventing your code from ever being run. I mean presumably they you know you even described it this way. They ran it themselves. Right, You write some code, you run it, like there's your feedback, the compiler compiled it, and it showed up on the screen or showed up, you know in some way. But I think about point of now you push it out, you know, put it
into the pipeline, it goes out of the production. When is the next time it actually those lines of code get executed exactly exactly? And uh, this is something that's uh that's been bugging me. Um. And you know you're right that there is some information that you get out of let's say your debt system, and maybe some feedback you get back from the test, which is mostly kind of limited because it's not qualitative. It's more true false as
failed kind of thing. But when it comes to more non functional feedback and more kind of feedback that has to do with the quality of the code and the impact of your changes. There's very little of that, both from CRI and production and even in Devon. I'll tell you another story. I caught a developer in my team adding a console log statement to a background service. And I noticed it because I'm looking at my code and I'm saying it was
just printing the amount of time that that kind of loop iteration took. And you were you were, you were running your code. You have to call his code and now you're seeing stuff show but your console exactly. Now, First of all, I would like to command that developer because a lot of developers would not do that right, they would not even check for that. It shows that he had the kind of insight to say, this is important to notice as I'm making changes, did this kind of U the discycle increased
dramatically in terms of performance? Why because maybe I made a mistake. It's the wrong technology to do it. Yeah, like he probably a console log would kind of you know, he probably not noticed it forever and it doesn't become a part of it. Have methodology beyond just that one time that that that he added, the console log is the er debug tool for JavaScript,
isn't it exactly? But at the same time, I completely sympathize with the sentiment, and I want, without thinking about adding a console long, for that information to be very as we said before, continuous and proactive, so
that I don't need to think about it immediately. Because my code is running and because I made some changes, and because things are now worse or even better, like I'm I like to get positive feedback as well, that feedback will start streaming to me as a developer, and that becomes kind of my eyes and ears about how my code is running and whether it's running, and again, what is the impact of my change it Because so it's part of
what you're saying there reminded me of this is stuff we catching code review that if you're pair programming, or if you do a code review like I don't know if any other way that really assesses code quality other than other pairs of eyes on it saying you know, there's a more reliable way to write this. You know that that kind of mentality of just like making higher quality code because the law of volvers are still very much in the place of hey,
you know what it runs like, that's good enough. There's no concern about quality. The main quality is it functions exactly. So did this issue UM ultimately leads you to Digma? And yes, yes, exactly. And and did you look for other tools out there? You said, there isn't anything
out there that does it. But what does DIGMA do that's so different from you know, other telemetry products, let's say so, Actually, the origin story is is that I was looking at the DevOps loop, a diagram that by now become you know, completely overused michiels look whatever, you've foreign it,
but it's still kind of a good model of the profit UM. And I was noticing in that particular diagram I was looking at it, it had like at different tools associated was each that was kind of like an equosystem long break now, but you saw the build tools of diploy tool, of continous integration tools, and there was a actually an arrow leading in the other direction. There was an arrow leading from production back into death and it said continuous
feedback. That's what that's what their name said. Yes, and they went out tools associated with that particular error, and that kind of blew me off because I was looking at this Stagram, and there's so many CI tools, so many build and deployed tool, so many monitoring tools. All of these exists. How come when you looked at continuous feedback, what was supposed to bring the information back to the developer. Now we could talk in terms of
was that feedback supposed to go back to the developers? That feedback supposed to go back to the to the pms, as this health features were used, here are the but the errors that we're seeing and then it gets fed into the sprint pipeline as remediations and people aren't using as the way we thought. You know that kind of thing like there is tools and the ear right,
but I think that we need to separate the types of feedback. And as I was saying before, and you actually mentioned it in the most accurate intro that was ever a clearly written about me that I have a split personality between
being a product manager and a coder. And at putting on my product manager had for a second, there are graduals as a product manager to understand what my users have gen So from a product perspective, I have, you know, the analytics, the tools that gave me feedback about how the product is doing. From a developer perspective, there is no Google Analytics for developers.
I don't know which parts of my code are being used and how, and I don't understand that this specific area of the code is a major a nexus bubbleneck area that is being used by multiple flows in the system that the routing so much traffic, and I need to think about concurrency here. It kind
of becomes trivling knowledge. So, if anything, I think there is a big gap between that kind of of elegance and richness of the ecosystem available to product managers and the technical feedback that I want to receive, both as requirements as and as kind of or feedback back on my work that's available from a technical perspective to the perth. So ray gun doesn't do that. For example, I'm just thinking off the top of my head, you can't tell raygun
to analyze bottlenecks and report back to me timings and things like that. Sure, there are a lot of technologies, but what I found out when I to developers is that montyas feedback is not something they past meaning when you talk to most developers. Although there are many dashboards and many kind of nice ways to visualize the data and you know, and to be frank, this caught me so off guard as a developer that I spent half a year just research
this. And by researching, I de meant talking to as many people as I could, and you know, trying to get to the rook of the problem. And I found out two very simple things. First of all, developers are busy, mostly over work, and they don't go looking for trouble. This is why developers did right out of the kindness of their heart, unless it became continuous and it became something that had to happen. And in the same way, developers won't go looking for trouble in the dashboard if it
means another kind of headache that they need to fix. Right, you work your burn down chart, and if you've got somebody in forcing code coverage, then you do enough code coverage to keep you out of trouble. That that is such a true statement there. Developers don't go looking for trouble. So talk about security like, we don't like security. That's just telling me what I can't do. We don't like somebody telling us, oh, this code could be improved if you just did this and that you're like, yeah,
yeah, get around to that. Shut up, you know, get a little fragile ego. Well, mostly because I benefit from shipping features. Yeah right, right, But but you know we've said this before on the show many times, Richard, if you want to be a good developer, lose your ego, right, because it's all about having the best code and having tools that point out you know, this could be better. It's actually making you a better programmer and making your products better for sure. So yeah,
truer words were never spoken. Developers don't like to go looking for trouble being. And by the way, I completely shared that sentiment, you know when when when when I stopped talking on podcasts and I start coding. Uh, it's it's the same thing, you know, I feel and what I like moving forward to the next new feature. Uh, you know, I like, um kind of a feeling progress. And and if I get sucked into these issues and it just slowed me down, and I'm right consciously motivated to
kind of not necessarily invest in these areas. And this is a problem, and it also requires cognitive effort. And this is the other thing that I know this so you get to some of these realizations like, you know what, as of my last commit, this and this change, this timeout error rate is different than it was before, and this API that I'm using or whatnot? Right, I need to have some cognitive effort and tools and expertise
that not all the developers have. And as a result, you know, my statistics one on one is pretty kind of not as up to date, and many developers kind of well try to ignore it because it's not in their conflicts, I mean, not something that they know and practice every day. And that makes a lot of sense to That's why we have tools. You talk about cognitive effort, it's when you have that feed, that typical debop feed backside. All that lands back on the pms and the feature designers,
the business analysts and so forth. The way it trickles back to the developer is, yeah, the apps too slow, Like that's some cognitive effort like to try and address that problem, say, okay, well where is it too slow? How is it too slow? Like to just decompose these sorts of broad statements into actionable code. That's a lot of effort. You can spend a long time trying to break that down enough to go. This is
the piece of code we need to optimize. You're absolutely right, and time is key here because it takes a long cyc of those context of what you were doing your contact switching. You need to there is this issue, but now it goes back need more information and then develops guys way in and then the IT guy's way in and you go back to the customer and eventually kind of it becomes a very inefficient process. So how does digma address this issue?
Yeah, so the premise of Digma was very simple. It was all of the information is there. The problem is making it proactive and reducing the cognitive effort and making it something that's continuous that fits into my DARE workflow. And if we can use AI to generate code, there is no way we
can't use AI to evaluate the code at frontime. And essentially what Tigma is is a way to is a platform that evaluate the code in WRON time and kind of like a linterm maybe but not for static analysis or dynamic analysis. And it can give you that indication straight away in depth than in test and in production about specific issues that you should notice in your code, specific parameters that you need to know in order to better design it and and and the
concept is that we didn't invent the profiler. We didn't you know, have to add some weird reflection into the code to make it happen. We just used the existing technologies. And actually dot net made it amazingly easy by incorporating hotel into the standard library. As far as System Diagnostic, which you know, to me as as a dotnet developer, was was great. It was great news because it just made it I'm a lot easier to support it within
doctor. So what's built in the dot net that makes your life easier? So as of dot Net, I think it's four point six to eight. They back that they added it backwards or something like that. Un System Diagnostics now supports open telemetry right open telemetry for those who are not familiar with it is a great step forward with observability. And the reason is not that it's doing anything groundbreaking, but that everybody agrees on it and it's open source.
So the combination of these two, you know, it's understated here, but it really becomes a game changer in terms of observability because suddenly, a you can rely on an open standard, then you don't need to kind of support one APM or another APM and their proprietary kind of finicking abstraction. But you have this open source, by the way, very staggeringly popular across different platforms and languages javan js, dot net. You can be a polyglot developer and
kind of benefit from it across your distributed micro services and multiple languages. And it's open and very easy to kind of create an ecosystem around it. And because it's so widely agreed upon, support started kind of becoming standard for any library platform. So aspeed, dot neet, NBC NAT supports it. You don't need to do anything, you just need to turn it on. It's an on switch. If you're using any inframwork, it supports it. If
you're using an adapter for posters, it probably supports it. If you're using mass transit to work with a rabbit and queue or something like that, it
supports it. So that means that taking a project from having zero visibility about what it does in terms of traces, metrics and logs to having almost too much data is a matter of flipping a switch rather than kind of, oh, let's kind of think about it, create a producag the philosophies for like two months about what we want to capture, then implement the let the infrastructure
team work on some infrastructure for that. No, it's it's already kind of out of the bat, and that's a big game changer that makes technologies like what we're doing with stigmas very easy because now we have the data very easy for the user to turn it on, and then it's just a matter of how do we process it and make it relevant. And to make it relevant, we understood that our front end needs to be not a nice dashboard, but the developers tooling, which is the ide the get tops process, this
is where he'll need that information. And so it becomes this kind of a living documentation and something that kind of becomes embedded within the code in so that I kind of take even that cognitive effort of taking opening another tab in my browser and and looking up a dashboard just because I thought I should check instead, it becomes something that just like a lintern, becomes embedded in my it.
Well, now that you've completely piqued her and just we're going to pause for this very important message or too, we'll be right back and we're back for talking Roney about DIGMA. And now that we know what it is, and apparently that you just have to turn it on and magic happens. Is it really that easy? Yes, but I can take no credit for that. The open telemetry and open telemetry and how easy it is to integrate with dot was a very strategic decision by the dot back team and there you know
so many different examples online. It is that easy to get some data out of your application, and there is also so much more depth to that data because now it's not just about logs, it's about logs and metrics and traces and inter correlating them. So it's it's very very easy to get very rich data and start making evidence based decision about your code and knowing what to focus
on and what you need to improve. And it can see back to their product managers who now know that they need to prioritize something because they know it's impact. Give me a typical example of something that a developer might do that UM DIGMA would pick up on and say, hey, you should do it
this way instead. Sure, UM, I'll give you a few. One example that I noticed is especially working with enemy firm work and these kind of absumptions, is you often fall into some coat smells inadvertedly just because of leaky abstractions and such, where you might create let's say an end plus one query or some kind of inefficient query that can be picked up if we analyzed what
was actually happening when you when you're runner. And this is something that's easily picked up, like if you look at the choice, it will immediately jump at you. But to look at it and to know how to do that as a novel, right, and it could be something that has to do with basically how, let's say, how the quode is being used. So let's say I want to make a change in a particular area, and I'm working in a complex environment. So finding static usages is one thing, but
understanding who's using this code in run time is another. And why is that important? Because those are the areas I want to test that I didn't break their flows, I didn't break their APIs and so on. That this is from a usage perspective, Well, that's ultimately what matters. It is not what you thought they were going to query from the data, it's what they
queried from the data exactly. You're taking in a parameter from a user and they're searching on something horrible, but that's what they're searching on, so you know, how are you going to deal with this? On top of that, the you know, the any framework context could be could be described as a wrapper around leakey abstraction and so many ways you can go wrong, especially
when you apply it to the Web. Definitely, definitely. And the idea is once you start getting those types of feedbacks, you start coding a bit more confidently because it's kind of like how then tests behind you. You know that there is something that's actually checking what's happening. And if I change the quarry and I forgot to add an index, I'll see those effects immediately. I'll see them and get notified about them and be able to do something about
it. So rather than wait for that report up the stack of this the app is too slow. I mean, what I find very cool about this, and I'm just looking some of the screenshots and things, is you're you're in studio, you're looking at your code, but highlighted beside it is how this code ran in production from open telemetry data. So you can see that the fifty percent case took this long. The ninety percent case the slowest cases to take this long, so you see the variability in that, like you're
kind of being guided to your problem children exactly exactly. And actually comparing those environments is also really critical. So knowing that let's say this area where I'm having major issues in one environment, visit project production is not getting hit at all in my testing environment, for example, would be some some other insight,
and that's an interesting insight. That's kind of barress environment, just because we have the various different content, right, So all in all, I think that the one way to see how valuable it is for me it was just to turn it off because and you can see that in the screenshot like on the website where you kind of see these code lands and highlights all around your code telling you what's going on here. And then the first thing I do is I turn it off, and and suddenly you know that it's still
there. You just can't see it because that data we didn't invent, We just analyzed the existing one. Yeah, so immediately there Now there seems to be a sort of excuse him here between servicing the open telemetry information and the AI part of the equation. I hesitate to even say that because is it actually a recommendation engine for how to treat it. So the AI is used to do a lot of thang. Now we're getting a lot of data, and the first things and the need to we need to do is make it
useful and data is there's a lot of instances. This took this, this took that. But now you need to start to break it down to clustery in order to understand the main flows that are going through the system. Then to start understanding changes. What constitutes a change. You know, production environments look like a very abstract kind of wall where you just scattered paint all over it. It doesn't look like a nice graph where you can say, oh,
here is that area where the change happened. In order to kind of start analyzing that, you need to make very advanced kind of data processing to understand which variables are related. For example, so I can't just say this is slow. This is not slow, because maybe it's low when a lot of users are online right right, So that's where are the open tell emergy
data comes into play. Yeah, so you need to correlate those that data and to start coming to conclusions about what's the root cause, where where is the bottlenetwork when did this problem happen? And what is it related to? And all of these questions are great questions that require a lot of heavy lifting or cognitive efforts to answer. So how does it and that's where AI comes into play. How does it integrate with visual Studio for example, like what
are the kinds of things that a developer can count on? So regarding Visual Studio, the idea and we haven't launched our Visual Studio play and yet right now we have a base cut plug in and the Visual Studio plug in is end development. We just support Rider from jet Brink. But the idea is that it integrates into both the interface of the visual studio itself, so you
can always click to see what's happening in this area of the code. It integrates into the functions so that you can see highlights if there's something critical to know about the specific area, and it can show you immediate feedback when you're debugging or troubleshooting, so you can take an action and immediately see, Okay, this action has happened, and these are the code locations that we're triggered by my action. So it's kind of a mapping or a map between the
observability and the code. It's just where the machine learning model really comes into play is being able to make sure it's associating with the right code, so it's steering you to the right place. Yeah, Yeah, it's machine learning helps with a lot of problems. It helps with a normally detection, prediction, trend analysis, clustering, and also correlating the code to specific issues and
right, and I'm nothing. Yeah, I mean a number of times I've been I've been handed at performance report on something and said, now, go find the code it's causing this and fix it. You know that those are much more difficult problems to try and get it to try and have tools and help you get to the right association. I think make your life a heck of a lot easier. Yes, you feel like you look at the right place. I don't know if you are. I don't know how often this
is wrong and you're putting in the wrong place. But certainly I've gone and fit I've gone an optimized code that made no difference to the problem whatsoever. Yeah, and and there is a problem here because these performance records tend to miss a lot of the context. So I got the filming a developers ask me, I saw there's one hundred per sensipin utilization? That bad or good? Like? Could I be happy that that that I actually managed to scale
things and parallelize them. So I'm using all of the CPU or am I being an inefficient There are ways to answer that question, yeah, but they require more contact or somebody is asking me, you know this process, I see it's taking forty millisecond. Great? Is that a friend from your takeline? We should address is it impacting a thing separation and asynchronic separation? What's
going on here? And this is exactly that type of contact that when handed a performance report, you know, a developer would often shrunk because it's it's very hard to contextualize it and realize what it means. Sure, And as a result, we have what we call some sometimes these silos called you know, the performance expert guys who who know their data dog and graphs and and you know whatever or two of the d're using and they're great at authorizing that.
But in my mind, this should be democratized with by using these types of our technologies lack ours like other technologies in our in the market that make it very accessible for developers, So I don't need to know about graphs and and plus one the felly and and P ninety five and metingons and what I can or cannot do about that in order to understand the significance of the of
the data point. Well, you know, often we have exactly the situation with profilers are complicated enough that you tend to have a team who specializes in using it. But it would be nice to have everything, you know open telemeratary city sets is up to the place where we're always telemetrying everything. So just to be told, hey, this software is not particularly this chunkle codes ow particularly fast, but it doesn't run very often, so it doesn't matter.
That's fine. As you know, the old forty millisecond one is great. You know, if you're running something one it's forty mile seconds is awesome. If you're running a billion times forty miles, is that that good? Exactly? And you know what this is something I was talking to somebody who actually works and someone who actually works in an observability company, ironic as it did, and he told me, look, I manage the king of developers, and my number one issue is that I see them spending so many cycles
just optimizing for the wrong thing. They go and micro optimize the heck out of a piece of code that gets called once in a blue moone and does this set up process that nobody cares if it takes forty minutes or sixte this
other piece of code that's right there. That's kind of every set in mill second you and you add there will have kind of a ripple effect across every microservice service and nicolusten because I don't know it's decoding some string or something like that, and they don't realize it, so they don't And an extra thought as they add that on the code addition will change his name. So it's that kind of this on end between you know, what some people might know
about the code, but and what everybody should know about the code. In harder to to make a confident you're a good profile in getting you down to here is frequently called code that needs to be faster. That will make a difference in everybody's lives if it's if it goes quicker. Yeah, but think about profiling. Profiling is also not continuous. That's something that's usually kind of
the interval thing. And yeast will work it's also constructive tests, so you're often testing against bad data, right, You're you're building good tests is hard too, so it's like I have highly optimized this for this scenario that will never happen, But boy it goes fast when that thing that never happens happens. Exactly did the did the name digma? Is that kind of like a play on agma, Like it's not dogma, it's stigma. Uh, that's
a good interpretation the but and it's not that farm. When I was thinking about the name, I'm mirabue origin and the word and Hebrew for paradilm is paradigma. I just remember and we got them because for me it's kind of sable. Right, Wow, that's cool. I this core idea that how your code random production always appears beside your code. I'm very much enamored of
this. This is a healthy thing that if you are all, every time you look at code that's been out in the wild, you also see what happened that this is what it looks like in a while, Because just that gardening aspect of as your group grew me through the code, you could see something that would make just draw your attention long enough to make the small optimizations that might make a difference. It doesn't become a big optim zation ritual just
becomes gardening. And I think that it also goes hand in hand with developer responsibility is becoming different than they used to. The code ownership is growing, you know, and and this is something I think we're seeing across the industry. Developers are doing more and owning more. It's not like it's no longer
a handover process. You mentioned before the QA team from twenty years ago, where it was Okay, I'm done, you guys take it from here, and then it's kind of like yeah, and then they do their QA opposite their OPS and and kind of somehow this tack makes its well way to production.
So continuous means that everybody's doing a little bit more. And developers today do some QUA under code right, They're doing at testing, they're they're they're aware of at least of the deployment aspects of it, so they know how to kind of what resources to require and so on, and how where they wish to deploy it, what they need from an authorization or in a different perspective that are more holistic about their code and how to use it and as
a result they become they own it much more. And the question is, how can you as a developer be expected to own your code when you don't have the data to do it? Like, how can I ask you? You know, Richard, it is now your responsibility to own this feature that you developed it. This is yours. If if this breaks, it's on your head. And then on the other hand, the moment you released it, you know nothing about what's going with it. How will I know when
it broke? Yeah? Yeah, So so being aware and involved in those things is critical in my mind to being Yeah, I just love the idea that you're always reminded that your code is being used by others. Yeah, Like, that's that's very That's going to keep you in the right head space certainly for sure. And and we think about the negative or we mentioned the negative, but there is a lot of positive feedback as well. Oh yeah, this, you know, people are using this. I'll give you an
example. We one of the things that we added and thinking about was finding scaling issues. That's not not not rocket spines, but there's something that's hard for somebody to do manually, which is basically correlate let's say concurrency was performance, and say, you know what, whenever this code is being called uh with the concurrency of let's say eight request per second, uh, this is how it performs to request per second, this is how it performs. And
and this is how it performs. And we can start seeing the trend and tell you the scale factor of this code is is nuts or horrible? Or we can say after after x amount, there's a lot in or and it breaks down company causes problems. Yeah, and that's that's important to know as a negative impact. But then we add the positive feedback as well. People are using this code. Yeah, this code slaps you know if you actually I've discovered it will it's one of the most performance scalable areas in the code
so far because you you've done your job right. So if in my mind, if if you don't also provide positive feedback, it becomes that looking for trouble sure paradigm where yeah where Yeah, I'm not going to glance in there because I'm afraid what I'm going to find. Versus this is actually giving me good feedback about the things that I do. And when I improve things, then I feel good about it because I can see it as well. So
what's next for Digma. Yeah, so we're not launched yet. We're going to launch officially in more August, but until then we're running a closed data So anybody who's interested in more joining at the close beta UM is more than welcome. We love develop our feedback. This is what we're basing our own I know feature set on UM and we'd love to have more developers get their hands on the product and tell us what they like and what they don't.
Awesome, I've already signed up. I can't wait. Yeah, that's great, Ronie, Thank you very much. It's it's a great, great concept and I'm looking forward to seeing the execution. It looks great. Thank you. It was really great being on the show. You bet. Yeah, and we'll talk to you next time on dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut,
and of course in the cloud online at pwop dot com. Visit our website at dt n et r ocks dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives, going back to show number one, recorded in September two thousand and two, and make sure you check out our sponsors. They keep us in business. Now go write some code. See you next time. We got Van do