#189 - The Art of Awesome Code Reviews - Michaela Greiler

[00:01:23] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have Dr. 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.

Michaela Greiler: Hello. Thank you so much for having me. I’m super excited to be on your show.

[00:01:53] Career Journey

Henry Suryawirawan: So Michaela, in the beginning, I always love to ask my guests, maybe, first to tell us more about yourself, right? So maybe specifically any highlights or turning points that you think we all can learn from you.

Michaela Greiler: Turning points. Well, I got into programming and informatics and computer science quite late in my like 18, 19, 20 years old, around that. I think I was 18 or 19. And I came from an art school, right? So I was actually studying art. 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 this 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. It felt really like ethically wrong to do that, right? To have somebody tell me how to do my art stuff.

So, yeah, so 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 one. 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? Something about algorithms and transactions and SOLID principles and things like that. And it was really like, oh, I really liked that part, right? Like the kind of thinking. And so I decided I’m going to study computer science. And everybody was like, wow, you cannot even turn on a computer. How are you going to study computer science? And so I bought myself a book, which is not very computer science like, right? So I went in 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. Let’s put it that way. But I always felt like this is the right thing to do. And I know that there were a lot of people that doubted 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 everyone 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 things and don’t let yourself be discouraged from the opinions that others have about you and your life, yeah.

Henry Suryawirawan: 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.

[00:05:33] Awesome Code Reviews

Henry Suryawirawan: 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 one 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?

Michaela Greiler: Well, 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 went on to actually have, I didn’t only do my bachelor’s in computer science, but I also did my master’s and then I went on to do my PhD. And I was, in my PhD, I 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 feel that this brings us closest 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 we 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 me actually 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, you 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 CloudMine 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? You 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 code reviews is one of those things that a lot of teams struggle actually with, right? So this awesome code review 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 first learn the basic stuff and then we level up and we get better at it.

But for code reviews, somehow, and still, I meet a lot of developers, even senior developers, that I ask them and they say, well, what do you have to learn about code reviews? You 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. I think it’s much harder to understand code from somebody else than to write your own code, right? So if I ask you to write a bubble 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 a bubble sort, right? It could be that it takes you 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 review 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 code reviews, 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 tests or, you know, unit tests and how to do them. But then that’s it, right? But for code reviews, it’s really the interaction as well, right, with somebody else, with your teammates. There are power struggles, there are hierarchies, there are cultural things happening. So it’s actually a wealth 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. 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 development practices, right? And I think 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 this space, love working with teams, and trying to find really 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 are doing code reviews, right? We’re getting all the benefits of the code reviews, it’s not only the drawbacks.

Henry Suryawirawan: 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, 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.

[00:11:41] Assessing Code Review Practices

Henry Suryawirawan: So I think in your website as well, I can see that you are 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 review is something that is more abstract. And it’s kind of like difficult. Maybe tell us a little bit more, how can we gauge within the team whether code review 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?

Michaela Greiler: 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 socio technical 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 reviews, what I really like, because it’s a complex thing when we look at it, I think the… I really try to break it down into two dimensions, right? And this is very simplified and abstract. One 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 code reviews, right? So what’s the turnaround time? How is that experience going on? And then also what’s the value that we are getting out, right? And on my website, um, you can look it up. It’s called the Code Review Quadrant. I called it that. I try to separate teams into four 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 turnaround times, but they are just looking over at a 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, which is 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 a very long time but the value of the code 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 the 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 code review techniques and they read it somewhere online, right? It’s a cool, good thing to do. And there are definitely papers out there that also say 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 two code reviewers. And then they put two code reviewers somewhere in the policy of their chains, right? For GitHub or GitLab or Bitbucket or whatnot. And then every minor change needs two people to approve, right? And people get really frustrated with it. Like, oh my God, this is horrible. 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 that 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 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 we have on a code review? And it’s nice to know that two people or four eyes see more. And it’s actually even six eyes, because there’s the person that’s writing it, and then you have to have two reviewers. So it’s good but don’t take it like a dogma. And say, well, for every change, there have to be two people.

So what do we want to accomplish? Well, probably high risk changes. It would be really problematic if bugs go through, while I 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, well, 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 then I have to combine that and think about, okay, 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 bugs 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 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 basics. 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 struggling to really 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 are achieving your goals. And then it’s an awesome practice, right? And it’s something that can help a lot. And I know a lot of developers that would say, I’m never going to a company or never going to accept the offer from a company anymore, where code reviews are not part of their 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.

