Vox

Leitura de 78 min

#159 - Leveling Up Your Code Reviews from ‘Good Enough’ to Great - Adrienne Tacke

Summary

This episode of Tech Lead Journal features Adrienne Tacke, software engineer and author of the upcoming book Looks Good to Me, for a deep dive into code reviews. The conversation explores why code reviews are a critical yet often dreaded part of the software development lifecycle.

Adrienne outlines the fundamental code review workflow involving authors, reviewers, and the team. She explains the common reasons developers dread the process, including unsustainable workflows, overly large pull requests, harsh or unhelpful feedback, and processes that are either too lax or too stringent. Beyond just bug-finding, the key benefits of effective code reviews are highlighted as knowledge transfer across the team and creating a historical, traceable artifact of code changes.

The discussion details the specific responsibilities for each role. Authors are responsible for letting go of ego, providing rich context in their pull requests, and making changes small and manageable (“atomic”). Reviewers must focus on the code objectively, learn to write effective comments using patterns like “Request, Rationale, Result,” and avoid skimming. The team’s role is to establish explicit expectations through a “team working agreement” and an “emergency playbook” to handle exceptions.

Adrienne and Henry also cover practical strategies to improve the process. This includes leveraging automation (linting, formatting, security checks) to eliminate low-stakes noise from reviews, writing better comments with clear labels (like “nitpick”), and giving constructive compliments. To speed up slow reviews, they recommend making PRs smaller, taking lengthy asynchronous discussions to synchronous conversations when needed, and ensuring the team shares the review load to avoid single-person bottlenecks.

Recommendations

Books

  • Looks Good to Me — Adrienne Tacke’s upcoming book (expected Summer 2024) dedicated entirely to code review best practices, covering workflows, roles, effective commenting, and team agreements.

Concepts

  • Team Working Agreement — A co-created, living document that makes a team’s implicit expectations about the code review process explicit, covering timelines, definition of done, follow-up protocols, and style guides.
  • Emergency Playbook — A predefined plan for how the team handles production emergencies, including what approvals are needed and how to communicate when circumventing the normal code review process.
  • Triple R Comment Pattern (Request, Rationale, Result) — A framework for writing effective code review comments: state the Request (what to change), provide the Rationale (why), and show the expected Result (e.g., a screenshot, benchmark).

Tools

  • Miro — A collaborative tool recommended for diagramming and process mapping during code reviews, useful for creating architecture diagrams, sequence diagrams, and other technical visuals to explain complex changes.
  • GitHub Actions / Azure DevOps Pipelines — Automation platforms mentioned for setting up pre-merge checks on pull requests, such as running builds, security scans (OWASP), secret detection, and enforcing PR templates.
  • Linting & Formatting Tools (e.g., ESLint, Prettier) — Automation tools that should be used to handle code style, formatting, and basic static analysis, freeing up human reviewers to focus on logic, architecture, and meaningful feedback.

Topic Timeline

  • 00:00:00 — Introduction and Adrienne’s Career Journey — Host Henry Suryawirawan introduces the episode and guest Adrienne Tacke, author of the upcoming book Looks Good to Me. Adrienne shares her unconventional path into tech, starting from a student help desk job, her experience as a feminine developer in a male-dominated field, and her accidental entry into public speaking which led to her current role as a senior developer advocate.
  • 00:09:06 — Defining Code Review and the ‘LGTM’ Problem — Adrienne explains the basic code review workflow and the term LGTM (Looks Good To Me). She discusses how this phrase has come to represent a process that feels mundane, unmanageable, and often fails to deliver its intended value. The conversation establishes why code review is a key part of software development that needs improvement.
  • 00:15:48 — Why Developers Dread Code Reviews — Adrienne outlines the primary reasons code reviews are dreaded: unsustainable processes with too many steps or huge PRs, a lack of context from authors, unhelpful or harsh feedback from reviewers, and developers tying their self-worth to their code. She emphasizes that these pain points stem from a lack of communication and trust within teams.
  • 00:20:34 — Core Benefits: Knowledge Transfer and Historical Record — Moving beyond bug detection, Adrienne highlights the most valuable benefits of code review. It serves as a powerful mechanism for knowledge transfer, getting the whole team on the same page about codebase changes. It also creates a traceable historical record, linking code changes to tickets and reasons, which is invaluable for debugging and understanding evolution.
  • 00:26:04 — Author Responsibilities: Ego, Context, and Manageable PRs — Adrienne details the author’s ‘contract’ in a code review. The first duty is to let go of ego and separate self-worth from the code. Authors must also set reviewers up for success by providing descriptive titles, detailed context (the ‘why’), and most importantly, by keeping pull requests small, atomic, and manageable to reduce cognitive load.
  • 00:32:48 — Reviewer Responsibilities: Objectivity and Effective Comments — The focus shifts to the reviewer’s duties. Reviewers must also be objective, focusing on the code, not the person. A key skill is learning to write effective comments. Adrienne introduces the ‘Triple R’ pattern: Request (what to change), Rationale (why), and Result (the expected outcome). Reviewers should give thorough reviews, not just skim, and share ownership of the code that goes to production.
  • 00:39:06 — Team Responsibilities: Working Agreements and Emergency Playbooks — Adrienne explains the team’s crucial role in setting the standard. She advocates for creating a ‘Team Working Agreement’—a living document that makes implicit expectations about the review process explicit. This includes review timelines, definition of ‘done,’ and follow-up protocols. Teams should also have an ‘Emergency Playbook’ to define how to handle urgent changes without abandoning process integrity.
  • 00:45:59 — Leveraging Automation and Writing Better Comments — The discussion covers how automation can elevate code reviews by removing noise. Tools for linting, formatting, and static analysis should handle low-stakes issues so humans can focus on higher-value feedback. For comments, beyond the ‘Triple R’ pattern, Adrienne suggests using clear labels (e.g., ‘nitpick’, ‘needs change’), giving genuine compliments for novel work, and always aiming for empathy—‘don’t be a jerk.’
  • 00:57:53 — Speeding Up Slow Code Reviews — Addressing a common anti-pattern, Adrienne provides advice for accelerating slow reviews. The root cause is often overly large PRs, which may indicate scope creep or poor planning. Solutions include making PRs smaller, sharing review load across the team to avoid bottlenecks, and taking protracted online discussions to a quick synchronous call (video or in-person), then documenting the outcome in the PR.
  • 01:05:04 — Three Pieces of Technical Leadership Wisdom — To conclude, Adrienne shares three key pieces of advice: 1) Don’t be afraid to switch to something new and try things outside your comfort zone. 2) Don’t be afraid to fail gracefully, as it accelerates learning and skill development. 3) Have at least one hobby you don’t monetize, to maintain balance and prevent burnout in the hustle-oriented tech industry.

Episode Info

  • Podcast: Tech Lead Journal
  • Author: Henry Suryawirawan
  • Category: Technology
  • Published: 2024-01-22T12:00:00Z
  • Duration: 01:12:00

References

Podcast Info

Transcript

[00:00:00] Hey, a quick message from me. Thank you for being part of the Tech Lead Journal community.

[00:00:05] This show wouldn’t be the same without your ears, and you are the reason this show exists.

[00:00:10] Creating this podcast is a labor of love, but the truth is it also takes time, resources,

[00:00:16] a whole lot of passion, and an extra bit of caffeine. So, if you’re loving TLJ and want

[00:00:22] to see it keep on growing, consider becoming a patron at techleadjournal.dev slash patron,

[00:00:27] or buying me a coffee at techleadjournal.dev slash coffee. Every little bit helps fill the

[00:00:34] research, editing, and sleepless nights that go into making this show the best it can be.

[00:00:40] Thanks for being the best listeners any podcast could ask for.

[00:00:44] A lot of developers tend to tie their self-worth to their code. Sometimes we feel like our code

[00:00:49] is an extension of ourselves. So, being able to let go of your ego and understanding that

[00:00:56] if we’re asking the reviewer, we’re not going to get the answer.

[00:00:57] Viewers to objectively review our code. The feedback is based on the code as I have

[00:01:03] presented it. It has nothing to do with me, has nothing to do with anything about me. It’s just

[00:01:08] the code. Hey, everyone. My name is Henry Suryawirawan, and you’re listening to the

[00:01:20] Tech Lead Journal podcast, the show where I’ll be bringing you the greatest technical leaders,

[00:01:25] practitioners, and thought leaders in the industry.

[00:01:27] To discuss about their journey, ideas, and practices. That we all can learn and apply

[00:01:34] to build a highly performing technical team and to make an impact in your personal work.

[00:01:39] So, let’s dive into our journal.

[00:01:46] Hello to all of you, my friends and my listeners. Happy New Year 2024. This is our first episode

[00:01:52] of the year, and welcome back to the Tech Lead Journal podcast, a podcast on technical leadership

[00:01:57] and excellence. If you haven’t, please subscribe on your favorite podcast app to get notified for

[00:02:03] new episodes. Tech Lead Journal also provides bite-sized contents on LinkedIn, X, Instagram,

[00:02:09] YouTube, and TikTok. My guest for today’s episode is Adrian Tagg. Adrian is a software engineer,

