How to run a miserable code review
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&#x27;re doing it wrong.<p>I tell most of the juniors I work with to work defensively against this using a few strategies:<p>- 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&#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.<p>- Validate your strategy before building it. If there&#x27;s a senior engineer in your team who nitpicks your code, get their buy-in before writing it.<p>- often bad code is the result of not really knowing how to approach a problem. Don&#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.<p>- review your own PRs and use a critical eye. You&#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&#x27;s the right choice at all.