[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"verticals":3,"article-code-review-comments":44,"search-suggestions":296,"related-code-review-comments":343,"comments-01a0ec73-1496-7457-92a3-031fc4cd640c":391},[4,20,32],{"id":5,"slug":6,"name":7,"tagline":8,"description":9,"accentFrom":10,"accentTo":11,"icon":12,"defaultLocale":13,"locales":14,"features":16,"position":19},"019fe637-3d33-714b-b57f-23e163ffca0c","dev","Web Development","Read it. Run it. Prove it.","A post a day on modern web development — most with an editable playground and a quiz that explains every answer. Free, no account needed.","violet-500","cyan-400","◇","en",[13,15],"fa",{"courses":17,"paths":17,"articles":17,"exams":18,"flashcards":18,"packages":17,"community":17,"certificates":17,"teams":17,"commerce":17},true,false,0,{"id":21,"slug":22,"name":23,"tagline":24,"description":25,"accentFrom":26,"accentTo":10,"icon":27,"defaultLocale":13,"locales":28,"features":30,"position":31},"019fe637-3dc2-754c-8657-0f175bfee7c6","lang","Languages","Learn a language the way you learn a codebase.","Grammar explained the way good documentation explains an API — one idea at a time, each with a quiz.","amber-400","⌘",[13,15,29],"es",{"courses":18,"paths":18,"articles":17,"exams":18,"flashcards":17,"packages":18,"community":17,"certificates":17,"teams":18,"commerce":18},2,{"id":33,"slug":34,"name":35,"tagline":36,"description":37,"accentFrom":38,"accentTo":39,"icon":40,"defaultLocale":13,"locales":41,"features":42,"position":43},"7b3c16f2-931d-410e-802e-e1fa4edab7de","soft","Soft Skills","The half of the job nobody wrote documentation for.","Weekly, on the parts of working life that decide more than your code does — first weeks, meetings, interviews, promotions, and the people around you. Written from what actually happens, and recorded as a podcast you can listen to on the walk.","emerald-400","teal-300","◉",[13],{"courses":18,"paths":18,"articles":17,"exams":18,"flashcards":18,"packages":18,"community":17,"certificates":18,"teams":18,"commerce":18},3,{"id":45,"slug":46,"title":47,"subtitle":48,"excerpt":49,"coverUrl":50,"locale":13,"readingMinutes":51,"publishedAt":52,"viewCount":53,"likeCount":19,"commentCount":19,"author":54,"vertical":59,"topic":60,"tags":63,"_count":76,"playground":48,"body":77,"bodyMd":273,"seo":274,"translationGroupId":277,"series":278,"podcastUrl":48,"verticalId":33,"thread":291,"assessments":293,"translations":294,"quiz":48},"01a0ec73-1496-7457-92a3-031fc4cd640c","code-review-comments","Why your code review comments sound harsher than you meant",null,"A review comment loses your tone on the way, and the author fills it back in — usually with a worse one, at the exact moment they're most attached to the work. Here's how to put the weight back into what you write, the words to use, and when to stop typing.","\u002Fmedia\u002Fcovers\u002Fcode-review-comments.png",8,"2026-09-30T06:11:19.028Z",27,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},"019fe637-3c25-7088-9034-39c9f15dc3c8","Parsa Jiravand","parsa","Frontend engineer · building bestpractic",{"slug":34,"name":35,"accentFrom":38,"accentTo":39},{"slug":61,"name":62},"people","The people around you",[64,67,70,73],{"slug":65,"name":66,"color":48},"career","Career",{"slug":68,"name":69,"color":48},"codereview","Codereview",{"slug":71,"name":72,"color":48},"beginners","Beginners",{"slug":74,"name":75,"color":48},"discuss","Discuss",{"assessments":19},{"blocks":78,"version":272},[79,83,87,90,93,96,99,104,107,110,113,116,119,122,125,128,131,134,137,140,143,146,149,152,155,158,161,164,167,170,174,177,180,183,186,189,192,195,198,201,204,208,211,214,217,220,223,226,229,232,235,238,241,248,251,254,257,260,266,269],{"id":80,"html":81,"type":82},"b1","\u003C!-- hello:start -->","paragraph",{"id":84,"html":85,"type":86},"b2","\u003Cp>👋 \u003Cstrong>I'm Parsa Jiravand — I work in IT, and this is Best Practice.\u003C\u002Fstrong> One article every day, one soft-skills episode every week. It all lives at \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002F\">bestpractic.org\u003C\u002Fa>\u003C\u002Fstrong> — come join us.\u003C\u002Fp>\n","quote",{"id":88,"html":89,"type":82},"b3","\u003C!-- hello:end -->",{"id":91,"html":92,"type":82},"b4","\u003Cp>You left fourteen comments on a pull request this morning, somewhere between standup and your next meeting. Twelve were small. One just said "nice". One was actually important — the retry logic could charge someone twice.\u003C\u002Fp>",{"id":94,"html":95,"type":82},"b5","\u003Cp>By lunch the author has replied "done" to all fourteen. Including the one that was a question. And in the afternoon they're a little short with you in chat, and you can't work out what you did.\u003C\u002Fp>",{"id":97,"html":98,"type":82},"b6","\u003Cp>You didn't write anything rude. Read it back — every comment is reasonable. That's exactly what makes it hard to fix.\u003C\u002Fp>",{"id":100,"html":101,"text":102,"type":103,"level":31},"b7","What's actually going on","What's actually going on","heading",{"id":105,"html":106,"type":82},"b8","\u003Cp>A review comment takes about forty seconds to write. Usually in a fine mood, usually between two other things, and you know exactly how you meant it, because you can hear your own voice saying it.\u003C\u002Fp>",{"id":108,"html":109,"type":82},"b9","\u003Cp>It's read by someone who just spent three days on this. At the moment they most want it to be finished. And they can't hear your voice. They get the words and nothing else.\u003C\u002Fp>",{"id":111,"html":112,"type":82},"b10","\u003Cp>So they put a voice back in. Not yours — theirs. Whatever they're feeling about the work right then is the tone your comment arrives in. People are far more confident their tone survives writing than it actually does; there's a well-known study on email where readers picked up the intended tone barely more often than a coin flip. A code review is that, with the added bonus that the reader has just been told what's wrong with their work.\u003C\u002Fp>",{"id":114,"html":115,"type":82},"b11","\u003Cp>And the first thing text loses isn't friendliness. It's \u003Cstrong>weight.\u003C\u002Fstrong>\u003C\u002Fp>",{"id":117,"html":118,"type":82},"b12","\u003Cp>Out loud, you'd do the weighting without thinking. "Oh — tiny thing, the name's a bit off." "Okay, this one actually matters." Your face and your voice tell them which is which. In a review tool, every comment is the same grey box in the same font. \u003Ccode>nit: rename to userIds\u003C\u002Fcode> and "this charges the card twice if the job retries" look identical on the screen.\u003C\u002Fp>",{"id":120,"html":121,"type":82},"b13","\u003Cp>So the author has to guess which ones they're allowed to push back on. And the safe guess, the one that doesn't risk anything, is to do all of them. That's what fourteen "done"s is. Not agreement. Compliance. And compliance carries a little resentment that shows up later, in chat, about something else entirely.\u003C\u002Fp>",{"id":123,"html":124,"type":82},"b14","\u003Cp>When every comment weighs the same, the only weight left is the count. Fourteen comments reads as a verdict on the whole PR, whatever each one actually says.\u003C\u002Fp>",{"id":126,"html":127,"type":82},"b15","\u003Cp>There's a second thing text strips, and it's the shape of a question. "Why did you use a map here?" said across a desk with a curious face is a question. Typed, it's a demand to justify yourself. A "why" with no reasoning attached reads as an accusation, and the person who wrote it almost never meant one.\u003C\u002Fp>",{"id":129,"html":130,"text":130,"type":103,"level":31},"b16","So what do you actually type?",{"id":132,"html":133,"type":82},"b17","\u003Cp>\u003Cstrong>Say how much it all weighs, before anything else.\u003C\u002Fstrong>\u003C\u002Fp>",{"id":135,"html":136,"type":82},"b18","\u003Cp>One line at the top of the review, above every individual comment:\u003C\u002Fp>",{"id":138,"html":139,"type":82},"b19","\u003Cp>\u003Cem>"Looks good overall. One real thing — the retry on line 84. Everything else is small and optional."\u003C\u002Fem>\u003C\u002Fp>",{"id":141,"html":142,"type":82},"b20","\u003Cp>That sentence does more work than the other fourteen put together. It gets read first, and it changes how every comment underneath it is read. The author stops scanning for the verdict, because you've already told them what it is.\u003C\u002Fp>",{"id":144,"html":145,"type":82},"b21","\u003Cp>Then weight each comment in words, at the very start: \u003Cem>"Blocking:"\u003C\u002Fem>, \u003Cem>"Non-blocking:"\u003C\u002Fem>, \u003Cem>"Nit, ignore if you like:"\u003C\u002Fem>. There's a whole convention for this — Conventional Comments — but you don't need the spec. You need the author to be able to answer the one question they're silently asking of every single comment: \u003Cem>do I have to?\u003C\u002Fem> A label that says "no" also gives them permission to disagree with the small stuff without it turning into a fight.\u003C\u002Fp>",{"id":147,"html":148,"type":82},"b22","\u003Cp>\u003Cstrong>Put your reasoning inside the question.\u003C\u002Fstrong>\u003C\u002Fp>",{"id":150,"html":151,"type":82},"b23","\u003Cp>Not \u003Cem>"Why a map here?"\u003C\u002Fem> Instead:\u003C\u002Fp>",{"id":153,"html":154,"type":82},"b24","\u003Cp>\u003Cem>"I think I'm missing something — is the map because of the lookups? I'd have reached for an array."\u003C\u002Fem>\u003C\u002Fp>",{"id":156,"html":157,"type":82},"b25","\u003Cp>Now they're correcting your guess instead of defending their choice. Correcting is easy. Defending is tiring and faintly humiliating, even when you win. And half the time the answer is "yep, the lookups", they type three words, and the thread's over.\u003C\u002Fp>",{"id":159,"html":160,"type":82},"b26","\u003Cp>\u003Cstrong>After the second reply, stop typing.\u003C\u002Fstrong>\u003C\u002Fp>",{"id":162,"html":163,"type":82},"b27","\u003Cp>Threads escalate on their own in text. Each reply gets a little longer and a little more carefully worded than the last, and careful reads as cold — so both of you feel the other getting frostier while neither of you actually is. By the third round you're not discussing a map anymore. You're discussing who's right.\u003C\u002Fp>",{"id":165,"html":166,"type":82},"b28","\u003Cp>\u003Cem>"This is getting long in text — got ten minutes to talk it through?"\u003C\u002Fem>\u003C\u002Fp>",{"id":168,"html":169,"type":82},"b29","\u003Cp>Then, after the call, write one line back in the thread saying what you agreed. The call was for the two of you. The line is for whoever opens this PR in a year.\u003C\u002Fp>",{"id":171,"html":172,"text":173,"type":103,"level":31},"b30","If you're the one reading them","If you're the one reading them",{"id":175,"html":176,"type":82},"b31","\u003Cp>All of this runs in reverse too, and it's worth knowing when you're the author.\u003C\u002Fp>",{"id":178,"html":179,"type":82},"b32","\u003Cp>You're supplying the tone. That's not a flaw in you, it's just how text works — but it does mean the harsh version you heard was at least partly your own. Try reading the comment again in the voice of the reviewer on their best day. It's usually closer to what they meant.\u003C\u002Fp>",{"id":181,"html":182,"type":82},"b33","\u003Cp>And the reply that ends most threads in one round:\u003C\u002Fp>",{"id":184,"html":185,"type":82},"b34","\u003Cp>\u003Cem>"I went this way because the list can get huge. Happy to switch if you still think the array's clearer."\u003C\u002Fem>\u003C\u002Fp>",{"id":187,"html":188,"type":82},"b35","\u003Cp>You've given your reason and handed back the decision. On the small stuff that costs you almost nothing, and it makes you easy to review — which matters more than it should, and I'll come back to it. On the thing you genuinely care about, don't hand it back. Say you'd like to keep it, and why. Just pick one or two of those per PR, not fourteen.\u003C\u002Fp>",{"id":190,"html":191,"text":191,"type":103,"level":31},"b36","Where this backfires",{"id":193,"html":194,"type":82},"b37","\u003Cp>Labels don't fix volume. Twenty-five comments that each start with "nit:" still read as twenty-five comments. If most of your review is nits, the fix isn't a better label, it's fewer comments. Gather the small ones into a single comment, or let some of them go. Not every naming preference needs to be in the permanent record.\u003C\u002Fp>",{"id":196,"html":197,"type":82},"b38","\u003Cp>Softening can bury the thing that matters. This one catches junior reviewers hardest: \u003Cem>"Might be worth maybe looking at whether this could possibly retry twice?"\u003C\u002Fem> The real bug is now wrapped in so much padding that it reads as optional, and it gets merged. If you're junior and reviewing someone senior, you don't need more padding. You need the label and one plain sentence: \u003Cem>"Blocking, I think — this runs twice if the job retries. Tell me if I've misread it."\u003C\u002Fem> The "tell me if I've misread it" is honest cover. The label keeps the weight.\u003C\u002Fp>",{"id":199,"html":200,"type":82},"b39","\u003Cp>If you're senior, it flips. Your question is an instruction whether you meant it as one or not. "Have you considered a map?" from a staff engineer gets you a map. Softer wording won't change that — only saying it will: \u003Cem>"Genuinely optional. I'd be fine either way."\u003C\u002Fem>\u003C\u002Fp>",{"id":202,"html":203,"type":82},"b40","\u003Cp>And some teams are blunt, and it's working for them. Padding a comment in a room like that reads as fake, or worse, as manager voice. Before you change how you write, go and read how the reviewers your team actually trusts write. Match them, not me.\u003C\u002Fp>",{"id":205,"html":206,"text":207,"type":103,"level":31},"b41","The part that isn't fair","The part that isn't fair",{"id":209,"html":210,"type":82},"b42","\u003Cp>The same comment is a different comment depending on who writes it. A lead's "hmm" weighs more than a new joiner's whole paragraph. That's rank, and text doesn't hide it. It amplifies it.\u003C\u002Fp>",{"id":212,"html":213,"type":82},"b43","\u003Cp>Code review is also a quiet ledger. People who are easy to review tend to get faster reviews with fewer comments. People who fight every thread tend to get slow, thorough reviews for a long time afterwards. Nobody decided that. It just accumulates. It isn't fair, and it's real. The practical version: don't spend yourself on the small threads. Save the argument for the one that matters, and it'll land as the one that matters.\u003C\u002Fp>",{"id":215,"html":216,"type":82},"b44","\u003Cp>Then there's this year's version. More of the code in a pull request was written with an assistant now, so there's more of it, and reviewers are tired, and tired comments are short, and short comments read as cold. There's also a brand new worst comment available: \u003Cem>"Did an AI write this?"\u003C\u002Fem> Whether it did or not, the author hears "you didn't think about this." If that's what you mean, leave the useful version: \u003Cem>"I can't follow why this handles the empty case like this — can you walk me through it?"\u003C\u002Fem> That's the comment you actually wanted to leave anyway.\u003C\u002Fp>",{"id":218,"html":219,"type":82},"b45","\u003Cp>Some of how a review lands is simply the other person's day, and you can't touch that. What you can do is make sure it doesn't depend on it.\u003C\u002Fp>",{"id":221,"html":222,"text":222,"type":103,"level":31},"b46","Monday",{"id":224,"html":225,"type":82},"b47","\u003Cp>The next review you leave, write the summary line before you write anything else. One sentence: how many things actually matter, and which one.\u003C\u002Fp>",{"id":227,"html":228,"type":82},"b48","\u003Cp>\u003Cem>"One real thing, the rest are optional."\u003C\u002Fem>\u003C\u002Fp>",{"id":230,"html":231,"type":82},"b49","\u003Cp>Then go back through your comments and label each one. If you've left more nits than you'd be comfortable receiving, delete a few.\u003C\u002Fp>",{"id":233,"html":234,"type":82},"b50","\u003Cp>That's the whole practice. You're not changing what you think about the code. You're putting back the part that text took out.\u003C\u002Fp>",{"id":236,"html":237,"type":82},"b51","\u003C!-- related:start -->",{"id":239,"html":240,"text":240,"type":103,"level":31},"b52","📚 Read next",{"id":242,"type":243,"items":244,"ordered":18},"b53","list",[245,246,247],"\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fspeaking-up-in-meetings\">You're not quiet in meetings, you're editing\u003C\u002Fa>","\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Ffirst-week-at-a-new-job\">Nobody tells you the question window is closing\u003C\u002Fa>","\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Ftypescript-won-what-it-bought-us\">TypeScript Won. Here's What That Actually Bought Us.\u003C\u002Fa>",{"id":249,"html":250,"type":82},"b54","\u003C!-- related:end -->",{"id":252,"type":253},"b55","divider",{"id":255,"html":256,"type":82},"b56","\u003Cp>🚀 \u003Cstrong>Want more like this?\u003C\u002Fstrong> Every guide, playground, and quiz lives on \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002F\">bestpractic.org\u003C\u002Fa>\u003C\u002Fstrong> — open it and \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002F\">sign up free\u003C\u002Fa>\u003C\u002Fstrong> so the next one finds you.\u003C\u002Fp>",{"id":258,"html":259,"type":82},"b57","\u003Cp>\u003Cem>Thanks for reading! Let's stay connected:\u003C\u002Fem>\u003C\u002Fp>",{"id":261,"type":243,"items":262,"ordered":18},"b58",[263,264,265],"⭐ \u003Cstrong>GitHub\u003C\u002Fstrong> — follow me and star the projects: \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fparsajiravand\">github.com\u002Fparsajiravand\u003C\u002Fa>","💬 \u003Cstrong>Discord\u003C\u002Fstrong> — join the frontend best-practices community: \u003Ca href=\"https:\u002F\u002Fdiscord.gg\u002Fd9KRhuAwQ\">discord.gg\u002Fd9KRhuAwQ\u003C\u002Fa>","📸 \u003Cstrong>Instagram\u003C\u002Fstrong> — frontend best practices, daily: \u003Ca href=\"https:\u002F\u002Fwww.instagram.com\u002Fbestpractice___\u002F\">@bestpractice___\u003C\u002Fa>",{"id":267,"html":268,"type":82},"b59","\u003Cp>🤝 \u003Cstrong>Want to make something with us?\u003C\u002Fstrong> Write a piece, come on the podcast, or bring an idea that should exist — \u003Cstrong>\u003Ca href=\"https:\u002F\u002Fbestpractic.org\u002Fcollaborate\">bestpractic.org\u002Fcollaborate\u003C\u002Fa>\u003C\u002Fstrong>.\u003C\u002Fp>",{"id":270,"html":271,"type":82},"b60","\u003Cp>\u003Cem>And if this one helped, send it to the person you know who needs it this week. That's what keeps these coming.\u003C\u002Fem>\u003C\u002Fp>",1,"\u003C!-- hello:start -->\n\n> 👋 **I'm Parsa Jiravand — I work in IT, and this is Best Practice.** One article every day, one soft-skills episode every week. It all lives at **[bestpractic.org](https:\u002F\u002Fbestpractic.org\u002F)** — come join us.\n\n\u003C!-- hello:end -->\n\nYou left fourteen comments on a pull request this morning, somewhere between standup and your next meeting. Twelve were small. One just said \"nice\". One was actually important — the retry logic could charge someone twice.\n\nBy lunch the author has replied \"done\" to all fourteen. Including the one that was a question. And in the afternoon they're a little short with you in chat, and you can't work out what you did.\n\nYou didn't write anything rude. Read it back — every comment is reasonable. That's exactly what makes it hard to fix.\n\n## What's actually going on\n\nA review comment takes about forty seconds to write. Usually in a fine mood, usually between two other things, and you know exactly how you meant it, because you can hear your own voice saying it.\n\nIt's read by someone who just spent three days on this. At the moment they most want it to be finished. And they can't hear your voice. They get the words and nothing else.\n\nSo they put a voice back in. Not yours — theirs. Whatever they're feeling about the work right then is the tone your comment arrives in. People are far more confident their tone survives writing than it actually does; there's a well-known study on email where readers picked up the intended tone barely more often than a coin flip. A code review is that, with the added bonus that the reader has just been told what's wrong with their work.\n\nAnd the first thing text loses isn't friendliness. It's **weight.**\n\nOut loud, you'd do the weighting without thinking. \"Oh — tiny thing, the name's a bit off.\" \"Okay, this one actually matters.\" Your face and your voice tell them which is which. In a review tool, every comment is the same grey box in the same font. `nit: rename to userIds` and \"this charges the card twice if the job retries\" look identical on the screen.\n\nSo the author has to guess which ones they're allowed to push back on. And the safe guess, the one that doesn't risk anything, is to do all of them. That's what fourteen \"done\"s is. Not agreement. Compliance. And compliance carries a little resentment that shows up later, in chat, about something else entirely.\n\nWhen every comment weighs the same, the only weight left is the count. Fourteen comments reads as a verdict on the whole PR, whatever each one actually says.\n\nThere's a second thing text strips, and it's the shape of a question. \"Why did you use a map here?\" said across a desk with a curious face is a question. Typed, it's a demand to justify yourself. A \"why\" with no reasoning attached reads as an accusation, and the person who wrote it almost never meant one.\n\n## So what do you actually type?\n\n**Say how much it all weighs, before anything else.**\n\nOne line at the top of the review, above every individual comment:\n\n*\"Looks good overall. One real thing — the retry on line 84. Everything else is small and optional.\"*\n\nThat sentence does more work than the other fourteen put together. It gets read first, and it changes how every comment underneath it is read. The author stops scanning for the verdict, because you've already told them what it is.\n\nThen weight each comment in words, at the very start: *\"Blocking:\"*, *\"Non-blocking:\"*, *\"Nit, ignore if you like:\"*. There's a whole convention for this — Conventional Comments — but you don't need the spec. You need the author to be able to answer the one question they're silently asking of every single comment: *do I have to?* A label that says \"no\" also gives them permission to disagree with the small stuff without it turning into a fight.\n\n**Put your reasoning inside the question.**\n\nNot *\"Why a map here?\"* Instead:\n\n*\"I think I'm missing something — is the map because of the lookups? I'd have reached for an array.\"*\n\nNow they're correcting your guess instead of defending their choice. Correcting is easy. Defending is tiring and faintly humiliating, even when you win. And half the time the answer is \"yep, the lookups\", they type three words, and the thread's over.\n\n**After the second reply, stop typing.**\n\nThreads escalate on their own in text. Each reply gets a little longer and a little more carefully worded than the last, and careful reads as cold — so both of you feel the other getting frostier while neither of you actually is. By the third round you're not discussing a map anymore. You're discussing who's right.\n\n*\"This is getting long in text — got ten minutes to talk it through?\"*\n\nThen, after the call, write one line back in the thread saying what you agreed. The call was for the two of you. The line is for whoever opens this PR in a year.\n\n## If you're the one reading them\n\nAll of this runs in reverse too, and it's worth knowing when you're the author.\n\nYou're supplying the tone. That's not a flaw in you, it's just how text works — but it does mean the harsh version you heard was at least partly your own. Try reading the comment again in the voice of the reviewer on their best day. It's usually closer to what they meant.\n\nAnd the reply that ends most threads in one round:\n\n*\"I went this way because the list can get huge. Happy to switch if you still think the array's clearer.\"*\n\nYou've given your reason and handed back the decision. On the small stuff that costs you almost nothing, and it makes you easy to review — which matters more than it should, and I'll come back to it. On the thing you genuinely care about, don't hand it back. Say you'd like to keep it, and why. Just pick one or two of those per PR, not fourteen.\n\n## Where this backfires\n\nLabels don't fix volume. Twenty-five comments that each start with \"nit:\" still read as twenty-five comments. If most of your review is nits, the fix isn't a better label, it's fewer comments. Gather the small ones into a single comment, or let some of them go. Not every naming preference needs to be in the permanent record.\n\nSoftening can bury the thing that matters. This one catches junior reviewers hardest: *\"Might be worth maybe looking at whether this could possibly retry twice?\"* The real bug is now wrapped in so much padding that it reads as optional, and it gets merged. If you're junior and reviewing someone senior, you don't need more padding. You need the label and one plain sentence: *\"Blocking, I think — this runs twice if the job retries. Tell me if I've misread it.\"* The \"tell me if I've misread it\" is honest cover. The label keeps the weight.\n\nIf you're senior, it flips. Your question is an instruction whether you meant it as one or not. \"Have you considered a map?\" from a staff engineer gets you a map. Softer wording won't change that — only saying it will: *\"Genuinely optional. I'd be fine either way.\"*\n\nAnd some teams are blunt, and it's working for them. Padding a comment in a room like that reads as fake, or worse, as manager voice. Before you change how you write, go and read how the reviewers your team actually trusts write. Match them, not me.\n\n## The part that isn't fair\n\nThe same comment is a different comment depending on who writes it. A lead's \"hmm\" weighs more than a new joiner's whole paragraph. That's rank, and text doesn't hide it. It amplifies it.\n\nCode review is also a quiet ledger. People who are easy to review tend to get faster reviews with fewer comments. People who fight every thread tend to get slow, thorough reviews for a long time afterwards. Nobody decided that. It just accumulates. It isn't fair, and it's real. The practical version: don't spend yourself on the small threads. Save the argument for the one that matters, and it'll land as the one that matters.\n\nThen there's this year's version. More of the code in a pull request was written with an assistant now, so there's more of it, and reviewers are tired, and tired comments are short, and short comments read as cold. There's also a brand new worst comment available: *\"Did an AI write this?\"* Whether it did or not, the author hears \"you didn't think about this.\" If that's what you mean, leave the useful version: *\"I can't follow why this handles the empty case like this — can you walk me through it?\"* That's the comment you actually wanted to leave anyway.\n\nSome of how a review lands is simply the other person's day, and you can't touch that. What you can do is make sure it doesn't depend on it.\n\n## Monday\n\nThe next review you leave, write the summary line before you write anything else. One sentence: how many things actually matter, and which one.\n\n*\"One real thing, the rest are optional.\"*\n\nThen go back through your comments and label each one. If you've left more nits than you'd be comfortable receiving, delete a few.\n\nThat's the whole practice. You're not changing what you think about the code. You're putting back the part that text took out.\n\n\u003C!-- related:start -->\n\n## 📚 Read next\n\n- [You're not quiet in meetings, you're editing](https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fspeaking-up-in-meetings)\n- [Nobody tells you the question window is closing](https:\u002F\u002Fbestpractic.org\u002Fblog\u002Ffirst-week-at-a-new-job)\n- [TypeScript Won. Here's What That Actually Bought Us.](https:\u002F\u002Fbestpractic.org\u002Fblog\u002Ftypescript-won-what-it-bought-us)\n\n\u003C!-- related:end -->\n\n---\n\n🚀 **Want more like this?** Every guide, playground, and quiz lives on **[bestpractic.org](https:\u002F\u002Fbestpractic.org\u002F)** — open it and **[sign up free](https:\u002F\u002Fbestpractic.org\u002F)** so the next one finds you.\n\n*Thanks for reading! Let's stay connected:*\n\n- ⭐ **GitHub** — follow me and star the projects: [github.com\u002Fparsajiravand](https:\u002F\u002Fgithub.com\u002Fparsajiravand)\n- 💬 **Discord** — join the frontend best-practices community: [discord.gg\u002Fd9KRhuAwQ](https:\u002F\u002Fdiscord.gg\u002Fd9KRhuAwQ)\n- 📸 **Instagram** — frontend best practices, daily: [@bestpractice___](https:\u002F\u002Fwww.instagram.com\u002Fbestpractice___\u002F)\n\n🤝 **Want to make something with us?** Write a piece, come on the podcast, or bring an idea that should exist — **[bestpractic.org\u002Fcollaborate](https:\u002F\u002Fbestpractic.org\u002Fcollaborate)**.\n\n*And if this one helped, send it to the person you know who needs it this week. That's what keeps these coming.*",{"title":47,"canonical":275,"description":276},"https:\u002F\u002Fbestpractic.org\u002Fblog\u002Fcode-review-comments","A review comment loses your tone on the way, and the author fills it back in — usually with a worse one, at the exact moment they're most attached to the work. Here's how to put th","01a0ec73-1496-7457-92a3-04c6e2ec93f1",{"name":35,"part":43,"total":43,"items":279},[280,285,290],{"slug":281,"title":282,"publishedAt":283,"readingMinutes":284},"first-week-at-a-new-job","Nobody tells you the question window is closing","2026-08-25T08:53:57.723Z",7,{"slug":286,"title":287,"publishedAt":288,"readingMinutes":289},"speaking-up-in-meetings","You're not quiet in meetings, you're editing","2026-09-02T10:58:23.112Z",9,{"slug":46,"title":47,"publishedAt":52,"readingMinutes":51},{"id":292,"locked":18},"01a0ec73-14b9-7558-8cbc-1368f6721c17",[],[295],{"locale":13,"slug":46},[297,301,305,309,313,317,321,325,329,333,337,340],{"slug":298,"name":299,"articles":300},"webdev","Webdev",115,{"slug":302,"name":303,"articles":304},"javascript","Javascript",97,{"slug":306,"name":307,"articles":308},"frontend","Frontend",75,{"slug":310,"name":311,"articles":312},"tutorial","Tutorial",41,{"slug":314,"name":315,"articles":316},"css","Css",36,{"slug":318,"name":319,"articles":320},"typescript","Typescript",17,{"slug":322,"name":323,"articles":324},"performance","Performance",14,{"slug":326,"name":327,"articles":328},"react","React",13,{"slug":330,"name":331,"articles":332},"browser","Browser",11,{"slug":334,"name":335,"articles":336},"node","Node",10,{"slug":338,"name":339,"articles":51},"html","Html",{"slug":341,"name":342,"articles":284},"accessibility","Accessibility",{"items":344,"meta":390},[345,356,374],{"id":45,"slug":46,"title":47,"subtitle":48,"excerpt":49,"coverUrl":50,"locale":13,"readingMinutes":51,"publishedAt":52,"viewCount":346,"likeCount":19,"commentCount":19,"author":347,"vertical":348,"topic":349,"tags":350,"_count":355,"playground":48,"hasQuiz":18,"hasPlayground":18},28,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":34,"name":35,"accentFrom":38,"accentTo":39},{"slug":61,"name":62},[351,352,353,354],{"slug":65,"name":66,"color":48},{"slug":68,"name":69,"color":48},{"slug":71,"name":72,"color":48},{"slug":74,"name":75,"color":48},{"assessments":19},{"id":357,"slug":286,"title":287,"subtitle":48,"excerpt":358,"coverUrl":359,"locale":13,"readingMinutes":289,"publishedAt":288,"viewCount":360,"likeCount":19,"commentCount":19,"author":361,"vertical":362,"topic":363,"tags":366,"_count":373,"playground":48,"hasQuiz":18,"hasPlayground":18},"01a05274-fd83-71ed-9890-3cc8c1004104","The reason you don't speak up isn't confidence. Everyone else is thinking out loud while you wait for your thought to be finished — and a good point at minute thirty is worth less than a rough one at minute twelve. Here's how to land it on time.","\u002Fmedia\u002Fcovers\u002Fspeaking-up-in-meetings.png",173,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":34,"name":35,"accentFrom":38,"accentTo":39},{"slug":364,"name":365},"meetings","Meetings and rooms",[367,368,369,372],{"slug":65,"name":66,"color":48},{"slug":74,"name":75,"color":48},{"slug":370,"name":371,"color":48},"productivity","Productivity",{"slug":71,"name":72,"color":48},{"assessments":19},{"id":375,"slug":281,"title":282,"subtitle":48,"excerpt":376,"coverUrl":377,"locale":13,"readingMinutes":284,"publishedAt":283,"viewCount":378,"likeCount":19,"commentCount":19,"author":379,"vertical":380,"topic":381,"tags":384,"_count":389,"playground":48,"hasQuiz":18,"hasPlayground":18},"01a037b3-d788-7645-99a4-a90f94ed0e61","In your first week you get to ask anything and it costs nothing. That window shuts quietly, usually around week three, and nobody announces it. Here's how to use it before it goes.","\u002Fmedia\u002Fcovers\u002Ffirst-week-at-a-new-job.png",450,{"id":55,"name":56,"username":57,"avatarUrl":48,"headline":58},{"slug":34,"name":35,"accentFrom":38,"accentTo":39},{"slug":382,"name":383},"starting","Starting somewhere new",[385,386,387,388],{"slug":65,"name":66,"color":48},{"slug":71,"name":72,"color":48},{"slug":370,"name":371,"color":48},{"slug":74,"name":75,"color":48},{"assessments":19},{"page":272,"perPage":284,"total":43,"totalPages":272},{"locked":18,"total":19,"comments":392},[]]