[00:02:17] keynote speaker, and the author of the upcoming book, Looks Good to Me. In this episode,

[00:02:23] we discuss code reviews and why it is an essential part of the software development

[00:02:27] process. Adrian discusses the importance and benefits of code review, the common code review

[00:02:33] workflow, and the different roles involved, how to provide effective code review commands,

[00:02:39] and why we should leverage on code review tools and automation. She also provides tips on how

[00:02:44] to speed up our code review turnaround time. I hope you enjoy listening to this episode and

[00:02:49] learning best practices on doing code reviews. Remember to share it with your colleagues,

[00:02:54] friends, and communities, and leave a five-star rating and review,

[00:02:57] on Apple Podcasts and Spotify. Let’s now go to my conversation with Adrian.

[00:03:05] Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today,

[00:03:09] I have with me Adrian Tagg. She’s actually writing a book, which is something that I look forward to

[00:03:14] read, which is titled Looks Good to Me. I mean, if you know this term, right, I’m sure you can

[00:03:20] associate that with code review. Maybe we’ll ask her what does look good to me means. So,

[00:03:25] Adrian, welcome to the show.

[00:03:26] Thank you, Henry. Thank you so much for having me. I’m excited to be here.

[00:03:31] Right. Adrian, I’d like to ask you to share a bit about yourself, right,

[00:03:35] if you have any career highlights or turning points that we can all learn from.

[00:03:39] Sure. I think the top three highlights I’ll share was in the beginning, I was never really

[00:03:45] introduced to STEM as most people would. So, I didn’t really have any family members who

[00:03:51] coached me or exposed me to that. My only exposure was through playing my

[00:03:56] own computer games, rather, like RCT2 or Age of Empires 2. And that’s a very important thing

[00:04:03] I like to distinguish because a lot of people think that getting into a career, you must have

[00:04:07] had this love for STEM or coding or doing these types of things from a very early age. And while

[00:04:15] that’s helpful for me, I didn’t know that I wanted to be in this type of career until college when

[00:04:22] I was a student help desk technician. So, that’s probably the first turning point,

[00:04:26] is I didn’t even get that job because I wanted to. It was the highest paying job at the time

[00:04:31] for university. And it was only there where you would problem solve, kind of help people break

[00:04:37] down their problems and try to help them was where I said, huh, this might be an avenue that I want

[00:04:42] to go into. Fast forward to probably middle of my career, I was a .NET developer for small

[00:04:50] companies here around Las Vegas where I was based. And this is where I started to learn that not a

[00:04:56] lot of people dressed like me. So, you know, you have this stereotype where it’s like, you know,

[00:05:02] you dress casually or like tech people don’t like to dress up. I don’t know. That’s probably false

[00:05:09] now, but at least at the time during my career, nobody dressed up in heels, nobody wore dresses,

[00:05:15] no one wore skirts, no one did their hair like I did. And so, that was a big turning point for me

[00:05:20] to kind of share. And so, I started to share that on an Instagram account where I’ve actually grew,

[00:05:26] didn’t really dress large without intending to, but I wanted to show other women specifically and

[00:05:32] other Filipino women, because there’s kind of this notion and push to go into the medical field of,

[00:05:38] hey, there’s actually a different avenue for you to go into. So, that was a big part was to share

[00:05:43] that you can be feminine and be technical, and you can go into the technology field if you don’t want

[00:05:49] to go into the medical field like I didn’t. And then the last turning point I’ll share was later in

[00:05:55] my career,

[00:05:56] and I was listening to a talk and the person who was sharing or giving the talk was really,

[00:06:02] really bad. I mean, I wasn’t really learning anything. The slides were just bullet points.

[00:06:07] I started to wonder, how do you actually get up onto these stages? Because I felt like I could

[00:06:12] do a better job of presenting than the current person I was watching. And so that’s when I kind

[00:06:17] of learned, oh, there’s this whole process of applying, you know, submitting talk proposals

[00:06:23] to these conferences. Organizers choose the best ones that fit their program. And then that’s how

[00:06:29] you actually can become a tech speaker. And so that was a very big turning point because I was

[00:06:35] like, okay, let me just try this out. And as a new person, someone who’s never been heard of on the

[00:06:40] speaking stage, the advice they tell you is to apply to as many as you can, because, you know,

[00:06:45] if you get rejected a lot of times, at least you have more chances. Well, at that first time,

[00:06:50] I actually got accepted to seven conferences.

[00:06:53] And so that was very, very interesting. And that’s kind of gotten me to where I am today

[00:06:57] as a senior developer advocate. I wasn’t expecting to transition into developer relations,

[00:07:03] nor was I expecting to be, you know, to actually really like speaking on stage. I’m usually very

[00:07:10] quiet, an introvert, don’t like talking to people at cocktail parties. So to get up on stage is

[00:07:16] something that’s very different for me, but I actually really, really love it.

[00:07:19] Thank you for sharing your story. I think it’s really interesting. You highlighted

[00:07:22] three different things, right, which I think many engineers could actually relate to. I think the

[00:07:27] key learning for me is not to be afraid to try something different, something new, right, even

[00:07:32] though something you didn’t have a background. So take the step and probably look at you now,

[00:07:37] right? It’s partly your main life now. This episode is brought to you by Miro.

[00:07:42] Collaborative development is one of the crucial aspects of software development.

[00:07:46] And code review is one such co-activity that can benefit from a good collaboration.

[00:07:52] As you will learn,

[00:07:52] in this episode later about code review best practices, finding a collaboration tool that

[00:07:57] can assist code review process is extremely useful, especially if it can be done in a fun,

[00:08:03] engaging, and collaborative way. One use case that I find Miro extremely helpful for code review

[00:08:09] is for diagramming and process mapping. You can use it for any of your technical diagrams,

[00:08:15] such as class diagram, sequence diagram, infrastructure and architecture diagram,

[00:08:20] data modeling diagram, and so many more.

[00:08:22] With a lot of readily available predefined templates, you can kickstart your collaboration

[00:08:28] within seconds. It also has support for popular diagram as code tools, such as Mermaid and Plant

[00:08:35] UML. Explaining complex ideas and systems becomes much easier now, and as a result,

[00:08:41] it will lead to a higher quality work, and most importantly, more engaged and productive

[00:08:46] software development teams. Find simplicity in your most complex projects with Miro.

[00:08:52] Your first three Miro boards are free when you sign up today at miro.com slash podcast.

[00:08:58] That’s three free boards at miro.com slash podcast. And now let’s get back to our episode.

[00:09:06] So today we are going to cover this book titled Looks Good to Me, which you’re still writing,

[00:09:11] right? It’s a book about code review. First of all, maybe a bit of background. What is

[00:09:15] Looks Good to Me, or in some company, they call it LGTM, and why you are writing this book?

[00:09:20] Great question.

[00:09:22] LGTM, the infamous acronym, or some people use the thumbs up emoji, right, with that. This is

[00:09:29] usually used to say everything looks, you know, okay. It’s good enough. It passes muster. It’ll

[00:09:36] be just fine. And this notion has kind of devolved, I think, into something that’s not so good.

[00:09:44] As a software developer who goes through code review and reviews other people’s code or,

[00:09:51] you know, puts up their own code,

[00:09:52] changes to be reviewed, there’s a lot of things that have just become really, really mundane or

[00:09:59] unmanageable about the process. And that’s really sad to me because this process is a very key part

[00:10:06] of software development and our jobs as software developers. So code review, for anyone that might

[00:10:13] be unfamiliar, is this very, I’ll start with a very basic workflow of you have code changes

[00:10:20] that you create. Usually we call this the

[00:10:22] author of the code changes. Once they’re ready to have their code reviewed, they typically put it up

[00:10:29] in what’s called a pull request or a merge request or a change request, and they prepare it for

[00:10:34] someone else, a reviewer, to look at. And then this review process can take many forms. Sometimes

[00:10:41] it’s tool-based. A lot of people are familiar with the GitHub-based thing where you put up a pull

[00:10:46] request and it’s asynchronous. Someone looks at it online on a tool, and there’s a code diff that

[00:10:51] shows the differences between the two. And then you have the author of the code changes. And then

[00:10:52] if the code is good, it’s the interviewer. So we can tell them, okay, we have to review this.

[00:10:54] We can say, okay, we have to do this, and that’s how it should be or done that way.

[00:10:55] So that’s what that’s doing. It’s a very easy way to understand the process.

[00:10:56] But I’m also interested in the form of code review. So this is a very, very complex process.

[00:10:57] Sometimes people like to consider pair programming sessions, also a code review where you may write

[00:11:02] some code and someone looks over your shoulder and reviews it at that time. Now, review, this

[00:11:09] phase can mean many different things. And this is kind of what I go into in my book too. But, you

[00:11:14] know, you have different goals as a team when you do the review part. Sometimes it’s looking to make

[00:11:19] sure code looks correct. Sometimes it’s seeing what it says. This could be done in a different way.

[00:11:20] correct. Sometimes it’s seeing, does this match the rest of our code base? Will this improve the

[00:11:27] health of our code base? Is there anything outstanding that’s missing? And are there

[00:11:32] things that we can learn from the changes? Like why are we making these changes at this time?

