<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>ar_lan</author><text>Everything you listed are exactly what the &amp;quot;know-it-all&amp;quot; senior developer is expecting already, though. If you&amp;#x27;re doing these things before you submit your review for eyes to look at, you&amp;#x27;ll come to a point where your reviews should only go through 0-2 revisions before submission is ready.&lt;p&gt;Personally, if I see a review that is &amp;gt;10 files that isn&amp;#x27;t explicitly a &amp;quot;Refactor&amp;quot; review, or I&amp;#x27;ve been prepped ahead of time, it&amp;#x27;s probably going to take a &lt;i&gt;long&lt;/i&gt; time to get the review out, because there are so many things to iterate on. I also have to block out a lot of time to even do the singular review, because it is so long and there is so much cognitive load to carry with it.&lt;p&gt;Smaller reviews are almost always better. If a review really can&amp;#x27;t be &amp;quot;completed&amp;quot; in a single PR, then I&amp;#x27;ve also suggested 1&amp;#x2F;x reviews where bones are placed but gated under an FSS or something similar. This prevents code that shouldn&amp;#x27;t be run from being run until the whole feature (even if small) is complete, and lets the reviews focus on independent parts.&lt;p&gt;--&lt;p&gt;Essentially, I&amp;#x27;m saying I disagree with you placing the &amp;quot;error&amp;quot; on the senior developers in this scenario. Burdening someone with insanely large reviews is the err of the submitter.</text><parent_chain><item><author>schwartzworld</author><text>Code review is a flawed process, especially for junior engineers. You spend time and effort, maybe days of work, getting this to work, and then some know-it-all leaves a bunch of nit-picky comments or tells you you&amp;#x27;re doing it wrong.&lt;p&gt;I tell most of the juniors I work with to work defensively against this using a few strategies:&lt;p&gt;- smaller PRs. Break the work up any way you can. Make small tickets or submit your PRs with Part 1, part 2, etc. You can&amp;#x27;t release half-baked work, but you can usually find opportunities to split things up. Nobody should be submitting 20 file PRs and not expecting a lot of comments.&lt;p&gt;- Validate your strategy before building it. If there&amp;#x27;s a senior engineer in your team who nitpicks your code, get their buy-in before writing it.&lt;p&gt;- often bad code is the result of not really knowing how to approach a problem. Don&amp;#x27;t just write the code and slap together a PR. You might need to figure out a working solution, then go back and tweak it and refactor it before submitting it.&lt;p&gt;- review your own PRs and use a critical eye. You&amp;#x27;ll catch the low hanging fruit (like forgetting console.log calls). Every time you have the urge to leave a comment justifying a choice, question whether it&amp;#x27;s the right choice at all.</text></item></parent_chain></comment><story><title>How to run a miserable code review</title><url>https://badsoftwareadvice.substack.com/p/how-to-run-a-miserable-code-review</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>verall</author><text>&amp;gt; smaller PRs&lt;p&gt;I think the opposite works better - submit thousands of lines of changes, you will get like 10 comments, address all of them, and then you&amp;#x27;re gold. The reviewer has no time to slog through thousands of lines of changes unless the code you&amp;#x27;re touching is their baby.</text><parent_chain><item><author>schwartzworld</author><text>Code review is a flawed process, especially for junior engineers. You spend time and effort, maybe days of work, getting this to work, and then some know-it-all leaves a bunch of nit-picky comments or tells you you&amp;#x27;re doing it wrong.&lt;p&gt;I tell most of the juniors I work with to work defensively against this using a few strategies:&lt;p&gt;- smaller PRs. Break the work up any way you can. Make small tickets or submit your PRs with Part 1, part 2, etc. You can&amp;#x27;t release half-baked work, but you can usually find opportunities to split things up. Nobody should be submitting 20 file PRs and not expecting a lot of comments.&lt;p&gt;- Validate your strategy before building it. If there&amp;#x27;s a senior engineer in your team who nitpicks your code, get their buy-in before writing it.&lt;p&gt;- often bad code is the result of not really knowing how to approach a problem. Don&amp;#x27;t just write the code and slap together a PR. You might need to figure out a working solution, then go back and tweak it and refactor it before submitting it.&lt;p&gt;- review your own PRs and use a critical eye. You&amp;#x27;ll catch the low hanging fruit (like forgetting console.log calls). Every time you have the urge to leave a comment justifying a choice, question whether it&amp;#x27;s the right choice at all.</text></item></parent_chain></comment><story><title>How to run a miserable code review</title><url>https://badsoftwareadvice.substack.com/p/how-to-run-a-miserable-code-review</url></story>