Henry Suryawirawan: Yeah, especially in the codebase that is large enough where you also have many developers involved in the team, right? So I think the quadrants that you mentioned definitely make sense, right? The speed of the code review process and also the value that comes out from the code review process.

[00:18:23] Code Review Speed

Henry Suryawirawan: 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 a 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?

Michaela Greiler: Yeah, so I think that, especially this fast, it’s similar to how many reviews do you have to have on one code reviews, right? So I don’t think it’s good to generalize here. I think a couple of weeks is probably too slow, right? And I think everybody would agree that that’s too slow. I think a turnaround 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? Are they maybe in the same office? Are they remote, right? So there are a lot of questions 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 turnaround time that can say, well, this is what we want to achieve.

Google, for example, has a code review turnaround time from around four hours, the average, 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 without, for example, in a different time zone, right? So on purpose, there is some throttling 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 we are going home at five, we don’t want somebody to be forced to look at it during the non-business hour. So we make sure that there’s enough time that people have actually have to look at the thing.

So, 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 that code review 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 awesome, right? So we wanted that. But nowadays, we see them, well this takes really a lot of time, right? So do we want to make this PR now or do we wait a little bit? And even the costs that we have for compile 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 okay 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 three 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 turnaround 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 survey or questionnaire where we get this pain points out. And then we see, 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 we have several teams from different departments on one workshop. And then we would have like this team thinks code review turnaround times are 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 four hours, that’s what you should do or 24 hours, that’s what you should do. But I would definitely think in days 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.

[00:23:31] Code Review & Developer Experince

Henry Suryawirawan: Thanks for the insight. So I think definitely makes sense, right? It’s highly contextual based on your team setup and maybe also the pace you are working with, right? And I think you mentioned a couple times about experience. Since you’re also part of this developer experience research with Abi Noda and, you know, Dr. Margaret-Anne Storey and Nicole Forsgren, 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 a 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?

Michaela Greiler: 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. And 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, 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, for 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 then we’d wanted to know which are the most important ones, right? And we hope that let’s say there are emerging three 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? It seemed like quite random depending on different things. And we realized that what’s really important for developer experience is 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 leaving the company for a bad code base or for a lot of legacy code or, you know, for tech debt. 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 code reviews again. Because the code reviews, this psychological safety is very important, right? So if you have, I think, you can have slow code reviews and it’s painful, right? But if you have psychological safety and you know 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 okay, right? And 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 it 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, and we are 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? This is 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. And 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 say we are not learning anything here, right? This is not for us, right? So sometimes if you have this toxicity in your company or in your culture is really hard to get rid of, right? People are then are very often blindly blind to the problems that’s going on. So it’s a hard problem to solve, but I think a very important one.

Henry Suryawirawan: 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 not just about the quantitative aspects, right? Maybe like metrics, the speed or, you know, 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 they think about the code review process? So if everyone is 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?

[00:29:13] Improving Code Review Cultural Aspect

Henry Suryawirawan: So I think you mentioned also psychological safety and all this cultural aspect, right? Maybe apart from, you know, toxic comments 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? could be the wrong algorithm, variable naming, or even could be like the syntactic thing. 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?

Michaela Greiler: So what I have seen, and I’ve even observed a lot of developers doing code reviews, 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’re actually alone. And so now the whole thing starts. So we are not actually giving feedback to a person, but we are just filling in textboxes, and looking at code, and it’s a very algorithmic way of thinking as well, right? So I’m looking through the code, it’s very hard to do and it needs a lot of brainpower to comprehend, right? And I think most people forget, and that’s I think totally human, forget that they are actually talking to a person.

I think this is also why a lot of consultants really hate code reviews, right? They discourage code reviews a lot. And they say mob programming, and before mob programming is more pair programming. This is the absolute only thing that we can do. And this is the right thing to do. And I think mob programming and pair programming has the advantage that you are 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? We are not in the same room, but I see your face, we are 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 they 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, right? 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 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, always think about how is that valuable to that person and really envision the person that we are talking to, right? So maybe before you start your code review, you think about, okay, I’m talking now to Michaela. Who is Michaela, right? Very quickly, who is Michaela? Is she new in the company? Or is she new in the team? Or is she a tech lead? Or what’s the situation of her? And what value can I provide to her? And that shapes a lot of the code review conversation, right? Because it will influence if I’m highlighting this and what kind of words I’m using.