[00:11:39] And kind of getting the rest of the team on board as to what’s changing in the code base.

[00:11:44] And once that’s done, once a couple people, ideally other than the author, the one who

[00:11:49] actually wrote the changes, take a look at it. That’s when you get that infamous looks good to

[00:11:53] me, you know, thumbs up, an approval that says, yay, this is okay. And then it goes on and merges

[00:11:59] into the rest of the code base. So very simplified at this point, what I’ve just explained, but it’s

[00:12:04] kind of the basis of what a code review is. And you’d be surprised at how many things can go wrong

[00:12:09] in that process. Right. I’m sure all developers understand what you’re saying, right? About

[00:12:15] getting it wrong, about getting it mundane, right? So first of all, I think I just want to

[00:12:19] clarify, you mentioned a few things that, which I think has been associated with code review

[00:12:23] workflow for quite some time, right? The first is about PR, MR, or CR, right? When you said it

[00:12:29] can also be done through pair programming, right? It doesn’t mean that code review can only go

[00:12:33] through, you know, pull request, merge request, change request kind of mechanism. And the other

[00:12:37] thing is, I think about the process of merging. So we are assuming people are using version control,

[00:12:43] of course, and a different kind of a branch before they can merge. Any kind of maybe fun,

[00:12:49] stories or horror stories that you have experienced with code reviews that you can

[00:12:53] share with us? Yes. So my very first experience was actually with a team foundation server,

[00:13:01] dating myself a bit, but this was Visual Studios and Azure, but Microsoft’s way of version control.

[00:13:08] And this was still when it was kind of new, people were not really big on version control yet,

[00:13:14] but it was the system where you would kind of check out a file.

[00:13:19] And you could work on it. And the notion was that kind of like checking out books in the library,

[00:13:24] when you check it out, you have your changes, you work on them, and then you’re able to check it back

[00:13:29] in. And this checking in process, at least in the team that I worked on, we didn’t really have a

[00:13:35] review process. You kind of just assumed everyone that was checking out their things were reviewing

[00:13:42] it themselves and kind of gave them the accountability that, hey, anything you are checking

[00:13:49] in is on you, right? We hope that anything that you check back into the main project code base is

[00:13:55] good and that there’s nothing wrong. So that was my first experience dealing with, well,

[00:14:00] what happens when somebody checks it out at the same time, or there’s a split difference where

[00:14:06] they may have overwritten something that was just checked in, or people don’t have that

[00:14:12] accountability and they just kind of check in their own changes and you don’t know that it’s bad.

[00:14:17] This is kind of the beginnings,

[00:14:19] foundations of where I’m like, why isn’t there some sort of process where we kind of take a look

[00:14:25] or just hold on for a second before we are sure let’s take a look at what’s about to go in. And

[00:14:31] I knew at that time, I was very afraid to break things. So I was extra careful. I was double

[00:14:38] checking, triple checking. And it was really hard to learn that not a lot of people are like that.

[00:14:44] Some people are just like, yup, let me just put it in and if it breaks, it breaks. I didn’t have

[00:14:48] that mentality. But there was a lot of foundation for me and a lot of the work that people would do

[00:14:49] in my field. And so I knew at that time, I was very afraid to break things. And I didn’t have that

[00:14:49] mentality. And so I knew at that time, I was very afraid to break things. And I didn’t have that

[00:14:49] mentality so it was very difficult to experience that firsthand of what happens when in that sense

[00:14:56] it was kind of like a merged conflict where the same file was changed and you don’t know what’s

[00:15:01] proper you don’t know what to keep you don’t know what’s most current and yeah that kind of started

[00:15:06] out the basic foundations in my career I didn’t know it yet at the time and as I started to learn

[00:15:11] get those things crept up in my head but yeah that’s where it kind of all started for me and

[00:15:18] got my mind spinning about why there is no such review process on my own teams

[00:15:22] I think I must also say from the experience I had right the kind of version control that you use

[00:15:27] will also determine this kind of a code review process right so I think mostly people are familiar

[00:15:32] with git now which is kind of like optimized for this kind of workflow so I think we should

[00:15:36] appreciate that git exists right so in your book you come up with this statement which I think

[00:15:41] really really interesting for us to discuss right you mentioned that we need actually code review

[00:15:46] but most of us

[00:15:48] actually dread it tell us why many people actually dread code review process there are a lot of

[00:15:54] reasons over my career over the different people I’ve spoken to different developers it mainly

[00:16:02] comes down to a couple things one the process is unsustainable so what I mean by that is the

[00:16:11] process itself is just really cumbersome there’s too many steps or the PRs

[00:16:18] the reviews themselves there’s too many files to look at there’s too many lines of code

[00:16:22] to review that’s way too large for any single person to properly look at and give a review

[00:16:30] sometimes there’s no description or context that comes with the code changes so as a reviewer it’s

[00:16:37] very difficult to make sense of what it is that you’re trying to do and then there are just

[00:16:43] processes where if you try to leave feedback you don’t know what to do and you’re trying to

[00:16:48] know how to leave feedback or the feedback is not helpful something like oh this could be better

[00:16:54] and then that’s it that’s the only comment you get you’re like okay what am I supposed to do with that

[00:16:58] as an author receiving that comment you have nowhere to go from there so it’s become unmanageable

[00:17:05] unsustainable number two in the more extreme cases there are reviewers who kind of take advantage of

[00:17:12] the little power that they do have as a reviewer and sometimes they just don’t know how to

[00:17:18] write effective comments so there are a couple examples in my book where I share these are on

[00:17:22] you know public open source repos and people are very harsh in their comments they’ll say oh this

[00:17:28] is a stupid way to implement this or oh this looks terrible or you know this or that and I always

[00:17:35] think for someone who’s either new to software development or new to the team or someone who’s

[00:17:42] just unfamiliar with the actual technology but could be a seasoned developer when you have this

[00:17:47] kind of

[00:17:48] culture of just being so harsh and not being able to give constructive feedback that definitely does

[00:17:54] not cultivate a good developer experience you know there’s another thing I say which is a lot

[00:17:59] of developers tend to tie their self-worth to their code which we shouldn’t do I talk about

[00:18:04] that too but you know sometimes you do and for those who haven’t learned to uncouple themselves

[00:18:11] from their code getting a comment that’s that harsh or direct or just unnecessarily mean

[00:18:17] can really be a lot of fun and it’s a lot of fun and it’s a lot of fun and it’s a lot of fun and

[00:18:18] break their day can make it really unnecessary so a code review that’s unnecessarily mean is

[00:18:24] something people dread and then the last part is just when you go through the process sometimes

[00:18:29] it’s so stringent so there’s like the lack of code review which is a terrible thing right you get this

[00:18:36] wild wild west of everyone stepping on each other’s toes that’s not so prevalent now like

[00:18:40] you said the git is more common and not to say we all use it properly but it’s there and then there

[00:18:45] is the other side of the spectrum where it’s too stringent and it’s not so stringent and it’s not so

[00:18:48] stringent so now you’re dreading the process because you have to get like this approval and

[00:18:53] you have to fill out these things and you have to do this and that and that and you know in my book

[00:18:59] I do say we’re not supposed to think about it as a burden there are certain things we have to do

[00:19:06] like if we’re opening a change we need to make sure context is there we need to link it we need

[00:19:11] to put labels but that’s a bare minimum thing I’m talking about the processes where they have extra

[00:19:16] approvals they have

[00:19:18] so many unnecessary steps that what do developers do when they you know are inconvenienced at any

[00:19:24] step they’re going to go around it so any process that is made much more difficult than it needs to

[00:19:30] be without any additional value developers are going to find a way around that and so that’s

[00:19:36] what I’ve seen are a few ways why developers just dread the process it’s not as easy as it needs to

[00:19:43] be it can be very harsh and mean when it doesn’t have to be and it is very difficult to do that

[00:19:48] it’s unmanageable when it should be manageable and it should really reel in all of the benefits

[00:19:53] if it’s done properly I’m sure like I can relate to many of them I think it also boils down in your

[00:19:59] book you mentioned it’s a lack of communication and trust between team members eventually you know

[00:20:03] like these mean comments or ineffective review comments or maybe even the delays and number of

[00:20:09] lines of code and number of files that you submitted right and also I think the lack of

[00:20:14] clarity about the process itself I think we assume that everyone is expert in the process and I think

[00:20:18] doing code review which I think in my experience not everyone actually is an expert and we need

[00:20:23] some kind of resources like this book to actually upskill ourselves so apart from the obvious you

[00:20:29] know like looking at the code finding bugs making it better what are some of the other benefits that

[00:20:34] you can share for doing code review yeah so even finding bugs that’s a highly debated thing that

[00:20:42] people say happens I talk about that in the book there are a couple studies that do show like

[00:20:46] there’s a Microsoft study that I’ve done that I’ve done a lot of research on and I’ve done a lot of

[00:20:48] it actually says it doesn’t find bugs but depending on how your team uses it sometimes it does

[00:20:53] we’ll leave that up to debate one of the really good things that code review does is it leaves

[00:21:00] artifacts for your team so it leaves a historical record of what changes in your code and it also

[00:21:08] increases knowledge transfer among the team I think to me as I’m continuing to write this book

