A lot of problems that we are facing is due to the interface. We are actually giving somebody else feedback, but we're sitting in front of a computer looking at the tool and having a text box there and we are actually alone. Most people forget that they're actually talking to a person. Understanding and comprehending and changing code is first of all something that we do a lot more than writing code. It takes much more time to do that and it's really hard.
And cultural reviews is one of the things that you have to do that. And what I see is a lot of teams have very fast turn around times, but they are just looking over at the glance, if they even look at it. So it's more window dressing activity. And then a lot of teams, and I think they have more pain points is when it takes a lot of time, it takes very long time.
But the value of the cultivaries are very low, especially for cultivates, because I hear this idea of cultivaries are so bad for our productivity and they're really destroying our whole focus that we have. But I think that's really far from the truth. I think people that are already struggling with their productivity or with scheduling their work, they are struggling more with Cultivates.
Hello guys, welcome back to another new episode of the Technical Journal Podcast. Today I have Doctor Michaela Greiler here, so I'll call her Michaela. So she will be talking a lot about code reviews today. So specifically how we can do awesome code reviews, maybe any new trends recently about code reviews and how code reviews is related to developer experience. So welcome to the show, Michaela. Hello, thank you so much for having me. I'm super excited to be on your
show. So Michaela, in the beginning, I always love to ask my guest maybe 1st to tell us more about yourself, right? So maybe specifically any highlights or turning points that you think we all can learn from you? Turning points, Well I got into programming and informatics and computer science quite late in my like 18/19/20 years old or around that. I think it was 18 or 19 and I came from an art school, right?
So I was actually studying art in my school had a big focus on that and computers didn't play a big part, right? So it was quite adverse to computers. So when I then finished the school and I had to go to university, I was thinking, what should I do? And I think a lot of people thought like psychology would be something that I could do or maybe I don't know, like history, but all of that were things that I could never
imagine myself doing. And also art was something that I really love, still love, but I didn't want to do it for like as a profession, right? So it felt like something that I do for recreation or in my free time, but I didn't want to make money from my art. Felt really like ethically wrong to do that, right? To have somebody tell me how to do my art stuff. So yes, I was thinking what
should I do? And in the last year of my school, I was already attending university classes and I can recommend that to everybody, right? So in the afternoons I was sitting into different classes. Psychology was 1. So I realized this is not for me. Or I was also sitting in a physics class and in mathematics. And I also popped into an informatics class, right, for something about algorithms and transactions and SOLID principles and things like that. And it was really like, I really
like that part, right? Like the kind of thinking. And so I decided I'm going to study computer science. And everybody was like, you cannot even turn on the computer. How are you going to study computer science? And so I bought myself a book, which is not very computer science like, right? And then a bookstore bought myself a book, and then I read about algorithms in a very abstract way at that point. But I decided, well, this is really what I want to do.
And yeah, in the first year, I have to say I struggled quite a bit because there were a lot of other people that know already how to program. I really indeed had a problem with knowing how to turn on the computer, how to go to a website, how to log in and things like this. It was really new to me. So, yeah, it was a steep learning curve. It's pretty that way. But I always felt like this is it's the right thing to do. And I know that there were a lot of people that doubt it and that
I can do that. But I think, you know, now it's almost 20 years later, it was the right decision. It was a good decision for me. And so I would encourage everybody to really try out stuff, even if it's very much not what you are used to do, right? Or what people believe that you can do or what others think about you. I think a lot of people have perceptions about what a person is interested in or what they can do or what they will struggle with, which is not
true. And it's not true, right? So really trust in yourself and try out the things and don't let yourself be discouraged from the opinions that others have about you and your life. Yeah. Right, thank you so much for sharing your story. I think it's pretty unique, right? So even though you started late and kind of like struggled, but I think looking at your career, right, you did a lot of research in the computer science space. So I think that's something that
we all can learn from, right? So don't be discouraged, even though you started late, you can always give it a go. And if you like it, I think anybody can succeed just by following, you know, your passion and working hard. So from all your work, I can see you love code reviews a lot, right? So in fact you have a website called Awesome Code Reviews right? So I think code reviews is 1 aspect that is very important in
software development. Some teams actually love code reviews, but some teams actually dread code reviews. In your specific case, what makes you think that code reviews should be awesome? Well, that maybe it's the other way around. I think that if you have code reviews on your team, they should be awesome, right? They can be very dreadful and as you said, like I would not actually have. I didn't only do my bachelor's in computer science, but I also did my masters.
And then I went on to do my PhD and I was in my PHDI was looking at productivity of developers and how software engineering practices actually help us achieve our goals or not, right? So my PhD was very empirically driven. So we did empirical studies either with static analysis, dynamic analysis, data mining, or also qualitative studies where we interviewed people. And I really like this mixed approach, right? I, I feel that this brings us close as to what's actually going on, right?
So when we do pure studies on looking at the data that we have in front of us, we often don't see the big picture or we don't see really what's happening here. We see a lot of correlations, but we don't understand the causations at all, right? And I'm not saying that we totally understand the causations if you are putting people into the picture, right? But if you're starting to ask them, you come much, much closer than with the correlations that
you have in your data, right? So I really like this two sided approaches where we have mixed research. And from that, that brought matches to code reviews, right? I started then working at Microsoft Research. I did a couple of studies there at Microsoft, which was awesome because we have like all these, you know, we have access to all these teams. You can really work with product teams. Like I worked with Office, with Windows, with Exchange, with all of them, with Visual Studio,
right? So you have access to all this data we had like it was a cloud mine called at that time, right? So we had like all the commit messages, we had the source code, right? We had the error messages, the tracing and tracking. We had all of that, right? We could look at this wealth of knowledge from this data, but then you also had access to the developers. And so I tackled with a lot of different teams, different
problems. And I saw that cult reviews is one of those things that a lot of teams struggle actually with, right? So this awesome cult reviews is something that some teams experience, but a lot of teams are not experiencing that. And what I also saw is that there's no training, right? If you say, well, let's do a test initiative in our company, then well, there are trainings and there are courses and there are books.
And you know, we all know that for testing we have to 1st learn the basic stuff and then we level up and we get better at it. But for code reviews somehow, and still I need a lot of developers, even senior developers that I asked them and they said, well, what do you have to learn about code reviews to just look at the code? And I'm like, well, you have to learn how to code, right? You have to understand code is one of the most difficult
things, right? I think it's much harder to understand code from somebody else than to write your own code, right? If I ask you to write a bottle sort, maybe you can do it, right? And you go through the thing yourself. But then if you read it and you have to understand that's actually bottle sort, right? It could be that it takes even
longer, right? It depends a little bit, but yeah, so understanding and comprehending and changing code is first of all something that we do a lot more than writing code. It takes much more time to do that and it's really hard. And code reviews is one of the things that you have to do that, right? It's the foundation is that I am able to understand the code that somebody else has written and still there are no courses around it, right? There is no training.
People are thrown into that and go on and give good comments to code. And then in addition to this technical perspective, right, that we have to understand the code and we have to know how good code looks like. Or, you know, if there's an anti pattern, we have to detect it, right? We have to have this, let's call it technical knowledge. There's also these social aspects that are going on in Cultivis, which is much harder
than testing, right? For testing, you go and you know how to write good test cases and you know about integration tasks or you know, unit tasks and how to do them. But then that's it, right? But for Cultivis, it's really the interaction as well, right? With somebody else, with your teammates, there are power struggles, their hierarchies, their cultural things happening. So it's actually a vault of problems that people are thrown into without any guidance.
And so I found this topic very, very interesting. So it was for me, it was really eye opening. It was like there were a lot of things that came together. I thought, why is nobody really tackling that right? And I guess a lot of people shy away because it's hard, right? It's a hard problem to solve for teams. There's not one strategy or one technique that suits all different teams, companies and, and, and development practices,
right? And I think This is why a lot of people are not touching it. But I think this is also why I think it's really super interesting and why I love working in the space, love working with teams and trying to find out what their problems are. And this is also where we are now starting to touch the developer experience area a little bit, right? So really understanding what is the experience of code reviews
in the teams for developers? And then how can we tweak and change their practices, adapt different practices so they have an awesome experience that they feel like this is really helping us. We know why we're doing code reviews, right? We're getting all the benefits of the code reviews, not only the drawbacks. Yeah, if I can classify maybe some different software development teams, right. I think many of the teams which
are not mature. So I think the code reviews process probably do not even exist, right, Because they are all about writing code, churning out features and getting it done, you know, release it to the production and things like that. But as you can tell from high performing software development teams, actually code reviews is kind of like the cornerstone of their practice. And in fact it is probably one of the biggest differentiator in order to come up with a high quality software.
So I, I think in your website as well, I can see that you're trying to make code reviews as part of the superpower for any teams, right? And I think it's what you mentioned, we don't have trainings, we don't have probably good metrics out of that as well, right? With testing, maybe you can see the test output, test report coverage, even maybe with code reviews, something that is more abstract and it's kind of like difficult.
So maybe tell us a little bit more, how can we gauge within the team where the code reviews is something that we are still being challenged or something that has actually given us a lot of impact in terms of software development process? Yeah. So when we look at the challenges or the pain points that come with code reviews, there's really a diverse set of problems of challenges that people have, right? It's a sociotechnical
engineering practice, right? So you have the technical problems, you have the social problems, and then also it's a team practice, which is another dimension, right? So we have problems with, it's not only me writing my code, but we have to synchronize with each other, right? We have to make sure that I'm doing it when you need it, right? And the other way around. And that I give you the feedback in a way that you are also able to take it or to do positive changes to it.
But when it comes to code reviewers, what I really like, because it's a complex thing when we look at it, I think that I'd really try to break it down into two dimensions, right? And this is very simplified in the abstract. 1 is the speed dimension, right? And one is the value dimension, right? So I think if teams have the first assessment of their practice, we can look at how fast are we doing cult reviews, right? So what's the turn around time? How is that experience going on?
And then also what's the value that they're getting out, right? And on my website, you can look it up. It's called the Code review Quadrant. I called it that. I try to separate teams into 4 buckets whereby it's very fluxed, right? So you can be somewhere on those two dimensions, right? But what I see is a lot of teams have very fast turn around times, but they are just looking over at the glance, if they even look at it, right? So it's more window dressing
activity. We don't really need that kind of code review, right? We just pretend to be doing something and we're not actually doing it. But it's also not such a burden. And then a lot of teams, and I think they have more pain points is when it takes a lot of time, right? It takes very long time, but the value of the cult reviews are very low. And I see a lot of teams are actually somewhere here, right? And there are a couple of root causes for that, right?
So when it takes a long time, it could be that code reviews are large, right? So you're dreading to even look at them or that you are having problems really understanding the code. So it could be that we are assigning the wrong people to the code reviews, right? Or people are randomly assigned to different aspects. A lot of people do this cross team contribute techniques and they read somewhere online. Right? It's a cool good thing to do and there are definitely papers out
there. That also said, cross team code reviews are awesome. And then they think like, we have to do that, right? And I see that so often for practices around everything, but especially code reviews, right? So we see there are papers out there. I even wrote one of those that said, well, two people are a sweet spot for code reviews, right? So you have to have at least 2 code reviewers and then they put 2 code reviewers at somewhere in the policy of their chains,
right? For GitHub or GitHub or Bitbucket, more whatnot. And then every minor change needs two people to approve, right? And people get really frustrated with any like comic. This is horrible. I, I just did this change and now I have to go through the whole approval process again, right? So I think there are a lot of problems then because it's such a broad practice and it touches so many things. There are many, many bottlenecks and many problems and friction points that people who get
thrown into. And what I urge people always to look at is the reason why are we doing this right? And are we accomplishing what we want to do with what we are doing, right? So for example, I think it's a very valid and very good empirical insight, right? For example, how many people should be have on a code review? And it's nice to know that two people are four eyes, see more, right? And it's actually even six eyes because there is the person that writing it and then you have to
have two ribiers. So it's good. But don't take it like a dog mark and say, well, for every change, there have to be two people, right? So what we want to accomplish, what probably high risk changes, it would be really problematic if bugs go through, I'll probably want to have at least two people that are looking through that change, right? But then if you look at other
research, we see it all. If I'm assigning a person that has never seen this code base before, chances are very low that they are really finding bugs or that they can give me very valuable feedback, right? So, and I have to combine that and think about, OK, then if I have a high risk change here, I assign two people that are familiar with that, right? But then maybe for another code change, I have a different reason to do the code reviews, right?
Because finding box is not the only reason. It's also a lot about knowledge sharing. It's a lot about mentoring, right? And so if I want to mentor, then I will have a very different selection for a code reviewer and, and put that person on it. So I'm giving workshops for code reviews, I'm giving courses for code reviews. And a lot of those things are really understanding the basic and I think empirical research is very, very good to have a fundamental of understanding of
how things work. But then it's about us reasoning about the motivations we have and if the strategies and the techniques that we are, the practices that we are putting in place and also the policies, if they make sense to achieve that. And very often you see a mismatch here, right? So you see somebody had a very good reason to say, well, this is, for example, our policy. And then they put it in place,
but it's not as generalizable. And so then it becomes hindering for this practice to be awesome, to be a good experience. And people are are struggling to re understand and see the value of it and very often for good reasons, right? On the other hand, I have seen teams and I've worked with teams where we could really transform their code reviews, right, make them reasonable and make them a good practice that you're achieving your goals. And then it's an awesome
practice, right? And it's something that can have a lot. And I know a lot of developers that would say, I'm never going to company or never going to accept the offer from a company anymore. But code reviews are not part of the engineering practices. And where they are done in a good way, right? Where you can really learn and build this connection with your teammates together. Yeah, especially in the code base that is large enough where you also have many developers
involved in the team, right? So I think the quadrants that you mentioned definitely makes sense, right? The speed of the code review process and also the value that comes out from the code review process. So maybe since you have been dealing a lot with the empirical study and also seeing a lot of different teams, right, Maybe if you can give us a guideline here, like what is fast enough in terms of code review? Is it the number of days?
Is it within the same day? And what kind of value that people should feel when they come out of a very good code review process? So maybe a little bit of, I don't know, guidance here so that people understand like what does it mean to be fast and what does it mean to be valuable in terms of code review? Yeah. So I think that especially this past, it's similar to how many reviews do you have to have when one cult reviews, right. So I don't think it's good to generalize here.
I think couple of weeks is probably too slow, right? And I think everybody would agree that that's too slow. I think a turn around time within a day is reasonable, right? But then it really depends a little bit on the pace of the company on the team makeup, right. So where are people located? Are they all in the same place, right? In the same city, in the same country, in the same continent, right Already maybe in the same oftenings already remote, right?
So there are a lot of question and very similar to that what I said before, right? There's not one one-size-fits-all strategy here, right? So I don't think there's one code review turn around time that we can say, but this is what we want to achieve. Google, for example, has a code review turn around time from around 4 hours, the upper right, right, which is very fast. And there are probably a couple of companies that are faster, but not a lot, right? Most of them are slower.
But then for example, some teams at Microsoft, they have even a policy that says, well, if you are under 24 hours, you're not allowed to approve this code review because we want to make sure that there are others that are having the time to look at it that for example, in a different time zone, right? So on purpose, there is some struggling in it where we slow it actually down, right? We say, well, and it could be also a lifestyle thing, right? So that we say, well, if you're
going home at 5:00. We don't want somebody to be forced to look at it during the non business hours. So we make sure that there's enough time that people have actually have to look at the thing. But again, I think it really depends on the kind of team that we are working with, what kind of software are they developing, right? So if you have a very fast-paced environment or we can change the software really quickly, I think then code reach should be also quicker, right?
If you have something that takes a lot of time. Nowadays, what I see more and more people struggling with is not even that we are maybe in a different time zone, but nowadays it's even about the pipelines that we are having, right? They're getting big, especially for bigger companies, right, That have a large test suite, for example, that have a lot of code that needs to be compiled, right? So we are scheduling our continuous integration pipeline, which is also right.
So we wanted that. But nowadays we see then, well, this takes really a lot of time, right? So do we want to make this PR now or do we wait a little, a little bit, right? And even the cost that we have for compiled time and for test time and so on, right? So I'm not saying that this is a good reason to slow your code reviews down. I'm just saying this is a new dimension of problems that I see popping up over the last couple of years that's getting bigger and bigger for a lot of
companies, right? It should be fast enough that you don't forget what you're working on, right? So when I work on something and I'm waiting, let's say four days, it could be that I have already forgotten, right? It could be that it's slowing me down and I feel like this is actually too slow. So I would really come back to the experience of people and ask them for how do you feel about it, right? So when you get the code review tomorrow or let's say in two days, do you feel this is
holding you back? There's actually something else that you're working on then. Well, we have to increase the pace, right? If people are actually quite OK with it and they say, well, that's totally fine for our rhythm that we have because we have this kind of work style and I'm working actually on that and this is over there. I know exactly. And then let's say 3 days, it comes back and I have scheduled it and I'm prepared that this is coming back back, then, then that's fine, right?
So I would go back really to the experience of how people are feeling about the turn around times. And this is also when I'm doing a workshop with the team, for example, one of the things that I'm doing with them, I walk with them through a service, through a questionnaire where we get these pain points out and NBC well, actually turn around time is a problem or is not a problem or what kind of degree this
problem is, right? And the interesting thing is also when I'm working, for example, with larger organizations, sometimes it could be that have several teams from different departments on one workshop. And then we would have like this team thinks could we turn around time server actually way too slow. And this thinks it's just fine. But the one that thinks it's too slow have a faster cadence than the one that are thinking it's
fine. And so that's why I think it's really, I would even say unprofessional to say, well, let's say 4 hours, that's what you should do or 24 hours, that's what you should do. But I would definitely think in dates or a day, not in weeks, right? So everything that takes several days, I think is for a lot of people in general a problem, yeah. Thanks for the insights. So I think definitely makes
sense, right? It's highly contextual based on your team set up and maybe the also the pace that you are working with, right. And I think you mentioned a couple of times about experience since you're also part of this developer experience research with Abby Noda and you know Doctor McGrath and story and go for screen, right?
So something that is quite related to developer experience is definitely this code review process and even the state of DevOps report also include code review as part of the factor in the high performing team, right? So maybe in your point of view, right, since you come up with this research from the developer experience as well, how highly correlated is code review with a good development experience that developers are having? Yeah, I think that my answer would be the same, right?
So I don't think that you can really correlate having code reviews with a good experience, right? But they can impact experience in both ways, right? So you can have code reviews that impact the developer experience in a positive and in a negative way, right? So slow code reviews or code reviews that are having a harsh feedback culture, we definitely see that they are decreasing the code, the developer experience, right?
But code review is where we have like a lot of learning going on, a lot of mentoring where people feel safe to talk about. And this has again, to do with psychological safety as well, right? And this is coming up also in the Dora research, for example. Psychological safety is super important for developer experience for high performing teams as well. I came up in that research as
well, right? And also in our DX research, psychological safety and culture were the only factors from all the different factors that are influencing developer experience. But we could see that it has bigger impact than the others, right? So we asked them, for example, because we had like over 25 factors that we distilled in this research and there were more example factors like program management, right?
So how reasonable are the deadlines or how much technical debt do you have or how much focus time do you have and all of that. And, and then we'd wanted to know which are the most important ones, right? And we hope that let's say they are emerging 3. And we can say, oh, those three things is what people should look at, right? But none of that actually happened in our research. People were saying, oh, this is really impacting my developer experience and that.
And so we went through all the factors, right? You know, seemed like quite random depending on different things. And we realized that what's really important for developer experience, it's not one particular factor, but your seniority, right? Your responsibility, the maturity of your company, right, the problems that you're facing. So there were, again, contextual things that are making one or the other factors more important
or not. But the only one thing that came up over and over was culture, right? So people were saying, well, I'm not believing the company for a bad code base or for a lot of legacy code or, you know, protected, but I'm going if it toxic there, right, If people are harsh or if people are not hurt or you know, and this was
very consistent again. So a lot of people said that and I think I want to connect it to cult abuse again, because the cult abuse, this psychological safety is very important, right? So if you have, I think you can have slow cult abuse and it's painful, right? But if you have psychological safety and in order to get good feedback and people really take time to look at your code and mentor you and also see when
you're doing good, right? So when there is this nice experience with the good valuable feedback that you're getting back, this is when it's still OK, right? When it's still improvement to your developer experience. But once you're getting in this power struggles, if you get harsh feedback, right, this is very, very bad for your developer experience. And this is when people leave, right? So this has a big impact. And now I'm just putting an anecdote here that most teams,
right? I have to say that most teams that I'm working with, if you point them to some of the harsh comments or problems that they're having, most of them are wonderful and they say, Oh yeah, I think we're changing that. But then there are some cases, right, that are coming in and they're the most toxic. And the ones that are the most toxic would say there's no problem, right? It's just you have to deal with it.
So it's very interesting for people that I have never seen a team that has very nice feedback that then did, for example, some training on giving respectful feedback that didn't learn something. I have only seen really toxic teams, not a lot, but a couple, right, that are coming in and doing a course on respectful feedback and they're completely toxic. They're saying we are not learning anything here, right? This is not for us, right?
So it's sometimes if you have this toxicity in your company or in your culture, it's really hard to get rid of, right? People are that are very often blindly blind to the problems that are going on. So it's a hard problem to solve, but I think a very important one. Thanks for highlighting again, right? There's no one single factor to actually show good developer experience. So I think like what you mentioned, right, it's a socio technical kind of a situation,
right? So it's highly contextual and sometimes it's about perception as well, right? I think you guys also mentioned that in the paper, right? So developer experience, it's not just about the quantitative aspects, right? Maybe like metrics, the speed or, or the test coverage and things like that, but also the perception from the developer. So don't forget to ask the developers as well. Like what do we they think about
the code review process? So if everyone is get getting any value out of it or is the process is too slow? So I think don't forget that aspect. So not everything can be measured just by numbers alone, right? So I think you mentioned also psychological safety and all this cultural aspect, right? Maybe apart from, you know, toxic commands or maybe some kind of a power struggle that happens. How can people start to think about this aspect more?
Because I think in many teams when they talk about code reviews, they just look at the code and just criticize, right? It could be the wrong algorithm, variable naming, or even could be like the syntactic thing, but you know, like the spaces and the tabs. Maybe some people have these jokes. But yeah. What other aspects that you think is very important for people to switch their mindset? Not just focusing on the code, but also focusing on the psychological aspect and the
cultural aspect as well. So what I have seen and I've even observed a lot of developers doing cultural based and I see it over and over again. I think the problems, a lot of problems that we are facing is due to the interface, right? So we are actually giving somebody else feedback, but we're sitting in front of a computer looking at the tool and having a text box there and we are actually alone. And so now the whole thing
starts. So we are not actually giving feedback to a person, but we are just fitting in text boxes and looking at code. And it's a very algorithmic way of thinking as far right. So I'm looking through the code, it's very hard to do. It needs a lot of praying power to comprehend, right? And I think most people forget, and that's I think totally human forget that they're actually talking to a person. I think this is also why a lot of consultants really hates cult reviews, right?
They discourage cult reviews a lot. And it's a mob programming and formal prominence, well, pair program. And this is the absolute only thing that we can do. And this is the right thing to do. And I think mob probing and pair programming has the advantage that you're sitting next to a person. So it's very, we are reminding all the time that we are actually talking to somebody, right? So for example, for me also it helps that we are using voice now that we are talking, right?
You're not in the same room, but I see your face, you're talking to each other. So somehow it becomes very clear that I'm actually talking to a human, right? And it definitely changes. Like if you would send me a questionnaire with all your questions, I think my answers would be completely different, right? Maybe better, I don't know, because there would be more thought through, right? So maybe I would appear more knowledgeable and more thought through because, well, I did.
But it would be less of a conversation, right? It would be less human. It would be less interaction, would be less conversation. It would be a script. So maybe it's even less interesting for people to read as when they're experiencing me and my thought process just in
time, right? And similar for code reviews, I think this interface that we have that we're actually looking at the IDE or let's say at GitHub or your, your code review tooling, it looks like the IDE you're looking at your computer and you're not actually talking to a person. So what I suggest is if you're giving feedback or we think about how is that valuable to that person and really ambition the person that we are talking to, right?
So maybe before you start your code review, think about, OK, I'm talking now to Michaela, who is Michaela, right? Very quickly, who is Michaela? Is he new in the company or is he new in the team? Or is he a tech lead or what's the situation occur and what value can I provide to her? And that shapes a lot of the, the code real conversation, right? Because it will influence if I'm highlighting this and what kind of words I'm using.
And then when you're doing the code reviews, I think it's OK to go into this very algorithmic thinking and this very technical thinking. And most of the time it's just note taking for us, right? It's like, I think this is wrong or this is strange. I don't understand that, right? So we can make our notes, but then when we have our notes, then think about how would I say that to a person, right? Would I say I don't understand that? Or would I say, oh, can you help me to understand this?
Or how would I phrase that, right? What would I say in this situation? If it's a conversation with a person, unfortunately GitHub and so on, you can actually put in your comments and not send them immediately. But it's dangerous, right? If you reload your Chrome or your browser, then it could be gone. So I'm not suggesting that. But once you've typed in your comment, go back and it takes a little bit. It's OK. Go back and reread it again and then rephrase it.
And if you look, for example, at maintainers at large open source projects, right, if you observe them doing contributes, you can see exactly that, right? So they would write a comment and, and a lot of them that are skilled and experienced, right, they write the comment, it's very technical. And then when you're, they go back to the, to the start and say hello, right, Maybe the name, Oh, thank you for your contribution, right? So it makes it a conversation,
right? So they put down their notes and then they are starting thinking about what the person that I'm talking to. And then we rephrase that. If you look on awesomecultures.com, there is one article that I wrote with tips. I think it's 10 tips and I think they are also very helpful, right? It's for example, not to generalize or phrasing your comments as I comments. So I think or for me or to me, right, So that this is feedback that's coming from you. Another a general statement.
Also, words like just or easy can be very problematic. Code reviews in general, also in documentation, right? So we should avoid them. They're actually plug insurance that you can use in your IDE that help you and alert you when you're using those words, condescending words. Yeah. So yeah, maybe have a look at that as well. So there are very practical tips that you can also use to make your phrasing or yeah up your code review comments better. Thank you for highlighting the
human aspect. Right. So I think, yeah, most of the people, most developers are so accustomed to this code review process where it is async, that's the first thing. And it's tool based, right? Either on the GitHub website or is it in your IDE, right. So they never actually deal with the actual person and it's always async and tool based. So I think bringing the human aspect in is definitely very important.
Choosing the words and go going back and reviewing what you wrote, I think it's also very important. So I think all these are definitely key aspects to make the code review culture kind of like a good one rather than the toxic 1. And I hope people can learn from this experience and this anecdotes that you just mentioned here. So speaking about tools, right, I know that you just mentioned one plug in, right?
I know that there's another plug in to help you do more inclusive comments, that kind of stuff, right? And also these days, there are a lot of automation and AI tools available as well. So maybe from the tooling aspect, can you share a little bit more what is the trend now? Is AI code review a thing now? Is it becoming like you don't need another developer to actually review or you can actually rely a lot on AI? So maybe a little bit of your experience here that you can share.
Yeah, Maybe I start really with the very basic tooling because you said that, right. I think a lot of people, for example, that are in my workshops, they're coming in with this idea that code reviews always have to be on GitHub or GitLab or Bitbucket and have to be asynchronous, right? But that's not true. Code reviews, any form of reviewing your code is code review, right? So you can do it online, you can do it via Zoom, you can do it
next to each other, right? One, I mean, can you maybe often call it over the shoulder reviews right now, which is, you know, you're popping over and looking at the code of somebody, right? And then we have the tooling that obviously help us a little bit to get more systematic or to do asynchronous contribution. Again, I think very important what I said at the beginning, thinking about why are we doing that, What do we want to achieve?
And then using the right tool is a good approach, right? And the right tool is also the right communication channel, right? So if I have a young person there and has a lot of problems with the code and understanding, you know, maybe how we do things in this company, then writing them hundreds of comment in an asynchronous style and sending them over isn't the best approach, right? Maybe I should, if we are in the same office, we should arrange a
meeting together. Or if you are not located together, we arrange a call and we go at the same time through the code and I'm showing, and this is definitely a better way to go about the problem, right? And also to do the code review or to the teaching or the mentoring. But then if in a different, a very different situation, that would be an overkill, right? We don't have to jump on a call for everything that we're looking at, right?
I can just send you an asynchronous code review and it may be a better experience for you and for me. And then we have these tools that I think the tools are wonderful, right? Especially tools around automatic detection of problems, right? They can be very, very helpful. They can also be helpful to get away from this picking aspects of code reviews, right? You mentioned that there was also and said, well, some people
are even nitpicking, right? Like around, I don't know, spaces or do we use this or that. But that can be all easily automated, right? We don't even need the code automated tool to review our code. We can actually have it pre forwarded, right, So that we have all the same style. We can have tools like that in our pipeline. We can have it even in our pre commit works, which I would
recommend, right? We should not put everything to the pipeline and then realize when it's over there that it's failing. Can have that already on our development machine, right? And make sure that even if it's grammar, right? We can have plugins for grammar. We can have static analyzers, right? We can have linters there. And then there are code read tools that do a little bit more, right?
So that using large language models, for example, to understand our code and give us some suggestions. I wrote a black post about a couple of tools that I like the most, right? I'm just randomly now naming some of them. I'm a big fan of GitHub Copilot, right? If you're programming, if you can ask questions, I laugh. Chat GTP. I also like that very much. There are a lot of integrations into your IDE as well for that, right?
But there are also other tooling, for example, that are summarizing, for example, your, your code changes, right, your PRS. And I think this is very vulnerable. I'm not saying that every tool is yet completely there, right? So that we can completely trust them. But I, for example, have for all of my countries, I have an automated summary there as well, which helps me then to reflect and to see, well, did I mention actually everything, right? Is that what we should be doing?
And so I, I actually think that the large language models will help a lot, right? And there will be parts that can be automated and there are already automated and can go away. But there are a lot of things that cannot, right? So it's still, I would say, stupid, and you should never forget that, right? So a lot of people think that AI can think, but AI can't think. It's a language model, right? So it's just pattern matching different things together. So it's still stupid and it can
give stupid answers. And it has a lot of hallucinations, right? So it's making a lot of stuff up. And so we have to be aware of that and use that with that knowledge. And then I think it's awesome. I really love it. I would encourage a lot of teams to really increase the automation that they have in their culture abuse and free the staff up for people to really look again, what we want to achieve with that, right? Do we want the person to tell us
our syntax error? No, we don't want that, right? But do we want somebody to tell us about the business logic or to reason through if we did a good way for performance, for example, right. Yes, we want that. And then having more concrete questions for the code author as well, right? To say, well, or the code reviewer, this is what I want you to focus on. Tell me, you know, did a good job here or this is your expertise. Tell me something about it.
Right, I think yeah, tooling these days, there are plenty of them, right. So starting from the normal static analyzer, right. So by analyzing bugs, potential bugs, right and also including those like the grammar, maybe code review comments. So I think please do check it out like make use these tools. And also the AI part, I haven't really experienced fully AI that can give a very meaningful
critical feedback, right? Most of the time we actually use AI to generate the code, maybe test cases as well, but not in the vice versa where you know, AI critiquing code that we write. So maybe one day we will see such tools exist and maybe even integrate it in the code review pull request, kind of like workflow. So I think automating some of the tedious aspects of code review is definitely very important.
And not to mention, right, if I hear somebody saying about the mundane stuff, to me that feels like an attack from a person to another person. But if it's a computer or AI telling us, I think we can take it lighter. That's my opinion, by the way. So I think, yeah, using such tools definitely will be very, very much useful so that we can have more critical feedback given to the core review aspect. So it could be the design, could be the business logic, maybe
even variable naming, right? Because sometimes it's very important to use like a consistent name rather than, you know, somebody coming up with some terms that is probably unique and new to the team. So speaking about other techniques. So I think in your blog, I see that you also write about 10 different techniques. So maybe if you can also share with us what are some of the techniques that people should probably try out. And specifically, I like the first one that you mentioned.
It's about checklist actually in your blog post, because I rarely see people have checklist when they do code review. Mostly it's like random and they just, you know, jump into the code that they feel like it. So maybe tell us a little bit more few techniques that we can learn how to use. Yeah. So what I've seen, and this is connected to this, there's not a lot of training on code reviews nowadays, right? Or not nowadays in general.
And a lot of people are, as they are supposed to know what they're doing, just do it ad hoc, right? And this is how code reviews are done most of the time, right? So people are just doing it at ad hoc review. They're doing what they think a code review should look like, right? There is no order of piles you should look at. There is no questions, concrete questions that you asked the code for, right?
It's coming from your intuition, from your experience, maybe from what we have seen before that others are doing and so on. And this is called ad hoc code reviews. But there are actually quite a few techniques that we can use to enrich our code reviews, right? So also to make it more thorough and to make it more consistent throughout the teams. So a lot of companies and teams are struggling with various degrees of thoroughness, right?
When people are doing code review, some people just open up the code and they run the code and think this is a code review. I don't even look at the code and it's still a code review, right? Some people will look at every single line and, and understand of that. Some will just pick a couple of files and look if they're there or at some part. So it really there is no straightforward way where we can say this is how hold reviews are
done. But when we are using techniques to do that, we get more systematic approach into it. And the first one, and this is the the one that I like the most because it's very practical, it's easy to implement, it's very powerful, It's checklist based reading, right? So the checklist based reading is you start with the checklist. We can start for example, with one that you can download from awesomecodejuice.com, a general checklist.
There are a lot of different parts we about implementation, right? So is this solving the problem? Is it simple? Is it on the right abstraction level? And what about the debugging, right? Is the debug good debugging, a way to debug this code? Is it testable, the code right? Are they good exception messages and all of that? And what it helps you, you can imagine it a little bit like,
well, a memory aid, right? So you know, these are the parts that I should look at and then they are all checked through, right? And there are a couple of studies around checklist based code reviews and they all come to the conclusion or almost all come to the conclusion that checklist really increase our potential to find problems and increase our ability to find problems in cold.
There's one for example, that's done quite recently at the University of Zurich. But if, for example, looked at to different groups of people and they were giving the same code and then they asked them, well, look at this code, review the code and tell me, you know what's wrong with it. And so people did. And when they said, well, they are done, they asked them again, I'm sure you're done. Yes, we are done. And then they just ask, well, what about security? And they showed them the code
again. And now the people found the security issues that they'd overlooked before, right? So this memory aid is a very, very interesting part of checklist based code reviews and churches based reading, right? And it's a very powerful following. Even the experienced trivia that know about security didn't look at security. They forgot about it. And I think within the same study, they also just tried out mentioning security or mentioning security and then
giving a lot of infos, right? Let's say looking at input validation or cross site scripting and you know, like giving more details and it didn't really change much, right? So what we can see from that is as well that you can only find the things in code reviews that you already know, right? It's hard to learn and do code reviews at the same time. But on the other hand, what we can do is you can use checklist to have a person learn.
Just don't expect them to apply the right in the code review, right? So when you look at, for example, a checklist that I provided, it's very detailed and you can use that for a couple of times, right? And then you would actually make it smaller, right? You would comprise it and and, and make it easier to grasp. Have just a couple of points as a memory 8, and then you can expand another area, let's say security. First. You have just security and you
have five points. But you could actually have a list of 50 points, right, of saying that you should have 50 points. But what I'm saying is that we can expand what we're learning about or let's say our team wants to know more about accessibility. Well, first there was just one point saying have you checked accessibility? Yes. But then you could actually have a whole list about accessibility and have like, let's say 15 criterias where you walk the
people too, right? So we can use checklist in two ways, either just as memorisation for things that we already know or we can also use them to learn and, and and then over time we integrate that knowledge. We are able to find things in coteries. And again we are flattening down this list again and and make it a little bit smaller. Yeah. Right, I like the checklist approach, just like what you mentioned, right? Sometimes we forget what important things that we should look at, right?
So because code review is a little bit open-ended, right? There are so many things that you can criticize, not just the code itself, but also the performance, you know, the variable naming and even like security aspect and things like that. Definitely, if you just jump into it and you don't have a checklist, sometimes it's kind of like random, right, based on the mood and based on the things that you have in mind at that point in time. So I think checklist definitely quite powerful.
And I think there's a book called Checklist Manifesto as well, right, that is highlighting the power of having checklist actually helping you. It's like a memory age, just like what you said, right? It's actually increase the success rate of the things that you are checking or reviewing. So another aspect that I find some people may struggle with is the need to actually jump context jumping, you know from the code that they are working into reviewing other people's
code. So maybe do you have any tips? How do you manage personally juggling between your own code and also reviewing other people's code? Do you batch your time or is there any kind of productivity technique here so that you can also give a good code review for others while also at the same time you can focus on the work that you are doing as well? So yeah, the context switching is definitely a problem, right? And sometimes people
overestimate the problem. I think especially for contributes because I hear this idea of coteries are so bad for our productivity and they're really destroying our whole focus that we have. But I think that's really far from the truth. I think it's one more drop. Either you're having a good handle on your day, on your structure, I think then coteries is not such a big problem.
But for you, I think people that are already struggling dealing with their productivity or with scheduling their work, right, they are struggling more with culture views, right? And I think, I don't think that again, it helps for everybody. It also depends a little bit on the people can have different minds, right? They can have different things that they are striving with and habits that they are striving
with. But I find something that having dedicated time, like for example this Pomodoro technique where we say, well, 25 minutes, you're looking at something, right? It's working for a lot of people. I can actually hold the focus longer than 25 minutes. I like it more. I have normally around 40 minutes timers, right? So I think you can adjust it to your personally needs, but the idea behind it is that that you are starting an activity, you have a timer, right?
Let's say 25 minutes or 40 minutes, whatever works for you. You can try that out. And then this time we really focus on one thing, right? So by example, code reviews, and we are starting now code review and we're doing it, let's say for half an hour. And when there are emails coming in, then we make sure that the notifications are off, right? That we are not looking at the emails or we're not jumping to, you know, something else and doing something else.
And a little bit that has to do also with our setup, right? So let's say we are compiling something or we are running our static analysis and that we know this takes a couple of minutes, then it's really easy to get distracted, right? Because it's boring. So what we are going to do now? And now you're starting a different task. A lot of people have ADHD as well, right?
So then you feel yourself, you're in the, I don't know, a 526 tabs looking at something completely unrelated and then you're having to come back, right? But I think the essence behind is not, it has nothing to do with code reviews per SE, right? It's one more task that you have to do. I think what's more important than what's maybe also trickier is that you have to synchronize it a little bit with your team, right? And this has a lot of to do with expectations.
So what are we expecting contributes to come out? How long are we waiting for culture to come back? And I think a lot of things are expectation management here, right? So that we know, for example, in our team every day, let's say we are sending out the code that we did so far, right? So we are working on something and I know that I'm going to send it out for a review to our
colleagues. So then you know, well, let's say tomorrow in the morning, I'm doing my code review or maybe every afternoon at 4, I'm doing the code reviews, right? So I think this plan, the plan ability and the way that I'm knowing actually this is when things will come in and I can schedule that into my work day. I think this is very, very important, right? And this is not only on you,
right? It's also on the teams that are the people that are on your team that they have to stick to a plan to something that we agreed on, right? And yeah, and I think this is very, very important. A lot of people are coderus just come out of nowhere, right. So I didn't even know. But today 3 came in and then there are three days that none come in and then five come in
and I didn't know. There's a really large form of person who worked on that for a whole month and now they want me to review it. You cannot plan for that. And I think this is really a big problem. But this is more team culture problem, right? Team haven't problem. So that we are giving heads out. You know, I actually worked on that a month. I know I shouldn't have, but I have. Let's arrange a meeting even for that.
And we walked together. I walk you through what I did and then afterwards you can, you know, take your dedicated time and really give me a culture review, right? Next time we do it better, I send you after, I don't know, two days of working. I think there are some of the normal productivity tips work for cultivars, right? Turn off your notifications. Use, for example, some dedicated time that you just look at that don't do something else right.
But a lot of the things that really are painful for cultivars is this team dynamics part, right? So put your code reviews on your planning, right? So that you know, this is when they're going out. This is when I'm supposed to do a code review, right? This is the cadence that we are actually expecting from each other, right? Like every second day, at least I have to send out my code and ask somebody to look at it. Or every day, whatever works for your team, right?
But this plan ability, I think is very, very important. Yeah, thanks for highlighting about the team dynamic aspect as well, right. So I think definitely individually we need to kinda like come up with the workflow that works for us, right, so that we can focus on our work, but at the same time also involved in the code review process. But what you're saying about the team so-called the team working agreement, right? The habit, the norms between each other, right?
How they like code review to be done is something that is also very important. And don't forget again, you can put automated check as well, maybe to remind you if the code review is staling right, so that you can keep each other, you know, following up on the stale code review. So I think there are many tools that you can discuss as a team on how to incorporate them to make you productive. And I like what you mentioned a couple of times by now.
Think about why you are doing a particular thing, right? So the reason behind what you do. So thank you so much for this conversation, Michaela. So I really love the aspects, all the aspects that you mentioned about the code reviews. Unfortunately, we come up to the end of our conversation. But before I let you go, I have one last question that I'd like to check with you. I call this the three technical
leadership system. So you can think of it just like an advice that you want to give to us. So maybe if you can share some of them. So that would be great. OK, So I think the most important, I think in general, right? So if you're a leader or an employee or even outside of coding, it's really to embrace the diversity of people, right? And also how their their minds work, how their bodies work and how we can do our best work, right?
And I think This is why I also really like the idea of the acts of developer experience in contrast to productivity, right? Productivity is all this. They're measuring something that's very elusive, to be honest. And then we are having the same metrics for every person, right? And it doesn't matter what their experience is or what they're actually bringing to the table, right? Because we are measuring one thing.
But on the experience part, it's really more about thinking how can we make sure that every person can do their best work, right? And it can look a little bit more differently for everybody. And based on that, we should also shape our practices to reflect that, right? So as a team, we have to come together and we have to talk and we share our expectations of each other, right? And we can say, well, I want my contributes to be on my table at 4:00 PM, right? That's a request.
Doesn't mean that has to become true, but it's good to be put out there, right? Because this is where I'm in a good state. I can do a good contribute. And then another colleague will share their habits or their way of thinking. Maybe they have ADHD or, you know, maybe they have they are neurodiverse, right? And then you would say, you know, actually, it's really hard for me to read your comments. I would rather have you call me.
And then we, if we have this ongoing conversation and if we are accepting that we are all different, I think we can shape a very nice practice together where we all can do our best work when they're thinking about the other people also that are involved, another of wisdom. And I think this is something that very often strikes me by surprise, that things are less than than we think, right? So for example, you talk about these reminders for cult reviews, right?
And I'm thinking about reminders. This is an old thing, right? Like cult review reminders. We talked about that like 10 years ago in academia and wrote papers about that, but actually just recently that came a paper out that meter now is doing it or Facebook is doing it right? And, and, and it's like surprise, we have now code review reminders and do really work right. So there are a lot of tools out there. There are a lot of techniques out there.
There's actually a lot of empirical knowledge out there that you can take and you can put into practice. Even if you think, well, why has nobody ever done that, right? Like it shouldn't work, right? But actually it works. But nobody he has ever done that. You know, Maurizio as well, right? So I had this conversation with Maurizio Anisha, you should check him out as well, right? He's big into testing.
And we talked about test coverage and test selection and periodization based on coverage and static and dynamic analysis. And again, this is like 15 years ago that I worked on that. And at that point, I thought I shouldn't work on that anymore because everybody knows, right? Like there are so many papers written about it, but it's 15 years later that he's now putting that into practice more and more, right?
Or other people are putting that into practice that a lot of companies that I'm advising or working with still don't have test selection or prioritisation based on coverage information. Or you could now even think about AI, right? Like large language model. So I think we know there's a lot of knowledge out there. But then if you look at the companies and the practices that teams are doing, a lot of things are not done. And actually it's out there and
you have just to grab it, right? You still call preview reminder and try it in your team and maybe it's not working then throw it away, right? But they're really to try out to experiment a little bit. And I think this can go a very, very long way and can increase the happiness of the developers or the productivity a lot. Yeah, yeah. And the last advice is probably the same that I had at the beginning, that we can always change, right? And we shouldn't have somebody restrict us.
And I think it's coming back to developer experience as well. I know that a lot of people, when I was recently had to go to, for example, people come up when I talked about developer experience and how we can change it. And some of them are very discouraged, right? They're like, I try to change it, but nobody is listening, right? Or I try to change it, but it's so hard. And I know it's really hard, right? Like some things are really
hard. And especially if you're doing something new, it's like coming from art school and doing computer science, right? So being in a company that has, for example, let's say some toxicity going on, some harsh comments in your code reviews, and you see that, right? You see that and you try to change it. It's really, really hard. But it's if you're doing it, if you could persistently doing it, just baby stabs, right? It's really worth it if you're able to do it.
And even if you're not able to do it, the deaf company in the next one, maybe you will, right. Yeah. Very beautiful wisdom, so thanks for sharing all of that. I think that people can reflect listening to what you just said just now. So I really love the last part, right? Doing change. Sometimes we can feel like we are against all the odds, right? Like maybe changing the legacy practice or people's mindset and
all that. But I think changing 1 little step is something that is doable for everyone. And also don't forget changing the company. It's also probably the last resort that you can do, right? Let's say you can't change the company. So Mikaela, thank you so much for this conversation. If people like what you said and they want to follow up with you or learn more from your resources, is there a place where they can find you online? Yeah.
So they can go to awesomecodereviews.com and there's a lot of information on code reviews. They can also go to my personal website, which is Mikayla kayla.com. I'm writing there as well about all kind of stuff on software development and also a little bit entrepreneurial stuff. You can also follow me on Twitter or X. Now I'm not so often on X anymore since it's X, but I'm occasionally there as well. Or they can also write me an e-mail, right?
I'm super happy to have e-mail conversations. I also have a podcast, it's called SE Unlocked Software engineeringunlocked.com. So they can also check out some of the episodes there. And yeah, that's, I think that's it. Awesome. So I'll put all of those in the show notes. So thank you so much for your time here. So I hope people learn a lot about core reviews and they can improve their core review process.
But thanks again for that. Yeah, thanks so much for having me. It was really fun talking to you.