And then when we are doing the code reviews, I think it’s okay 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, oh, 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 okay. Go back and re-read 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 code reviews, you can see exactly that, right? So they would write a comment. And a lot of them that are skilled and experienced, right? They write the comment, it’s very technical.

And then when they go back to the start and say, hello, perfect, 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 awesomecodereviews.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” comment, so “I think” or “for me” or “to me”, right? So that this is feedback that’s coming from you, not a general statement.

Also words like “just” or “easy” can be very problematic in code reviews, in general, also in documentation, right? So we should avoid them. There are actually plugins 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 they are very practical tips that you can also use to make your phrasing or yeah, of your code review comments better.

Henry Suryawirawan: 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 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 one. And I hope people can learn from this experience and these anecdotes that you just mentioned here.

[00:35:36] Code Review Tools

Henry Suryawirawan: So speaking about tools, right? I know that you just mentioned one plugin, right? I know that there’s another plugin 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 can share?

Michaela Greiler: Yeah. Maybe I start really with the very basic tooling. because you said it right there. 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 it’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? In academia, we often call it over the shoulder reviews, right? Where we just, you know, you’re popping over and looking at the code of somebody, right? And then we have the tooling that obviously helps us a little bit to get more systematic or to do asynchronous code reviews. And 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 that 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 comments 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’re 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, it 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, and 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 nitpicking 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 a code automated tool to review our code. We can actually have it pre-formatted, 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 hooks, 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. We 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 review 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 blog 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 love ChatGPT. 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 code changes, right, and I think this is very valuable. 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 code reviews, 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 actually think that the large language models will have a lot, right? And there will be parts that can be automated and they 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 we 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 code reviews and free the stuff up for people to really look again. What do 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 review, this is what I want you to focus on. Tell me, you know, did I good job here? Or this is your expectation. Tell me something about it.

Henry Suryawirawan: Right. I think, yeah, tooling these days, there are plenty of them, right? So starting from the normal static analyzer, right? So 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 of 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 code 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.

[00:42:11] Code Review Techniques

Henry Suryawirawan: 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, they just, you know, jump into the code that they feel like it. So maybe tell us a little bit more, a few techniques that we can learn how to use.

Michaela Greiler: Yeah. So what I’ve seen, and this is connected to this, there’s not a lot of training on code reviews nowadays, right? 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 an ad hoc review. They’re doing what they think a code review should look like, right? There is no order of files you should look at. There is no questions, concrete questions that you ask the code for, right? It’s coming from your intuition, from your experience, maybe from what you 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. They don’t even look at the code and it’s still a code review, right? Some people will look at every single line and understand all 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 code 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 one that I like the most, because it’s very practical, it’s easy to implement, it’s very powerful, is checklist-based reading, right? So, a checklist based reading is, you start with a checklist. You can start, for example, with one that you can download from awesomecodereviews.com. A general checklist, there are a lot of different parts, maybe about implementation, right?

So is this solving the problem? Is it simple? Is it on the right abstraction level? What about debugging, right? Is the debug, good debugging, a way to debug this code? Is it testable, the code, right? Are there good exception messages and all of that? And what it helps you is, 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 that 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, almost all come to the conclusion that checklist really increase our potential to find problems and increase our ability to find problems in code.

There’s one, for example, that’s done quite recently at the University of Zurich where they, for example, looked at two 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, are you 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 overlooked before, right? So this memory aid is a very, very interesting part of checklist based code reviews and checklist based reading, right? And it’s a very powerful for, like even the experienced reviewers 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 info, right? Let’s say, looking at input validation or cross site scripting and, you know, 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 it already in the code review, right?

So when you look at, for example, the checklist that I provide, it’s very detailed. And you can use that for a couple of times, right? And that you would actually make it smaller, right? You would compress it and make it easier to grasp. Have just a couple of points as a memory aid 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? I’m not saying that you should have 50 points, but what I’m saying is that we can expand what we are 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 criteria, where you walk the people through, right?

So we can use checklist in two ways, either just as memorization for things that we already know or we can also use them to learn and then over time, we integrate that knowledge, we are able to find things in code reviews and, again, we are flattening down this list again and make it a little bit smaller. Yeah

Henry Suryawirawan: 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 aid, just like what you said, right? It actually increases the success rate of the things that you are checking or reviewing.

[00:48:15] Context Switching