[00:21:15] those are the really the key things that I think are the most important things that I think are

[00:21:18] the most important things of why code review really will stay we might talk about this later

[00:21:22] but people are talking about oh AI can just do the code review for us and we don’t have to deal with

[00:21:26] it anymore that’s not going to happen but knowledge transfer is a really big one you know as you code

[00:21:33] review and more eyes look at the code changes that are being presented that’s one of the greatest ways

[00:21:41] to share what is happening on the code base and again if the code changes are prepared

[00:21:48] as in you give the context as to why the code is changing you tie it to the tickets that may have

[00:21:55] started the you know the reason for why you’re making the change in the first place or you know

[00:22:00] you tie it to the initial bug report that ties to the fix you’re about to change it just paints a

[00:22:06] better picture for the rest of your team as to why you’re making this change and then the diff

[00:22:12] itself the code that’s the how right how are you doing it you’re looking at the code you’re

[00:22:17] seeing what you are implementing the code review the PR the pull request or the change request

[00:22:23] that’s the why and so that is very important to spread across the team and as you go and evolve

[00:22:32] your code base is very important for the team to all be on the same page otherwise you get these

[00:22:37] scenarios where it’s a single person or it’s like a senior senior developer and they’re the only one

[00:22:42] that knows anything about everything about the code base so then you get this problem

[00:22:47] where they actually become the only person who reviews every single pull request and then you

[00:22:53] get into the unmanageable case where it’s like it’s a bottleneck I’m the only one who can look

[00:22:57] at these well why are they the only one that can look at this I’m the only one that knows about

[00:23:00] this code why are you the only one that knows about this code well because I’m the only one

[00:23:04] that’s familiar so that in and of itself is a great reason to do code reviews and to do it with

[00:23:11] as many people on the team as possible to learn about it the other side of that other

[00:23:17] really good goal of code reviews is historical record specifically traceability so when you

[00:23:24] have these official formalized documented reasons for why the code has changed it makes it much

[00:23:31] easier for the team to see what has happened and if something goes wrong if you do it correctly or

[00:23:40] I want to say if you take the effort and time to you know have really good commit messages to link

[00:23:47] tickets to the pull request to make pull requests and changes atomic and small and to do them in a

[00:23:55] way that if something does go wrong you can easily revert back and say oh I know when that happened

[00:24:00] it specifically happened October 31st on this specific commit that’s the goal right that’s the

[00:24:06] ideal state that developers would love to have but that’s possible with code review because

[00:24:11] you get to see what has happened why it has changed and you are where you are today

[00:24:17] and then if you use you know there are things like I just watched a talk at a conference I

[00:24:22] spoke at where they use get release manager and they don’t use pull requests but they do

[00:24:28] use issues as kind of their central item that kicks off everything and because they have good

[00:24:35] commit messages because they use proper linking with issues and with pull requests and labels

[00:24:41] and things like that they are able to automatically generate a change set and then also if there was

[00:24:47] an issue that was fixed by a specific pull request they automatically are able to send a message

[00:24:54] through a web hook that says hey we just released something this has been fixed in release you know

[00:24:59] 2.3 in this particular thing so a lot of that accountability and traceability you can get if

[00:25:07] you do these processes and I think those are really really good things to have that’s what

[00:25:13] makes software development much more professional and much more fun I think

[00:25:17] to have it all laid out in a nice way like that it seems like a really high bar and really

[00:25:22] interesting to learn as a case study right so I think things like spreading the knowledge we

[00:25:28] kind of like think it can it will happen right in the code review but not all the time I believe

[00:25:32] because like what you said right lgtm is most common comment probably when you’re looking at

[00:25:38] the PR whether it happens constructively or not we don’t know and many other things like for example

[00:25:43] making sure the code base follows the same standard in the team right I think that’s

[00:25:47] also one of the other benefits if done properly so I want to tackle the other topic that you cover

[00:25:54] really really well in the book which is about the roles and responsibilities of the people or

[00:25:59] entities involved in the code review right so you mentioned like reviewer author and things like

[00:26:04] that there are actually more roles in the code review process maybe if you can go highlight some

[00:26:09] of the roles and responsibilities especially the author maybe let’s start with the author first

[00:26:17] um this is the one that puts up the code changes they are the ones that write the code and they’re

[00:26:22] asking someone to review it and for the author I put a lot of responsibilities I kind of call

[00:26:29] it a contract for them to adhere to in the code review and one of the first things is to kind of

[00:26:36] forget your ego so we touched on this earlier like I said sometimes we feel like our code is

[00:26:42] an extension of ourselves we’ve been working on this really nice change

[00:26:47] or we’ve fixed this bug and we’ve prepared this really nice code and it’s our baby right and so

[00:26:54] when we put it up for review we become vulnerable now we don’t want to hear sometimes feedback on

[00:27:02] it because what do you mean it’s perfect the way that it is our baby is perfect the way that it is

[00:27:07] but sometimes not being open to that feedback means we don’t get the best code possible or

[00:27:15] when we’re so in the

[00:27:17] weeds working on our particular feature just being down at that level focusing on the code

[00:27:23] sometimes we don’t see particular edge cases or sometimes different skill sets and different

[00:27:30] perspectives take a look at our code and can actually offer some good feedback so being open

[00:27:37] to that means we have to let go of the ego of you know our code is perfect and the way that I’ve

[00:27:43] submitted it is perfect alongside of that you might be open you know you’re like

[00:27:47] no I know that I have room for improvement sometimes people will get feedback but then

[00:27:53] they’ll say oh well actually no I don’t think that is correct so that’s the other side is you

[00:27:59] know you say you’re open to feedback but then you actually do get feedback and then you’re like no

[00:28:03] you know you disagree and you try to fight it off so being able to let go of your ego and understanding

[00:28:09] that if we’re asking the reviewers to objectively review our code and to only look at the code not

[00:28:16] consider us

[00:28:17] then we need to do the same thing we need to objectively say this feedback is based on the

[00:28:23] code as I have presented it has nothing to do with me has nothing to do with anything about

[00:28:28] me it’s just the code focus on the code the next thing that authors are responsible for

[00:28:34] is we need to have due diligence when we actually create these pull requests so I don’t know about

[00:28:41] you Henry but have you ever received a pull request where it’s like the title is like bug

[00:28:47] box and then everything else is empty and you have no idea what is going on have you ever had

[00:28:54] like a very non-descript review that you’ve had to do yes not only PR sometimes the code commit

[00:29:02] comment as well right yep so that is another big thing that I see authors don’t do is we

[00:29:10] don’t set up the reviewer for success we don’t give them the context that they need to properly

[00:29:17] our code. So that starts with a very good descriptive title. Like I need to know what

[00:29:24] I’m about to review in the 10 seconds that I read the title. And then when I go into the

[00:29:30] description, the description is where you tell me the why. Why am I making this change? Is it because

[00:29:36] a ticket was the catalyst for this? Is it because we had a planned, you know, in our retrospective,

[00:29:43] we said this work was going to be done and this is now the work that is happening? Is it because

[00:29:48] it was some one-off conversation with our manager that said, you need to do this right now? Like,

[00:29:53] why is it here? And then adding that context there, it tremendously helps put the reviewer

[00:29:59] in the correct mindset to review it. Not only that, but making RPRs manageable. So I’ve been

[00:30:08] guilty of this before, especially when I had, you know, I was just learning Git, but, you know,

[00:30:13] there are PRs out there with like 5,000 files changed or 8,372 lines changed. And you’re like,

[00:30:23] really? You really expect me to properly review this, a single person? So not making the PR

[00:30:31] manageable is something I think is a very big responsibility that we have as an author.

[00:30:37] So that’s why in my book, I do have, you know, rough guidelines from several research

[00:30:42] papers. So that’s why in my book, I do have, you know, rough guidelines from several research

[00:30:42] papers. So that’s why in my book, I do have, you know, rough guidelines from several research

[00:30:43] papers and studies that have been done. Basically, the smaller that you can make your PR,

[00:30:48] the better. And it makes sense for everybody involved. The more atomic the change, the less

[00:30:53] files you have in your PR, the less lines of code that someone has to look at, the more likely that

[00:30:58] the person, the reviewer, is going to be able to properly review that. The less likely someone can

[00:31:04] have an excuse to say, oh, I don’t have time to review because it’s such a small PR. If you could

[00:31:10] do it in 10 minutes, it’s going to be reviewed. It’s going to be reviewed. It’s going to be

[00:31:12] reviewed. There’s no excuse to not review it. And then, again, it’s the traceability aspect of

[00:31:19] if something goes wrong, it’s much easier to pinpoint this particular pull request was the

[00:31:25] source or the root, right? Versus having like a gigantic pull request with several changes

[00:31:31] muddled in there, along with configuration changes and some package JSON changes. Like,

[00:31:37] you put that cognitive load on the reviewer and on yourself later on if you have,

[00:31:42] ever have to untangle something from that particular pull request. So, that’s another

[00:31:48] responsibility that I say is very important for authors is to make sure that the pull request

[00:31:53] that they’re preparing is primed, is what I say. It’s ready for the reviewer to look at.

[00:31:59] And I think those are the big ones. I’m sure there’s a couple more that I’m forgetting,

