Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Write Code Reviews That Actually Get Read
Transcript
- Lucas: So, you push a pull request, you're proud of it, you write a clear description, and then... crickets. Or worse, you get a drive-by 'LGTM' that clearly means 'I looked at the title for two seconds.' Luna: Oh, the dreaded Looks Good To Me that absolutely does not mean the code was reviewed. I think every engineer has felt that sting. Lucas: Right. And the flip side is also painful — you get fifteen nitpicky comments about whitespace, but nobody actually reads your core logic. Today I want to talk about a weirdly under-discussed skill: how to write a code review that people actually want to read. Luna: Wait — you mean the review itself, not the code change being reviewed? Lucas: Exactly. There's tons of advice about 'how to review code' — check for edge cases, run the tests, look for security holes. But almost nobody teaches you how to structure your feedback so that the author actually engages with it. And the data is pretty stark. Luna: I love data. What've you got? Lucas: There's a 2023 paper from Microsoft Research — they studied thousands of code reviews across their engineering org. One finding that jumped out: when a diff is over 400 lines of changed code, the chance of getting any substantive review feedback drops by 60 percent. Reviewers literally give up before they start. Luna: That's huge. And it's not just about the reviewer being lazy — it's cognitive overload. You see a wall of red and green and your brain just nopes out. Lucas: Right. So one obvious lever is: keep your diffs small. But even when you can't — like a refactor touching many files — the way you the review request makes a difference. I've seen senior engineers at Meta write a short summary that says: 'This is a 600-line refactor. I recommend reviewing file by file in this order — start with types.go, then the main logic, then util changes. The tests are at the end.' Luna: That's literally scaffolding the cognitive load for the reviewer. I love that. Lucas: It's a small thing, but it changes the reviewer's experience from 'Ugh, 600 lines' to 'Okay, I have a map.' And it signals respect for their time. Which — and this is the key psychological insight — makes them more likely to give you a thorough review. Luna: Because they feel like you've already done part of the work for them. Reciprocity. Lucas: Exactly. And this ties into something I think about a lot: the 'cost of review' is real. Every time someone looks at your code, they're spending mental energy they could spend on their own work. If you can reduce that cost — by writing a good description, by segmenting your changes, by using commit messages that tell a story — you're basically paying them in cognitive currency. Luna: I want to zoom in on one specific tactic that I've seen work wonders: the 'prefix commit' habit. Do you know this one? Lucas: Tell me. Luna: So, before you even write the implementation, you push a commit that contains only the interface, the function signatures, maybe the types — no logic. And you tag it as 'PREFIX: design review, not code review.' Then you ask your reviewers to look at that first. Once they sign off on the design, you push the implementation on top. The review becomes 'does this match the design?' instead of 'let me understand what you're trying to do.' Lucas: That is brilliant. And it directly addresses one of the biggest pain points in code review: the reviewer has to reverse-engineer your intent. If they already know the intent from the interface review, the implementation review is way faster. Luna: And it also prevents the classic trap where someone spends 20 minutes reviewing your implementation, then says 'actually, I think the whole approach is wrong.' Because you caught that at the prefix stage. Lucas: Right. That's the most expensive kind of feedback — the 'start over because your architecture doesn't scale' comment. You want that as early as possible. The prefix commit creates a cheap checkpoint. Luna: So what about the tone of the comments themselves? I've seen reviews where every comment is a demand — 'fix this', 'change this', 'this is wrong'. Versus reviews that say 'What do you think about...?' or 'Have you considered...?'. Lucas: There's research on that too. A study at Google found that framing feedback as a question — even when you're pretty sure it's a bug — leads to 30 percent fewer back and forth rounds. Because the author feels less defensive and more curious. And defensiveness is the enemy of actually absorbing feedback. Luna: I've heard this called 'the Socratic code review'. You ask questions that lead the author to discover the issue themselves, rather than handing them the answer. Lucas: And if you want to be really intentional about it, you can separate your comments into 'blocking' and 'non-blocking' explicitly. At Amazon, that's almost a cultural rule — you label your comments 'BLOCKING' or 'NIT' or 'SUGGESTION'. It removes ambiguity. The author knows exactly which comments they have to act on and which are just polish ideas. Luna: Because nothing's worse than getting a review where you can't tell if the reviewer thinks a comment is a hard requirement or a nice to have. So you end up debating every single one, or ignoring them all. Lucas: Exactly. And that's where the 'code review as conversation' model breaks down. It's not a chat — it's a decision-making process. The best reviewers treat it like that. Luna: And if you're the author, you can also set expectations up front. Like, 'I'm looking for feedback on the architecture primarily, and I'm less worried about style right now.' That directs the reviewer's attention to where it's most useful. Lucas: That's a pro move. And it's respectful — you're telling the reviewer 'don't waste your time on style if I'm going to rewrite this section anyway.' Luna: You know, it's funny — we talk a lot on this show about interview prep and career strategy, but something as day-to-day as code review can have a massive impact on your reputation. If you're known as someone who writes thoughtful, constructive, low-friction reviews, people want to work with you. And if you're known as someone who writes tl;dr reviews or nitpicky flame wars, people avoid you. Lucas: It's a career multiplier. And it's totally learnable. I think a lot of engineers treat review style as a personality trait — 'I'm just a blunt person' — but really it's a skill you can practice. Just like writing good commit messages. Luna: If today's conversation gave you something usable, and you'd like to support the show staying ad-free and independent, you can buy us a coffee at buy me a coffee dot com slash fexingo. No pressure — just a way to keep these episodes coming, if they're helpful to you. Lucas: Yeah, we really appreciate that. It's listener support that keeps this going. So thank you to anyone who's ever chipped in — it genuinely makes a difference. Luna: Alright, back to code review. One more tactic I want to mention: the 'review buddy' system. At Google, some teams pair up engineers specifically for code review — not as a formal pair programming session, but as a commitment to review each other's diffs within a few hours. Lucas: That's a great way to beat the bus-factor problem. If you have a review buddy, you're not waiting for whoever happens to be free. And you build a rhythm — you review their stuff fast, they review yours fast. It's a force multiplier. Luna: And the relationship means you're more likely to give honest, detailed feedback, because you know them. You're not worried about being polite to a stranger. Lucas: Right. So let's pull this together. A few concrete takeaways from today: keep diffs under 400 lines when possible. If not, provide a review roadmap. Use prefix commits for design sign-off. Label comments as blocking or non-blocking. Frame feedback as questions to reduce defensiveness. And consider a review buddy to speed things up. Luna: And never forget: the goal of code review isn't just to catch bugs — it's to share knowledge and build shared ownership. A good review teaches the author something. A great review makes the codebase better and the team smarter. Lucas: Well said. So next time you open a PR, spend five minutes writing the review request as carefully as you wrote the code. It'll pay off. Luna: I'm going to try the prefix commit thing this week. I'll let you know how it goes. Lucas: Please do. And if listeners try any of these, drop us a note — we'd love to hear what works. For Fexingo Business, I'm Lucas. Luna: And I'm Luna. See you next time.