Henry Suryawirawan: 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?

Michaela Greiler: So yeah, the context switching is definitely a problem, right? And sometimes people overestimate the problem, I think, especially for code reviews, because I hear this idea of code reviews 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 code reviews is not such a big problem for you. I think people that are already struggling with their productivity or with scheduling their work, right, they are struggling more with code reviews, right?

And I think, I don’t think that, again, it helps for everybody. It also depends a little bit on the people are, can have different minds, right? They can have different things that they’re striving with and habits that they’re striving with. But I find some of the thing that having dedicated time, like for example, this Pomodoro technique, where we say, well, 25 minutes we are 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 at timers, right? So I think you can adjust it to your personal 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 you really focus on one thing, right?

So for example, code reviews, and we are starting now a 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 are 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 we are starting a different task. Lots of people have ADHD as well, right? So then you feel yourself, you made the, I don’t know… 526 tabs, looking at something completely unrelated and then you have to come back, right?

But I think the essence behind is not, has nothing to do with code reviews per se, right? There’s one more task that you have to do. I think what’s more important and what’s maybe also trickier is that you have to synchronize it a little bit with your team, right? And this has a lot to do with expectations. So when are we expecting code reviews to come out? How long are we waiting for code reviews 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 four, I’m doing the code reviews, right? So I think this plan, the planability and the way that I’m knowing actually, this is when things will come in and I can schedule that into my workday, 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, our code reviews just come out of nowhere, right? So I didn’t even know, but today, three 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 one. A person 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 habit problem. So that we are giving heads up, 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 code review, right? Next time, we do it better. I send you it after, I don’t know, two days of working.

I think there are some the normal productivity tips work for code reviewers, 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 code reviewers is this team dynamics part, right? So put your code reviews on your planning, right? So that you know, this is when they are 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 planability, I think is very, very important.

Henry Suryawirawan: Yeah, thanks for highlighting about the team dynamic aspect as well, right? So I think definitely individually, we we need to kind of 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.

[00:54:14] 3 Tech Lead Wisdom

Henry Suryawirawan: 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 wisdom. 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 will be great.

Michaela Greiler: Okay, so I think the most important thing, in general, right? So if you’re a leader or an employee or, even outside of coding, is really to embrace the diversity of people, right? And also how your minds work, how your bodies work, and how we can do our best work, right? And I think this is why I also really like the idea of DX, of developer experience in contrast to productivity, right? Productivity is all this, we are 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 code reviews to be on my table at 4pm, right? That’s a request. Doesn’t mean it 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 code review and then another colleague will share their habits or their way of thinking. Maybe they have ADHD or you know, maybe they have their neurodiverse, right? And then they will 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 we are thinking about the other people also that are involved.

Another wisdom, and I think this is something that very often strikes me by surprise, is that things are less done than we think, right? So for example, you talk about these reminders for code reviews, right? And I’m thinking about reminders. This is an old thing, right? Like code review reminders, we talked about that like 10 years ago in academia and wrote papers about that. But actually just recently there came a paper out that Meta now is doing it or Facebook is doing it, right? And it’s like, surprise, we have now code review reminders and they 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 has ever done that.

You know Mauricio as well, right? So I had this conversation with Mauricio Aniche. You should check him out as well, right? He’s big into testing. And we talked about test coverage and test selection and prioritization 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 prioritization based on coverage information. Or you could now even think about AI, right, like a 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? Use the code review reminder and try it in your team. And maybe it’s not working, then throw it away, right? But dare 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 at GoTo, 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’s 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 steps, right? It’s really worth it if you’re able to do it. And even if you’re not able to do it at that company, in the next one, maybe you will, right? Yeah.

Henry Suryawirawan: Very beautiful wisdom, so thanks for sharing all of that. Yeah, 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. I think changing one little step is something that is doable for everyone. And also don’t forget changing the company is also probably the last resort that you can do, right, letssay you can’t change the company.

So, Michaela, 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?

Michaela Greiler: 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 michaelagreiler.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 email, right. I’m super happy to have email conversations. I also have a podcast. It’s called SE Unlocked, softwareengineeringunlocked.com. So they can also check out some of the episodes there. And yeah, that’s, I think that’s it.

Henry Suryawirawan: 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 code reviews and they can improve their code review process. So thanks again for that.

Michaela Greiler: Yeah. Thanks so much for having me. It was really fun talking to you.

– End –