[00:32:03] but those are the ones off the top of my head are very, very important that we tend to forget.

[00:32:08] Yeah, you mentioned about cognitive load. I think sometimes we don’t empathize the reviewer,

[00:32:12] right? So, we are in the mood to finish whatever that things that we are working on, right? And we

[00:32:17] didn’t realize that the number of files, number of lines of code are too big. And we just submit

[00:32:22] the PR in one go, right? So, I think you mentioned a very, very important responsibility as the

[00:32:26] author as well is be your first reviewer, right? So, you look at the PR, look at the number of

[00:32:31] changes and make it more manageable, right? So, I think making it more manageable to me is maybe

[00:32:36] one of the biggest important thing that we can do in order to make it less dreadful. So, now,

[00:32:42] the author is going to tell us a little bit more about how to do that. So, I’m going to

[00:32:42] the PR. So, there’s a reviewer. I think this is also another important role. So, tell us the

[00:32:48] responsibility for the reviewer. Yes. So, for the reviewer, I also say the same thing, right? Forget

[00:32:54] your ego, focus on the code, not the developer. So, as reviewers, we need to be objective. We can’t

[00:33:02] bring in, you know, if you’re having like an argument with your co-worker, but they ask you

[00:33:06] to review your code, that’s like another issue. You should sort that out. But if you are reviewing

[00:33:11] someone’s code, that shouldn’t come into play. You should just look at the code. This is also not

[00:33:16] the time to be giving a better implementation for the sake of giving a better implementation

[00:33:23] without reason, right? So, a lot of what I hear when I talk about these reviewer responsibilities

[00:33:30] is that this means that I can’t just give feedback anymore at all to the author. Like, it has to be

[00:33:36] walking on eggshells. Everything is happy. I’m like, no, that’s not what I’m trying to say. What

[00:33:40] I’m trying to say is, if you’re a reviewer, you should look at the code. You should look at the

[00:33:41] code. So, that’s another thing that I say is a responsibility of the reviewer is to actually

[00:33:50] learn how to write effective comments. This is something I think a lot of reviewers have trouble

[00:33:56] with, and rightfully so. Some are actually empathetic, right? They’re like, I don’t want

[00:34:01] to offend the developer. I don’t want to hurt their feelings. I want to bring up something

[00:34:07] that is important, but I don’t want to do it in a way that will scare them off.

[00:34:11] Or make them upset. And so, something that I’ve developed in the book, I call it the triple R

[00:34:17] pattern. If you are going to ask someone to make a change, or you have a request or something,

[00:34:22] I say the three R’s. Name the request, give your rationale for it, and then give a result.

[00:34:28] And that will almost always be an objective way to write a comment that gives feedback to

[00:34:35] the author. Because you tell them what you want, which is the request. You give the reasoning

[00:34:40] behind it, which is the question. And then you give the answer. And then you give the answer.

[00:34:41] The rationale. And then the result that you are sharing with them is a way for them to actually

[00:34:47] compare and say, am I on the right track? Or did I do it correctly? And that could be, you know,

[00:34:53] if you need something to change visually, have a screenshot exactly of what you are expecting.

[00:34:59] Because that will almost always be helpful than trying to describe it. If it’s like a performance

[00:35:04] optimization, give them a benchmark to hit. The more specific that you can be, the less likely

[00:35:10] the author is going to be. And then you give them a benchmark to hit. And then you give them a benchmark

[00:35:11] that says, oh, this person just wants me to do more work. Or, you know, they’re trying to make

[00:35:17] me achieve a standard that’s unnecessary right now. I just need to get the work done. The less

[00:35:22] you are vague about it, the more outcome focused you are, the more specific you are, and the more

[00:35:28] objective you are about it, the better your comments will be received by the author. With

[00:35:35] that, another thing that I say is a responsibility of the reviewer is we should also,

[00:35:41] you know, be thorough in our reviews. So there’s been a notion to kind of skim reviews. This is why

[00:35:48] we get the looks good to me, right? And as an author this time, when, you know, you’ve prepared

[00:35:53] a nice review, maybe you have a nice set of changes, it’s actually manageable. And you put

[00:35:59] it up for request. You’re like, oh, can someone review this? And then within like two minutes,

[00:36:05] you get a thumbs up. And you’re like, there’s no way somebody looked at this properly. There’s no

[00:36:10] way they actually reviewed it. And then you’re like, oh, can someone review this? And then you’re

[00:36:11] like, oh, they gave this the due diligence that it needed. So as a reviewer, you know, it can be

[00:36:16] tempting, but this is why it’s a two-way effort of when the PRs are manageable and they’re small

[00:36:23] enough, then there’s really no excuse for you as a reviewer to skim them. So if they are small

[00:36:28] enough and they are manageable, being able to review in 10, 20 minutes at most, give them the

[00:36:34] proper review that it needs. Go through them, go through the code, and really give it your thorough

[00:36:39] eye as if you are a reviewer. And if you’re a reviewer, then you’re a reviewer. And if you’re

[00:36:41] a reviewer, then you would want to have your own code reviewed. And then also giving that time to

[00:36:47] yourself. Sometimes you need to talk to yourself and say, you know, before you ask the author to

[00:36:54] make a change, for example, first ask yourself, why am I asking the person to make this change?

[00:36:59] Because if you yourself can articulate why you are going to make that request, then you’re going

[00:37:05] to be able to better articulate it to the author. That’s how you get rid of those comments of like,

[00:37:11] be better, and then it’s done. Or, you know, a comment that’s like, I think there’s something

[00:37:16] wrong here, but then that’s it. And you leave it at that. That’s where the discussions go back and

[00:37:21] forth because you didn’t take the little extra time to articulate it a little bit better to

[00:37:26] understand yourself why you’re making that comment. And so, you know, doing that due diligence,

[00:37:31] not skimming in your review, giving it a proper review, and, you know, forgetting your ego and

[00:37:37] making sure that we write effective comments.

[00:37:41] Now are on the top of my head, the most important responsibilities for the reviewer in a code review.

[00:37:47] Yep. Also, you mentioned something really, really important that I want to highlight here as well,

[00:37:51] right? Eventually, the reviewer also responsible for the code that gets through, right, to the

[00:37:56] production. So I think if we just skim it and we think that it’s the author’s problem, I think

[00:38:01] that’s also not the right way, right? So I think the reviewer should also own the responsibility

[00:38:05] to make sure it works really, really well. Yes, I’m glad you brought that up. I’m really glad you

[00:38:11] brought that up. And I think the last thing I’ll say about that is there’s this notion with reviewers

[00:38:14] to be like, oh, it’s the developer’s fault, right? If something does go wrong, and it goes through

[00:38:19] their review, we are quick to blame and say, oh, it’s not. And really, what we should be thinking

[00:38:25] is, oh, how did that actually pass through my review? So that’s like a really big mindset shift

[00:38:31] that I’m hoping to convey in the book. And I hope more people will start to think about when it comes

[00:38:36] to code reviews, specifically as a reviewer. But thank you for reminding me of that part.

[00:38:41] Yep. The other aspect about reviewer is like how long the code review lasts, right? So I think

[00:38:46] there’s sometimes a power dynamics, especially if you are senior to review your code, right? You

[00:38:51] kind of like just wait and kind of like beg them, please review my code. So I think as a reviewer,

[00:38:56] you also have the responsibility to make sure it doesn’t drag, right? Doesn’t delay for too long.

[00:39:01] Which brings us to the aspect of team, right? A team, maybe standard or convention, right?

[00:39:06] So the team here also has a role to play. So tell us what is the responsibility,

[00:39:11] for the team. So the team is basically the one that sets the tempo for the rest of, you know,

[00:39:19] for all the individuals. Sometimes there are some suggestions in my book where I say,

[00:39:25] have extra steps, you know, or use a lot more caution and be very intentional about what you do.

[00:39:32] But sometimes you have a team who might be like a team of five senior developers,

[00:39:39] they’ve all been working very well.

[00:39:41] With each other, they know each other. Maybe they have the luxury of actually being in an office

[00:39:47] on site together. And so if that’s the case, maybe you may not need such a formalized process. Maybe

[00:39:55] you trust each other and you have less of a checklist when it comes to your code review.

[00:40:02] But then if you have, maybe say a more mixed team, you have a couple senior developers,

[00:40:07] you have a more intermediate and junior developers,

[00:40:11] or you have an intern, or someone that’s maybe new to software development,

[00:40:15] then it’s the team’s job to help integrate the rest of the members. So that number one,

[00:40:22] they know what the process is. And number two, to keep the process enforced for everyone.

[00:40:28] Doing that becomes a lot easier. There’s a whole chapter I dedicate to this concept,

[00:40:34] which is what I call the team working agreement. And this is a document that’s co-produced by the

[00:40:40] team. So if you have a team that’s working on a project, and you have a team that’s working on a

[00:40:41] project, it’s basically all of the implicit expectations that you have as a team,

[00:40:46] you make them explicit, you write them out. So what are the steps of your code review? What are

[00:40:51] the expectations around the code review? Things like, if somebody leaves feedback on my code

[00:40:58] review, do I have to answer every comment? Do I have to mark all of it as resolved? Or is there

