Subscribe
Share
Share
Embed
The Hangar DX podcast focuses on developer experience and learning how different companies solve developer productivity challenges at scale.
www.aviator.co/podcast
Ankit Jain (00:01.41)
Hello folks, and welcome to Hangar DX. This is a podcast about developer experience and how engineering teams solve productivity challenges. I'm your host, Ankit, co-founder of Aviator. At Aviator, we are building a verification platform for AI-generated code that creates guardrails and reduces AI slop So I'm very excited today. My guest is Dr. Michaela, who has spent a lot of time thinking about code reviews, have done extensive research in
Test, build code review techniques for several years. And this not just during the LLM era. So a lot of things have would have changed, and this is something we will be talking about. And obviously, Michaela has worked in Microsoft in many different teams. so it'll be like a lot of interesting conversations around that. With that, Michela, I'm very excited to have you here. Thank you so much for your time. let's why don't we actually do a quick introduction?
Dr. Michaela Greiler (00:59.308)
Yeah, yeah. Thank you so much for having me. I'm very excited to be on a podcast. You talk a lot about code reviews. So I think I'm at the right place and developer experience as well. yeah, so I love software engineering and really working with teams to make software engineering a better experience, right? Like having better outputs, but also how we feel about what we do, our craft, right? How we you know, I I really like to I had this phrasing or when I did research on DX.
doing our best work joyfully right so this joyful part is also something that I value so it's not only about doing our best work right but also joyfully so how can we actually as a as humans get the most out of what we are doing and I think this really leads to better results. There's also research on that right that employee satisfaction in general employee you know experience leads to better outcomes for the business, for the customers, for everybody. So
I really try to focus on that and I love, you know, doing it and I've been doing it for a long time, yeah.
Ankit Jain (02:04.895)
Awesome. There's a lot of things that you've written, but maybe we just start with the current state. You know, things are changing at crazy pace in software engineering than whatever we have seen in the last 20, 30 years. So has your approach for understanding kind of like the code review processes, the value of code review changed in the last year?
Dr. Michaela Greiler (02:11.277)
Mm-hmm.
Dr. Michaela Greiler (02:27.458)
Yeah. So there was definitely a point, it's more than a year ago, that I was like wondering, you know, is code review holding up to all of that? Right? Like, my God, is everything that I know about code reviews, like is it is it still valuable, right? Or do I have to rethink everything completely? And I really try to reimagine code reviews from scratch and and you know the funny place the funny thing is that I'm I'm reaching a place.
Where I'm not far off from the values and the principles that I had before, right? There things are changing that definitely. And I think code review also has to change. but I've been, you know, working with teams on code reviews and the bottleneck that code reviews can become, or the problems and the struggles that people have for 15 years now, right? Like it's it's not a new problem. It's not like, my God, code reviews were, you know, it was such a pleasant you know, practice or easy.
Practice before and now we are struggling. It's more that it's a very valuable practice, but it's a hard practice, right? You have social challenges, you have technical challenges, you have organizational challenges, and all of that existed before large language models, right? But now things are, you know, getting more serious, right? There is definitely more pressure on code reviews. We see it with data, right? Like larger PRs, more PRs. so you know, teams that don't have their ducks in a row.
definitely, you know, ha have more problems than they had before. And people had problems with code reviews even before, right? So we we have to rethink. And I'm yeah, but interestingly I'm I'm sort of leaning back to the things that I valued before, right? Like for example, really thinking about why we are doing this, like what is the outcome is something like one of the principles that I, you know, taught in workshops five years ago.
Right. When a team was coming and struggling, one of the first things that I clarified with them is, you know, what is your goal actually to do code reviews and what techniques, because code reviews, it's it's it's not one thing, right? There are definitely different techniques that you can have. You can, you know, review in person, you can have like a meeting, you can have asynchronous code reviews, right? it depends on you know what kind of part of the code base you're really looking at, and so on, right? So
Dr. Michaela Greiler (04:44.63)
It's not one thing and it has never been. And I think now, one of the things that I definitely went back is like when I went back to the drawing board, I also went back to research, right? So I'm interviewing a lot of developers, I'm working with teams, really studying, you know, the problems that they are facing, the the techniques that they are having to make an informed, also empirical decision on, you know, where should this go? Where are people like really having problems? And I definitely see people have an even more fragmented
review practice, right? I don't know if you you're seeing the same, but now with the AI adoption, not everybody is on the same page, right? To put it, you know, lightly. So even within the same team, within the same organization, company, you know, AI adoption is very differently, not from maturity or how much, but also like the techniques that people, you know,
That they do, right? One guy is after one shot approach, right? This is how they think that this would go, right? Like I'm planning in planning mode, and then I have a one shot and only, you know, this is what I'm submitting. Another person is more the iterative guy, right? Like going over and iterative and changing here and there. So there are very different approaches to programming now or to code generation, and the same for code reviews.
And the and the practice gets even more fragmented. And I think with all of that, we really have to put a strategy around all of that, right? Like that we are getting back on the on the same page that we have consolidated practices. Yeah.
Ankit Jain (06:14.301)
Yeah, absolutely. And I think there's also a lot happening in this. you know, there's I think you also mentioned the emotional part of the reviews. given that you run workshops, where do you see the biggest challenge today? Like, I mean, obviously there is this whole you know conflict in some ways between different mindsets of engineers where there are some people who really want to protect and make sure we do reviews properly.
Dr. Michaela Greiler (06:21.952)
Mm-hmm.
Ankit Jain (06:42.303)
And there are many engineers who are like, okay, how do we ship faster? Even leadership is like, how do we ship faster? So where do you see sort of like, you know, this friction sort of like turning out, like especially when you do workshops or talk to p like these companies, how how are you navigating those conversations?
Dr. Michaela Greiler (07:02.486)
Yeah, good question. so maybe maybe one of the and this is more anecdotal, I have some data on it, but you know, I actually just thought today it would be good to have more really quantitative data on that as well. But the funny thing is that when I'm looking at people and their AI consumption and how they're doing stuff, right? It's it's often the people that don't enjoy AI, right? They really hate it. They despite it, that are
Heavily invested, heavily using it, right? Like sort of a, my God, I have to, you know, still have a job in in half a year. So it's it's a very strange, a very strange era in which we are, I would say, right? So I see people that actually enjoy AI more, that maybe use it more moderately, and some people that really heavily use it, but actually despite it a lot, right? So and
And when I and I think it's it's coming back to team culture, right? So what I'm also seeing is that if the team culture, if the team, you know, has very good values on, you know, engineering practices, they somehow find their ways, right, together about, you know, what what are we doing about AI slop, how are we going about this, how do we value you know, code reviews or thinking about that. But there's definitely pressure also from outside, right? I have a couple of engineers that tell me, well, you know.
Don't ask me about code reviews because it's a business decision, which I found a very interesting take, right? So it says like, well, as an engineer, I would like to review the code, right? I would like to do this and that. But in the end, it's a business decision. If you don't want to spend money on, you know, or time on me doing code reviews, then you have to, you know, live with the with the yeah, trade-offs that you have, right? With quality that's going down, with understanding that's going down, right?
so I think it's a how do you say it's it's an interesting conversation, but when you put things in place, right, that where people agree on then everybody feels a little bit more secure. I think trust and psychological security are very important parts of this conversation, right? And if people trust each other in a in a team, you know, that I can say, Well, I don't understand this. I mean this is super important.
Dr. Michaela Greiler (09:27.458)
And then you can experiment, then you can also push large language models to the limit, right? If you're in a team like that where you can, you know, raise your hand and say, you know, we try this, I don't understand, like I this is too much for me. Let's go, you know, step, you know, step a go one step back. I think this is very, very important. And I would probably start with that, right? Like really trying to find out where are people daring to speak their mind and where they are not.
And and then having the conversation together. Very often teams have the same values, right? It's we want the same thing, but we are coming from different directions, right? Maybe somebody pushes AI really hard and you know pushes even code that they don't understand because they feel forced to do it and not secure enough to actually say, Well, no, hold on. This is maybe not the right way to go. Yeah.
Ankit Jain (10:24.179)
Interesting. So how do they find common ground? Like in some ways, I feel like also with AI writing most of the code, many times there is also behaviors where, as you're saying, you know, even the author who published the code or like kind of like sent a pull request may not have read the code themselves, right? Or may not understand the code themselves. So there is two parts, right? One is the trust aspect, which is also something you're talking about, like how do we build trust as a team? I think the other aspect is also the responsibility.
Dr. Michaela Greiler (10:44.302)
Mm-hmm.
Dr. Michaela Greiler (10:51.288)
Mm-hmm.
Ankit Jain (10:54.005)
Which is like who owns the responsibility of this code? Like, are you seeing sort of like places where the you are able to navigate those conversations? So kind of like, you know, teams get aligned on the same sort of, you know, principles, or this is still sort of like an ongoing conversation and it's all over the place.
Dr. Michaela Greiler (11:15.988)
well, this is probably the oldest story of all, right? Like this has really nothing to do with large language models or AI, right? So even before AI, when I was going into, you know, a company, giving a workshop or working, consulting with people, I could probably tell, you know, very much from the beginning how easy or how hard this will be, just based on culture, you know, culture in the company about structures, even who hired me, who wants me to be there, right? Like
If at the the best experiences and and luckily also very often this is how people find me also pro because I position myself like this, is that engineers really reach out and want me to be, you know, part of their, you know, part of their team and help the team understand and consolidate and share. And when that happens, you know, you can really move a lot. You can people come together, you you know, you get them talking, maybe see each other's sides, not saying that everything goes very smooth all the time, right? But
You know, there's definitely common ground and people start to see, you know, that it's it's often not a right or wrong thing. It's just different perspectives, you know, how I am I'm approaching the thing. It's not that seldomly there's a guy saying, well, I actually want this company to go down or, you know, this this code base to be completely full of technical debt. I mean, this is not how it normally works out, right? It's more that maybe you have too much time pressure to actually really read the code or
I'm getting so frustrated by all this AI slop that's sent my way that I say, Well, I'm also not reading that anymore, right? So the you know, there there are when we have you know bad behaviors or strange behaviors, there might be reasons for it, but if we understand and if we can talk to each other, then we can also you know help go in the right direction. And then other companies, like where it's more a different culture, right? Like where we have less.
ability to speak our minds, to say something. You can definitely tell in my workshops, right? They are always the same people. You quickly couldn't tell, well, these are, you know, sort of the leaders, this is like the the technical lead or the managers or something. And they they know they very openly mention their opinions and how things have to go. And you know, others are more quiet or not talking, right?
Dr. Michaela Greiler (13:37.484)
It's very hard to work with them. It's not impossible, but it takes much more time, right? It takes much more time. It takes different approaches. yeah. So and I I see the same for AI, right? Like yeah, at least.
Ankit Jain (13:53.332)
Okay. And and through your workshops, if I I'm just curious, like what is the actual goal, like that kind of like you know, generally like the success that comes out of that the workshop that you run?
Dr. Michaela Greiler (14:06.67)
Well, so the workshop before AI, right, were really about the problems that we had in code reviews, right? So this would be slow turnaround times, you know, people not giving good feedback. You know, it could a a a very common problem was that, you know, some engineers give very detailed feedback, some are not giving detailed, you know, detailed feedback. maybe some teams had really issues with how you phrase the feedback, right? Like maybe people.
Ankit Jain (14:11.681)
Mm-hmm.
Dr. Michaela Greiler (14:34.552)
felt a little bit more defensive or you know, felt a little bit more aggressive in in the in the comments. So those were sort of the the the problems that people were facing, mostly really about turnaround times and this consolidation of the standard, right? Like the very different results that are that are came came out of that. And so we worked on, you know, practices and rethought about, you know, how can we shape the practice so that it fits the software development lifecycle and on on those things.
And more or less, I mean, in AI, it's I would say it's sort of the same problems, but they are much heavier, right? Like, and we also have like it's not only that we have more problems, we actually have more tools as well with AI, right? Because you can actually use AI also to review your code. It's not that, you know, we are not in the same place. We have more PRs, but we actually have very good tools. I mean, large language models are great for reviewing. Not saying that they, you know, I wouldn't go and say, well,
They review and I'm not reviewing because this brings other problems, also for understanding, you know, building a mental model of your code base, alignment on all of that, right? So you're missing out of that. But they can really get rid of a lot of the problems that maybe don't need human attention, right? So we're in we're in a new era, right? And but it's the same thing. It's like, so why are we doing this? and where is it needed and how is it needed, right? And with this pregnant.
fragmented places, right? I really try to help people understand, depending on where they are on their AI journey, how code reviews could fit into their development lifecycle. How could we, you know, do it in the most efficient way, right? So that we are not spending time set, you know, arguing things that actually machines could do, which I always found stupid, right? Like there were, I mean, how many teams I had in my workshops that weren't using the automation that we had?
Ankit Jain (16:22.189)
Yeah.
Dr. Michaela Greiler (16:28.61)
let's say three years ago, which was also strong. Like we had good static analysis, you know, like you could have linters, you could have style checkers, and a lot of teams wouldn't have that and would have people, you know, look for those things. And I'm like, why would you do that? Like spend your human attention where it's really needed. And now we have different tools, but you know, same problems, just bigger, I would say.
Ankit Jain (16:51.669)
Right. Interesting. So you also mentioned a concept in some of your writings about code review surrender. Do you wanna do you wanna share a little bit about that?
Dr. Michaela Greiler (17:00.076)
Yeah. Yeah. Yeah. So yeah, code review surrender. Well, it's there were two concepts of phenomenon phenomena that I saw when talking to people, working with teams, you know, doing research, interviewing people. And one was code review surrender, which is sort of giving up on code reviews, right? But it's not a deliberate thing. It's not like, we have this great strategy in place, so we don't need code reviews anymore. it's more like
Well, this is not working, right? So it's a window dressing activity. We just pretend to do code reviews, but you know, I'm wading through this large PR or MR or whatever you're using, right? and I try to understand what's going on and, you know, be smart. but the fact is that I d don't really know what's going on, right? And so this would be code review surrender. it could be silent, so people are not talking about it, right? It's just
You know, one looks good to me after the other, and maybe I find one thing that I can, you know, nitpick on or say about this so that I seem to be participating. or it could be also that teams really say, well, we we can't do it anymore, right? And so they they circumvent and and do something else, but without a strategy in place, right? To say, well, all these goals that we had, because if you think about code reviews, I mean they're maybe a little bit overloaded as well, right? Like we have bug finding.
We have accident prevention, we have mentoring and learning, we have like tracing and tracking, we have knowledge sharing, right? All of that. We want all of that out of code reviews, which I thought like this is crazy, even before, right? This is one of one of the things that we always start in my workshop. It's like, well, you want all of that all the time at the same time, which is, you know, it's almost impossible you would have to spend so much time doing it, right? So let's be a little bit more juicy here, which is hard.
But you know, life is hard. And what do we want to get really out of these code chains when we look at it, right? yeah, and code review surrender would be like you're giving up on those goals and just say, Well, we are you're shipping without looking, or we pretend to look most of the time. but yeah, not really looking, yeah.
Ankit Jain (18:54.282)
Yeah.
Ankit Jain (19:12.67)
Right. Interesting. So do you imagine a world where we don't do code reviews anymore? I feel like there are already at least many of the AI labs or startups who have sort of like claimed that they don't do reviews anymore. What do you think sort of like, you know, and especially there's also these concepts of software factories. people also talk about dark software factories. what are your opinions or like kind of like you know, if you were to think about near future?
Are are there a place where there is no code of view anymore?
Dr. Michaela Greiler (19:47.959)
Yeah, it's a good question. I'm really investigating that right now heavily. So my take is that if we let go of code reviews completely, you know, we would completely miss out a lot. And it's not possible, right? So it's not possible. I mean, we would have to imagine a world where everything is done by agents, right? So but also this means, you know, requirements engineering done by agents, right?
the idea of the product, the creation done by agents, right? Because where do you stop? I mean, now what I see is we are shifting it left and right, right? So code reviews are that's what I meant with it's fragmented, right? So we somehow start earlier. I actually wrote about that if you go on my website, https://www.michaelagreiler.com/scope/ Scope is sort of the new code review model that I'm proposing. I actually called it change oversight instead of code oversight. So
scope stands for staged code oversight with proportional escalation. Sounds very fancy. But what it means, what it means is that if we think about code review, right, I'm thinking more that we have code oversight or change oversight, and that we have it at different stages. And a lot of the stages will now be before implementing, right? So which is weird. It's like not code review anymore. It's we start looking at something before it's even created in the coding phase.
and so I think it's it's it's going to the left and it's going to the right, right? so you have, I would say planning, for example, would be a good place to start thinking about the code, right? And deciding about the oversight that that should have. And then this proportional escalation part is also interesting. which means I don't think that each code change needs the same oversight, right? So some code changes they have more high risk code.
For example, they need more oversight. And some have lower risk. They need less oversight. But risk is not the only thing that we should decide on how much review we do. Alignment as well, right? Understanding. So, how much understanding need does this need? Or, you know, alignment does this need? it could be that it's low risk because it's not impacting a lot of users. but for our architecture, it has a lot of impact, right? So we want people, engineers, good people.
Dr. Michaela Greiler (22:12.706)
To be there in the line on this decision, understand that this happens and also that they are okay with it. And so this is sort of how I how I envision code reviews and that they will get, right? So the code review itself, I think it will get less. And I think that's also okay, right? We don't like if I if I know, if I looked at the plan and reviewed the plan, and I know that there is enough detail to it, right? And then I have the output of the agent and I have AI.
you know, agents review that, maybe I look at the output of those, right? And I then it not every code change will, you know, will need me to go through each line of code probably. Right? Some simple things I think we can maybe just hand over. The same for peer review, right? Like I think when we it it depends a little bit like
Ankit Jain (22:55.338)
Interesting.
Dr. Michaela Greiler (23:04.662)
It's very difficult to say this is a generalization because it depends how people implement their AI usage, right? Some people really have like this factory model where we would say, well, there's a ticket, and the ticket nobody looks at, and it goes in, right? An agent implements it, another agent reviews it, and out comes, you know, something and it goes directly to production. Well, where are we there? Right. Like we're very at the end. Could be very expensive as well. when you're when you're deciding, well, now we have to roll that back, even with AI.
Ankit Jain (23:24.095)
Yeah.
Dr. Michaela Greiler (23:33.217)
I wouldn't go for that one. But let's say if we are adopting changes from an agent, right? It's still very different than if we're steering an agent, right? So there's more control in it. When you're steering an agent, right, if you say there's still a developer that maybe looked through the plan, you know, very carefully, and then gave the plan to a large language model of your choice, right? And then maybe looked a little bit through the code. Even there, you don't have to look at
every line of code, maybe you know, right? Like I mean, if it touches that, I know this this is gonna work out. But you know, people know the failure models if they work with large language models more and more, right? So I also think that the checklist of code reviews will change and need to change. And so when they look through it, there's sort of a review. I I see this and this is also what I depict in in scope, right? This back and forth between the you know large language model and the developer that steers it.
Ankit Jain (24:06.865)
Mm-hmm.
Ankit Jain (24:16.073)
Interesting.
Dr. Michaela Greiler (24:31.458)
That's part of a review, right? It's different than you writing code for three weeks because this is done, you know, like in in half an hour. So you have to review the code. So you're actually reviewing the code. And I think this should be honored. So if you're bringing in a new peer, they probably don't have like the context of that. Something that was first created for a week, now just created in half an hour. But still to comprehend, right, it's very difficult. So they shouldn't re replicate what the developer did here.
Ankit Jain (24:59.839)
Interesting.
Dr. Michaela Greiler (25:00.234)
But they should bring a different challenge, right? An independent challenge, bring their own background. So I think there we have to rescale a little bit and start understanding, you know, what are the right questions to ask at each of those stages? And how much do we need? I think for some changes, we don't need another developer, right? It's enough if one developer intimidately knows what's going on here, right? Depending on risk and alignment. and then we don't have to have another, you know.
Teammate, for example, look over that. And for some other changes, I think it would be very valuable and would be a bad choice not to have that. And people would miss out. I mean, not saying that you can't do it, but there are always costs to it, right? Do you want to swallow them or not? yeah.
Ankit Jain (25:43.124)
Right. Right interesting. So, I mean, this also aligns a little bit with like how I am thinking about code reviews, like some of the things that I'm talking about as well. the one thing I'm curious about is why hasn't it been like this kind of like model has been adopted widely yet?
Dr. Michaela Greiler (25:51.054)
Mm-hmm.
Dr. Michaela Greiler (26:01.536)
Mm-hmm. I think partly it has, right? Like if we think about meter, for example, they at least look at risk and other companies as well, right? So they try to at least get the review load and things like that down with risk-based approaches where they say, well, but this is more incident, right? So for scope and how I envision it, I really think I mean I think that mechanical signals are important.
Ankit Jain (26:07.296)
Mm-hmm.
Dr. Michaela Greiler (26:31.564)
And I would definitely use them. But in addition, I think the human judgment is really important, right? But here we have like very mechanical signals. We did it actually at Microsoft 15 years ago. we had like I was part of the code review team there. And one of the experiments that we did and have rolled out at at that time as well to see, you know, like research how people re react to it was this risk-based indicator, right? So it indicated how much risk or not risk.
Is there for each of the the pull requests. But at that point, I mean it's a long time ago, right? Developers really wanted to know, right? Why, you know, why do you have this signal? What does it mean? And so on, right? So just having like a like a yes or no decision, or you know, a green, orange, red signal, at least at that point.
wasn't enough for engineers, right? Engineers really wanted to, you know, stay in control. And I see that the same. I think people want to stay in control. They want to understand. They want to make their own informed decision. So if you give them some metrics to help judge, you know, whether or not we should review or where should we review, where should we focus, I think it's something that will come. and I well, it's coming also already, right? So
Ankit Jain (27:45.322)
Interesting.
Dr. Michaela Greiler (27:47.661)
Even though Microsoft did that and didn't roll it out at that time, fifteen years ago, Mita is rolling it out. Google is, you know, doing experiments and doing things like this in in that direction as well. So risk based review selection, like test case selection, review selection is a thing I think that's coming and people are definitely playing around with it. yeah.
Ankit Jain (28:08.287)
Very cool. So I know we're coming close to time. So I would like to at least have your opinions on or do you have more general guidance for engineering teams who are seeking better code review practices as a team? They kind of like have collective right incentives. Where should they start? Like what things they can do today or like in the next few days or weeks to actually improve their code review processes?
Dr. Michaela Greiler (28:36.396)
Yeah, so code review processes are quite different than normal engineering processes like writing code or now generating code or even writing tests, right? Testing as well. You can do that really on your own. and partly you can do code reviews, and this is really new, right? With with large language model, partly you can do that also now on your own, right? You don't need another person. You just, you know, ask your favorite large language model about, you know, what do you think about you know?
Ankit Jain (28:49.131)
Mm-hmm.
Dr. Michaela Greiler (29:04.558)
security in this you know area or did I you know did I make that very modular or not right so you get actually feedback there but if you're coming back to your team practice I mean this is what differentiates code reviews from many other practices it's a team practice so it's a lot about sharing being open being transparent and I think especially team leads engineering managers they have a very important role right the role is really to be vulnerable themselves right
model good behavior, model that they maybe sometimes don't know. Like I interviewed so many senior engineers, principals, super smart people, and people don't know, right? They don't have a crystal ball. We don't know will code be important like three months from now, three years from now, will we really read it, right? So I think whoever tells you they know, they're lying. They don't know, right? We don't know right now. We don't know if the technical debt that we you know ship
Ankit Jain (29:49.876)
Yeah.
Dr. Michaela Greiler (30:03.65)
When we are not looking at the code and we definitely ship it. if that will be a problem later on. Some some research is there that backs that up, right? That says, well, if you have technical problems in your code base, the large language model actually multiply that, right? So it's not that they can work nicely whatever with whatever you know, code base you have. You're spending more tokens. There is research on that, right? Limited research, but there is research already on that, that that we can see it, right? Or that the
know that the aggregates problems overall. So I think yeah being very open and transparent about that that we don't know right now what's the right thing and you know also inviting others to you know share their thing well if you're not if you don't feel secure enough to say you know now I have so much pressure I'm shipping code that I don't understand that's a problem I think that's a red flag and the question is
Is your team saying it? I think it happens to a lot of people. The question is, is are they saying it? And how do you react to it? If somebody tells me that, this is not a red flag, it's actually a green flag, right? It's like they dare to say, you know, hold on. we are shipping at the pace that I don't understand and I don't feel good about what we're doing here, right? I think this is a very, very healthy sign for a team for a team. It's more the teams that, you know.
They do and they push and they push and they push and everybody's very confident and my God, I'm such a hero, right? I did the best context engineering and I have the best, you know, agent files and whatnot, right? The best, you know, guardrails. I think and we're more more worried about those teams, right? So yeah.
Ankit Jain (31:32.725)
Yeah.
Ankit Jain (31:45.009)
Mm. Interesting. I mean, yeah, definitely this is more of a people and cultural problem than a tool problem today, right? And I think it'll always be will be, especially when it comes to good reviews and collaboration. But
Dr. Michaela Greiler (31:52.578)
Yes.
Dr. Michaela Greiler (31:57.13)
Yeah, I mean it's definitely also a good infrastructure, right? Having good context files. I think this is all very valuable. Having good, like if I'm going in and helping people with their code reviews, I one of the things that definitely think about is, you know, how how is their harness looking? How is their verification system looking? How is their test suite? Are they good? Are they bad, right? but again, here also there is honesty about it, right? You can have a lot of tests now with large language model that mean nothing.
And you have maybe less test, less less task test coverage, but you know, you have confidence about it, right? And I mean, a lot of things are nowadays incentivized to be window dressing activities, right? And the more we have pressure from business, I mean, first we just had the problem that we couldn't explain technical debt to business people, right? I mean, this was an an ever going on thing. How how do we make sure that we have time to
refactor that we have time to do things proper. And there was this battle with, you know, business side. And now it's even harder, I guess. Right. Like, why, why, why do you need like three weeks if I can wipe code that, you know, in an afternoon? but you know, it's it's sort of the same thing. just harder. Yes. Yeah. Yeah. Yeah. True.
Ankit Jain (33:02.677)
Ha ha.
Ankit Jain (33:13.003)
Yeah, we're definitely living in interesting times. Yeah. Yeah. Awesome. I know we are at time. So, Michaela, thank you so much for your time. This was this is definitely a topic which is very close to my heart as well. And thank you everyone who was listening. If you're interested in developer experience or work in DevOps platform teams, join us at hanger dx. It's dx.community. We also run virtual sessions there. And Michaela joined also one of our recent ones, so she can also vouch for that again.
Thank you so much, Michaela. Thank you for your time. And I'm sure we'll have more conversations about code reviews. All right. Bye.
Dr. Michaela Greiler (33:43.694)
Thanks so much.
Sounds good. Okay. Thank you so much. Bye bye.