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.