[00:41:04] some wiggle room there? What counts as done? What counts as an approval? How long is too long on a

[00:41:11] code review? If someone hasn’t looked at my code, when is it appropriate to follow up? These are

[00:41:16] all the sources of frustration, of tension among the team, because it may be different for everybody

[00:41:23] in everyone’s head and specific preferences. You know, someone might want it done the next day,

[00:41:29] 24 hours. Someone might be more lax and like, oh, I’ll get to it by the end of the week.

[00:41:33] So having all of that figured out on your team, not only makes it easier for everyone to be on

[00:41:40] the same page.

[00:41:41] But if someone is going off base and is not following the process, then you can use that

[00:41:47] document and use it to enforce on the team to say, hey, look, we all agreed. This is what we said for

[00:41:53] this particular situation. And this is what we should be following. And so it’s much easier to

[00:41:59] bring that up versus just saying it’s a he said, she said, or, you know, it’s one preference versus

[00:42:06] somebody else’s preference. It’s the team’s preference. And this is the team’s

[00:42:11] standards. And this is what the team’s way of going about things. And the other thing about

[00:42:16] this document is that, you know, a lot of people say, well, you know, once these are written,

[00:42:21] like, what if things change? Well, the document changes with the team. So it’s not this set in

[00:42:27] stone thing where it’s like, these are the rules forever. No, your team’s going to change. Your

[00:42:32] code base is going to change. Your project’s expectations are going to change. There are a

[00:42:37] lot of things that are going to change. And so if you find that there are

[00:42:41] parts of the process that don’t work for your team, change it and then also change that team

[00:42:46] working agreement. That’s the great thing about this is that as long as you have an open culture

[00:42:52] on your team, a culture of feedback where people are open to talking to each other and open to

[00:42:57] discussing things like this, then a change can be made the next day. And then, you know, it might

[00:43:04] take a while for people to get used to it, but the change is implemented and then you continue to

[00:43:08] enforce it that way. So that, you know, that’s the great thing about this document.

[00:43:11] It’s one really good way to keep the team accountable. And then the last part is not

[00:43:17] everything is going to go the happy path, right? It’s not just, we’re going to change some code,

[00:43:21] we’re going to review it. Some people look at it and then it goes into the rest of the code base.

[00:43:26] There’s going to be times where there are emergencies. So production goes down. There’s

[00:43:32] some really big thing that happens that requires the attention of the team. What do you do in that

[00:43:38] situation? This is where, you know, there’s a lot of things that are going to happen. And so

[00:43:41] a lot of other problems become larger when you don’t have a process in place. So sometimes

[00:43:48] emergencies are used to circumvent the code review process, and that’s not a good use case for it.

[00:43:56] What would be better is to anticipate emergency scenarios and then have that written on your team.

[00:44:03] Say, what do we do in an emergency scenario? There’s things called an emergency playbook

[00:44:08] where you write down, okay, if it’s an emergency scenario, what do we do? And then you can

[00:44:11] say, okay, if it’s this kind of emergency, what are we allowing in our process? Are we saying

[00:44:16] we can allow one approval instead of two? Does a manager approving, you know, does that count in

[00:44:24] an emergency situation versus our normal two people or more? Can we open a pull request

[00:44:30] straight to production? What are those processes and what’s happening in them? And then not only

[00:44:37] that, if you are going to go around the process, you’re normally going to have a process that’s

[00:44:41] normal code review process. Make sure that in your emergency processes, you have a very outlined,

[00:44:48] detailed communication plan of this is happening and this is why we’re doing it. So it’s one thing

[00:44:54] to circumvent the normal process. It’s another to make sure everyone knows that that is happening,

[00:45:00] knows that’s okay because you’ve anticipated it, and also knows that you’re circumventing it

[00:45:06] because it’s an emergency. So that’s very important to anticipate it and then to

[00:45:10] communicate it. And then if you’re going to go around the process, you’re normally going to have

[00:45:11] to communicate to as many people as possible that whatever you’re doing is happening because of the

[00:45:16] emergency situation. Right. I find these two, the team working agreement and also emergency playbook

[00:45:22] is something that everyone should check from your book, right? Because it really details a very,

[00:45:26] very important thing that I think most teams are lacking, right? Especially the team working

[00:45:31] agreement. So what you described is like you make something like an expectation becoming more

[00:45:36] explicit and that you can enforce to the team, right? As a standard practice for them. So do you

[00:45:40] check these two out from the book? And I think really, really a lot of insights there. Of course,

[00:45:44] there are other roles which will not cover things like who is in charge, right? The TL, the EM,

[00:45:49] or even the leaders from engineering, right? And also the organization at the end. So let’s move

[00:45:54] to the next section, which is about automation, right? I think in some teams which are advanced

[00:45:59] enough or using some system that provides all this automation is always nice. Tell us the role

[00:46:04] of automation in making code review better. So you’d be surprised at how many

[00:46:10] teams that I’ve spoken to that don’t make more use of automation in terms of development

[00:46:19] automation. So there are a lot of code reviews that are spent fixing formatting or fixing spacing

[00:46:28] or changing naming conventions to a particular language. And these are all such low stakes

[00:46:36] issues that they really should not be in the code review.

[00:46:40] Because they waste a lot of time and they are also very subjective. They can get into very

[00:46:47] heated debates among developer preferences. And so that’s another thing that should be decided

[00:46:52] upon by the team. Have a proper style guide, add that to the team working agreement, and then

[00:46:58] make use of the automation that is for that. So linting, formatting, static analysis,

[00:47:05] running security tests that you can locally. These are all things that should be done

[00:47:10] during the code review. And so I think that’s a really good point.

[00:47:10] During development, we have so many tools at our disposal as developers that integrate with our

[00:47:17] IDE. We have extensions galore in VS Code. We have things like ReSharper. There are so many

[00:47:24] things that are there to help us to do all of these things during development. And I really

[00:47:30] believe that if you fix all of these things as they happen, as you write code, and when you can

[00:47:36] during development, the less likely they’ll interrupt the code review process. And so I

[00:47:40] believe that if you fix all of these things as they happen, as you write code, and when you can

[00:47:41] the more likely you’ll get to use the code review process for those more important things, for

[00:47:48] actually focusing on the things that matter, either allowing the reviewer to actually just

[00:47:53] see higher stakes issues, because they’re not bogged down with like, oh, there’s a space here,

[00:47:58] or you’re missing a comma here. You are letting them focus on higher stakes issues, but you’re

[00:48:03] also allowing people to actually get that knowledge transfer without being interrupted or bothered by

[00:48:10] all of this. And so I think that’s a really good point.

[00:48:10] lower stakes issues. So automation is for those things firsthand so that you can get rid of all of

[00:48:18] that noise in the code review. And then another part of automation that I know sometimes it’s

[00:48:24] not really part of the code review, but I’m a big proponent of because sometimes you can

[00:48:29] integrate it with them. And those are all the kinds of checks that you can do in a process.

[00:48:34] So on GitHub specifically, and on some other tools like Azure repos, or I’m sure

[00:48:40] AWS has an equivalent, there are some initial checks that you can do. For example, on GitHub,

[00:48:46] when you open up a pull request, you can set it up to have an initial build go through and see if

[00:48:54] it will break. And it’s a pre build check. There are other tasks that you can have run also when

[00:49:01] you open a PR. So if you have things to check, like there are some GitHub actions, I think that

[00:49:09] allow you to check for a pull request. So if you have things to check, like there are some

[00:49:10] a multitude of things. Do you have secrets in your code? Do you have some security,

[00:49:16] you know, like OWASP 10 issues that are glaring that somebody else may not have the time to check?

[00:49:22] Those should certainly be checked during development, but they act again as another

[00:49:26] checkpoint at the PR point to be able to check that as well. You have things like being able to

[00:49:35] automatically deliver, let’s say a PR template to someone, depending on the type of,

[00:49:40] issue that they’re doing. So, you know, I always go on and on about how the author needs to put

[00:49:46] as much information as possible in their PR. Sometimes that’s a lot of information. Sometimes

[00:49:51] you just forget, or you really don’t remember all the things. And so something like a PR template,

[00:49:58] for example, you can have a checklist basically that says, Hey, you help the author. You say,

[00:50:03] these are all the things that you need based on the type of pull requests that you’re opening.

[00:50:07] And then again, you set them up for success. You know,

[00:50:10] let them help themselves by having this automatically appear when they open a PR.

[00:50:16] So using automation in this way is again, it’s to help us help ourselves, right? It’s to get rid of

[00:50:24] all of the noise, all of the lower stakes issues, and to give the reviewers the best chance of

[00:50:31] reviewing it in like a clean of a slate as possible to really focus on the things that

[00:50:37] automation can’t find. That’s,

[00:50:40] where the human judgment, the nuance, the understanding, the example I really like

[00:50:45] giving is you can have all of these checks, you can run all of the static analysis and all of that.

[00:50:50] But the reviewer is the only one that can in a code review say, Hey, this variable name is actually

[00:50:57] not that meaningful. I don’t understand it. Can you make it more meaningful? And meaningful is

[00:51:04] completely lost, at least at this point for AI, for any kind of,

[00:51:10] static analysis tool, it would never be able to give that kind of surface, that kind of comment to help us fix it.

[00:51:17] So if we can eliminate all of the noise and allow the reviewers to focus on those kinds of issues, then I think we’re

[00:51:26] doing a good job and we’re really using the code review to its largest advantage and largest benefit.

[00:51:32] I think if as a team, right, you manage to, you know, remove all these accessories thing, I say like formatting,

[00:51:39] spacing, you know,

[00:51:40] comma here and there, right? I think that’s a good bar that everyone should aspire.

[00:51:44] Another thing that you include in this automation is actually inclusive language, kind of a check,

[00:51:50] which brings me to the next thing about commenting, right? Maybe a little bit of advice, how we can

[00:51:55] comment code reviews better.

[00:51:57] Yes. So aside from the really good pattern I shared, which is the triple R pattern, the, you know,

[00:52:04] request rationale result, I think following that for most comments would be really, really good.

[00:52:10] Because it gives the author somewhere to work off of, and it also gives them some understanding or context

[00:52:19] behind why you’re making a request or that comment. But other things, I don’t know if you’ve ever used a

[00:52:26] nitpick comment label. This is very debated. Like, I feel like you should not have nitpicks at all.

[00:52:33] But if you must have some sort of nitpick, which is like, it’s purely subjective, but you have to be able to

[00:52:40] tell the author that this is, you know, you don’t have to do anything about it. It’s not a change.

[00:52:44] You just want to let them know this is purely a subjective preferential thing. Then my team likes to label that

[00:52:51] as a nitpick very clearly. And along the same lines, if you’re able to kind of label your comments in that way,

[00:52:59] for example, if something needs to actually be done, make that very clear on the comment.

[00:53:04] So just like you would label a nitpick, nitpick, like bold first nitpick, and then the nitpick,

[00:53:09] you would say needs change, for example, and then you write your comment or needs rework, let’s take this

[00:53:16] discussion offline, and then you put your comment, you know, having that very clear upfront and being

[00:53:23] able to let the author read it, having them read that as the first part of the comment saves a lot

[00:53:29] of cognitive load for them, because then they can say, Oh, these are the ones that are important

[00:53:34] that I should focus on. And then these are the ones that are not so important. And I think that

[00:53:39] Yeah, that’s a good point. I think that’s a good point. I think that’s a good point. I think that’s a good point.

[00:53:39] is important, because I don’t know how many people are like me. But every time I see any

[00:53:44] comment on a pull request that I open, I just immediately associate that, oh,

[00:53:50] it’s work I have to do. Every comment means I have to change something or update a line or do

[00:53:55] something. So then I get a little bit worried. I’m like, I got to do all of these changes.

[00:53:59] But then being able to organize my expectations as an author and says, Oh, I actually only have

[00:54:06] one thing to work on. The rest of these are nitpicks. That’s a much better,

[00:54:09] to receive feedback as an author. So that’s one thing to help in the discussion. And then

[00:54:17] there are also code compliments, which I’m a big fan of, but within reason. So like,

[00:54:25] you know, everybody thinks about code review as this very judgmental process,

[00:54:29] you’re supposed to find what’s wrong with each other’s code. And it’s part of why people dread

[00:54:34] it, right? It’s typically seen as a negative thing. But if we try to turn this around,

[00:54:39] and we say, you know, let’s say somebody implemented something in a really novel way,

[00:54:45] like you haven’t seen it before, or they have a really awesome performance savings that you just

[00:54:52] are very impressed by, say something, you know, say that’s really awesome, or good job in figuring

[00:54:58] that out, or it’s some like, bug that everyone has been stuck on, and then someone actually

[00:55:02] finds a fix for it with tests, we hope, right, and then documentation. And all of these things,

[00:55:09] please feel free to actually leave a comment or two, that’s a compliment, if you see something

[00:55:15] you like, say so, where it gets too much as if you’re leaving it for the sake of leaving it,

[00:55:21] you know, that’s where I draw the line. Like, if every other comment, you’re like, Oh, this is

[00:55:25] awesome, or Oh, that’s great, or Oh, this, it kind of loses its value, because now you’re saying

[00:55:30] everything is great. Everything is awesome. And so I say code compliments within reason,

[00:55:36] if you find something really novel, I’m sure the

[00:55:39] author would really appreciate and like that you found some appreciation in the way that they

[00:55:45] wrote something, just in general, like you can sum it up as don’t be a jerk. I know that might

[00:55:51] be harder for some people, or maybe some people don’t know if they are like, you know, some people

[00:55:57] are more direct, some people are not as direct. So maybe that’s actually one way where I would say

[00:56:04] AI, an AI based tool could help, where if you are unsure,

[00:56:09] you can, you know, use an extension that says, Oh, your sentiment is a bit more negative, or it

[00:56:16] seems passive aggressive, or, you know, the tone could be more neutral, something like that is

[00:56:22] where I think AI based tools could help in a code review. But there are people that say, you know,

[00:56:29] let’s have AI write the comment for us. Sure, you can. But again, I always hesitate to say fully

[00:56:39] about AI based tools, because you still have to review it, anything that is AI generated, or AI

[00:56:44] produced, it still needs to be reviewed by humans. So sure, if it saves you some time, and you can

[00:56:49] let some tool write the comment for you in a more neutral tone, just know that you still need to

[00:56:56] look at it to make sure it’s correct. And number two, to make sure it’s actually saying what it

[00:57:02] wants, you know, the intent of what you actually wanted to say, to make sure that’s still in there.

[00:57:08] So you don’t want to lose that part of the community.

[00:57:09] So in terms of comments, yeah, you know, code compliments within reason, don’t be a jerk,

[00:57:17] and try to be as objective as possible, as outcome focused as possible. And just try to write the

[00:57:25] comments that you would want to receive as a reviewer in the most objective way as possible.

[00:57:30] Yeah, don’t be a jerk, I think have a lot of empathy, right, for the people who either the

[00:57:34] author or the reviewer, right. And also, I think it’s very important, like you mentioned,

[00:57:39] forget about the content, right? Because if you don’t, you’re not going to get the feedback that you

[00:57:39] get the ego, right? Like you should not have ego, attack the code, not the person, right? I think

[00:57:44] that’s also important. So one very crucial aspect, the last question I have from the conversation is

[00:57:49] about, you know, code reviews that takes too long. I think this is quite common in many teams. This

[00:57:53] is also an anti-pattern, I believe. What can you say for teams to actually maybe making the code

[00:57:59] review speed faster? And also, interestingly, right, the last State of DevOps report mentioned

[00:58:04] about code review speed as the one technical practice that teams should aspire to become a

[00:58:09] kind of a performance. So maybe a bit advice here. Sure. So code reviews can take a long time

[00:58:16] due to a lot of reasons, but it mostly comes down to the PR itself is too large. And then the PR

[00:58:26] itself being too large is a symptom of other issues. So we’ve touched on the other ones before,

[00:58:33] right? They take too long because they’re gigantic. They take too long because the author

[00:58:38] has not put in enough information in the pull request. So as a reviewer, you’re kind of

[00:58:45] sifting through, you’re trying to make sense of what’s happening, and you can’t really understand

[00:58:50] why this code change is happening the way it is. If you have a person, a single person,

[00:58:56] who’s doing a code review, that could be a reason why it takes too long. So it’s something I call

[00:59:02] the single senior developer bottleneck problem. They’re the only person that can review,

[00:59:08] means they must be on all the PRs, and they’re only a single person. So, you know, take that

[00:59:14] into account and then multiply that if the PRs that they have to look at are large and are

[00:59:20] nondescriptive, you get the idea. It can take very long that way. So we’ve talked about how

[00:59:25] spreading the knowledge might ease that problem. You level up the rest of your team so that there’s

[00:59:30] not just one reviewer available, but multiple reviewers available who are able to share the load.

[00:59:38] And then the thing that I said, which is try to make your PRs smaller. So one thing that is very

[00:59:46] common is, you know, I say atomic changes or like keep it to a single feature or a single bug fix.

[00:59:52] And sometimes the feature itself, it is a single feature, but it’s still like 30, 40, 50 files

[01:00:00] or a lot of lines. And so when it gets to that point, the thing you have to look at at that point

[01:00:08] maybe there’s something that’s lacking in your design or planning phase. And so why did the

[01:00:15] feature get scoped to be that large? Did it actually start out small and then scope creep

[01:00:22] made it that large? Or did you actually all agree and say, no, yeah, this is a single feature. I

[01:00:27] think we can do it and this is going to be fine. If it happens to be that case, that’s where you

[01:00:34] need to start planning on your next design and planning phase. And for the

[01:00:38] foreseeable future, if you don’t want large PRs, then you’re going to have to

[01:00:43] scope your features down much smaller. So really think about the feature and if it has to have

[01:00:50] everything that you are thinking about, because if you absolutely must have it all together in a

[01:00:57] single feature, or at least in one task that is being worked on, then just anticipate that the

[01:01:03] PR is going to be that large, especially if you’re trying to keep to the single feature

[01:01:08] piece.

[01:01:08] So just to have people be a little bit pedantic about that, it’s more about is the change itself

[01:01:16] as small as it can be? And then if you are able to get it that way, the resulting PR is going to

[01:01:22] obviously be much smaller. So the other thing that makes PRs really, really long is let’s say

[01:01:29] somebody asks a question, somebody answers back, somebody doesn’t understand, so they ask to

[01:01:36] clarify, and then someone tries to explain it. And then somebody answers back, and then somebody

[01:01:38] gets it, and then they don’t get it, and then it just becomes a really long discussion online

[01:01:43] asynchronously. If you have the ability to get on a video call, or if you have the luxury of seeing

[01:01:51] the person in person, sometimes it’s best to just, if it’s like two or three comments or four

[01:01:57] comments in, just take it off and actually speak with each other synchronously, because then you

[01:02:03] have a greater chance of getting through whatever communication block that is happening.

[01:02:08] You can walk through the code together. You can go through the description and have them fill in

[01:02:15] what is happening. Sometimes the result of that conversation means there’s actually stuff that

[01:02:21] was missing from the description. And so you can just ask the person, hey, can you add this

[01:02:25] to the description? And then everything’s fine. Sometimes that discussion actually reveals that,

[01:02:31] oh, this is actually work or changes that don’t need to happen right now, and we should

[01:02:38] have this PR. And then you find the reasons for it, and then you close the PR because you don’t

[01:02:45] actually need it. And then the important thing here is to actually let everyone else know on

[01:02:49] the team, hey, we are closing this PR because of X, Y, Z reason that we figured out on this

[01:02:56] discussion. This is the important part about discussions that happen offline is whatever the

[01:03:02] result of that discussion is, it’s important to let everybody else know, not just for knowledge

[01:03:08] transfer.

[01:03:08] For any of those teammates who may be looking at the PR with you, but later down the road,

[01:03:14] again, the documentation, the historical aspect. If you’re wondering, why did this PR close? Or

[01:03:20] how come we never merged this in? This actually would have fixed something. And then if you just

[01:03:24] leave one single comment that says, hey, we took this conversation offline. We talked about this,

[01:03:30] this, and this, and this was the result of our conversation. This is why we’re closing it.

[01:03:35] Think of how much headache you would have, you know, eliminated,

[01:03:38] in the future, even for yourselves, because you just took the time to write that out, right? So if

[01:03:44] you find discussions are getting too long, try that, try taking it synchronously and trying to

[01:03:50] work it out. And then please go back to the PR and write down what happened as a result of that

[01:03:56] discussion. So all of these reasons, they tend to prolong the code review process, because there’s

[01:04:04] just too much cognitive load for the people involved, right? And so, you know, it’s, it’s, it’s

[01:04:05] a huge cognitive load for the people involved, right? And that can come from the multitude of

[01:04:11] reasons that we’ve spoken about. But if you focus on making the PRs smaller, if you focus on, you

[01:04:18] know, erring on the side of communication, and trying to talk to people and getting that

[01:04:23] understanding faster, I think a lot of the reasons that make code reviews long will actually go away.

[01:04:30] And then code reviews will be the quicker, more efficient process that they’re going to have.

[01:04:34] Right. And I would also say that make it as part of the work, right? Make it as part of the

[01:04:41] definition of done, so that you kind of like expect code review to be done as part of the work. And I

[01:04:46] think what you mentioned, all of that could be included in the team working agreement. So again,

[01:04:50] I think it’s a very, very important artifact for the team to kind of like agree on the expectation

[01:04:55] explicitly. So thank you so much for, you know, covering a lot of code review best practices.

[01:05:00] Adrian, I have just one last question before we end our conversation,

[01:05:04] which I think is really important. So Adrian, I have just one last question before we end our conversation, which I

[01:05:04] think is really important. So Adrian, I have just one last question before we end our conversation, which I

[01:05:04] call the three technical leadership wisdom. You can think of it just like an advice that you want to leave to us to learn from you.

[01:05:11] That’s a good question. I think the first one stemming from my own experiences is don’t be afraid to switch to something new.

[01:05:21] That happened to me when I got my student technician job. I had no idea. I was first resetting passwords for people and then it soon

[01:05:29] blossomed into why is my computer slow to how do I install this?

[01:05:34] It becomes more and more problem solving of a higher level. And I found out that I actually really enjoyed that and then taking the chance and applying to technical conferences and actually speaking at conferences and doing that.

[01:05:49] I didn’t know I was going to be good at that. I tried it anyway. That’s my full time job now. And I’m actually pretty good at it. So you never know what might happen if you don’t try it, especially if it’s something that seems interesting to you.

[01:06:03] Try it.

[01:06:04] And then you can say, oh, that’s not for me. And that’s the worst thing that can happen.

[01:06:09] Second piece of wisdom. I wrote this in a really long article back then, but I said, don’t be afraid to fail. I know I said in the beginning I was afraid to fail. But what I find is if you are unafraid to fail gracefully, I’ll put that, you will not only increase your skills and knowledge in what you do, but you will also increase your ability to do things that you don’t do.

[01:06:34] Whatever it is that you’re doing, but you’ll actually level up faster because you learn what it is to solve the problem that initially made you fail in the first place. And so instead of being afraid or instead of being like me initially where I didn’t want to break anything, I walked around eggshells. I stayed stagnant for a while because I just didn’t want to break anything.

[01:06:56] But then the first time I broke something where I actually deleted a couple rows in a table in a database.

[01:07:03] Yeah.

[01:07:04] So freaked out like, oh, no, I’m going to lose my job. Oh, my gosh. But that’s where I was able to talk to a DBA to say, hey, this is how you actually roll back something. Here’s how you can do these operations in a staging environment where it’s not as problematic or not as scary.

[01:07:22] And then here are the ways that you might go through this process again, but do so in a way where you can easily revert back so that you’re not as scared to make changes.

[01:07:34] So if I had never made that failure, if I had never deleted those rows, I would have just been stuck, you know, doing everything as carefully as possible. And I would have never gained that knowledge of environments of doing things in a way that can be reverted back and in doing things in a way with more confidence because I know that I can fix it if I need to.

[01:07:57] So fail fast and fail gracefully.

[01:08:01] And then the last thing I will say for techs.

[01:08:04] As I’ve gone through my career, I’ve gone through what I feel like is everything. I’ve written a book. I’m writing one now. I’m doing courses. I’ve done the Instagram thing, trying to get followers, all of that stuff.

[01:08:17] And at this point in my career, I feel like you should have one hobby that you just don’t monetize. I feel like it’s very prevalent in the tech industry to always have another hustle. You’re building a SaaS on the side.

[01:08:33] You are.

[01:08:34] You’re monetizing. I don’t know, building websites, SEO friendly, like all of these things are cool. But at the end of the day, if everything becomes a goal to make money, it kind of loses its luster. You kind of get burnt out. And I’ve gone through it before where things that were fun that did become a job because the focus was to try to make money. Just I didn’t like it anymore. And not only that, you put a lot of pressure on yourself to make it in the right way.

[01:09:04] And so I say, have a hobby that’s just for you. You bake and you eat bread and you don’t post about it. You just enjoy it. You enjoy it with butter or jam or whatever. And that’s your thing. You don’t have to share it with anybody. You don’t have to make money on it. You don’t have to share the recipe. You don’t have to have a bread baking course. Like, there’s nothing about it. Just have it for yourself. And I think a lot more of us will stay a lot more balanced when it comes to navigating the tech industry.

[01:09:34] Thank you for sharing the last one. I think it’s really, really beautiful, right? So not everything should be monetized, right? Have a hobby that only you can enjoy it. That’s also perfectly fine. So Adrienne, if people want to follow you or maybe contact you for more discussions, right, especially regarding code review, where can they find you online?

[01:09:54] Yes. So LinkedIn, actually, is a pretty good place. I’m pretty active on there. And then Twitter slash X, depending on what you want to know it as.

[01:10:04] And then Instagram, I’m also there. So my handle will be at Adrienne Teca is my first and last name. And you should be able to find me there and I will do my best to answer. So please, if you have any questions about code review, I’d be more than happy to answer them.

[01:10:20] And when are we expecting the book to be published?

[01:10:23] So that just changed. Yeah, it’s going to be summer of next year. So chapter seven is actually going to be released very soon on Meep.

[01:10:33] And that’s the chapter on code review comments. So keep an eye out for that. But after that, I have eight, nine, 10. I have four more chapters to write. And I have a lot of stuff that I want to add to the existing chapters, actually. So summer 2024. Keep an eye out.

[01:10:51] Looking forward for that. I’ve read the Meep, right? So I find it really, really good. So I think all developers should check this book out. So thanks again, Adrienne, for your time.

[01:11:00] Thank you, Henry. It was great being here.

[01:11:03] Thank you for listening to this episode and for staying right until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you’re new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better. You can also find the full show notes of this conversation on the episode page at techleadjournal.dev website, including the full show notes of this podcast.

[01:11:33] You can also find the full transcript, interesting quotes and links to the resources mentioned from the conversation. And lastly, make sure to subscribe to the show’s mailing list on techleadjournal.dev to get notified for any future episodes. Stay tuned for the next Tech Lead Journal episode. And until then, goodbye.

Visão de gráfico