A bogus study on code review
I&#x27;ve read this and similar posts on this study a dozen times in the last few weeks. I think the data is poorly interpreted and what you&#x27;re really seeing is that shorter pull requests elicit better feedback (in this case &quot;more defects per line&quot;).<p>In my experience running code reviews, shorter pull requests, presumably due to their reduced effort necessary to understand, tend to get better review, review that is more than just superficial style&#x2F;linting errors.<p>In light of that, I always encourage developers to aim for the shortest reasonable changeset - and make it very clear to them that 2 line PRs are totally acceptable - on my current team, we go as far as to encourage tricks like rewriting (local) Git history and cherrypicking to ensure that is the case. Continuous integration and good unit tests help to ensure that strange states generated from that process are still good and I find the costs are far outweighed by the better reviews.<p>Another little lesson I&#x27;ve learned managing that process is to encourage the submitting developer to highlight problem areas in his own code: when I submit my own code for review, I&#x27;ll actually do the review first, line-level highlighting areas I wish the reviewer to pay attention to. This will only work if you can trust your developers to not try to &quot;sneak something by,&quot; but if you can&#x27;t do that, you&#x27;ve probably already lost. Developers generally know what they weren&#x27;t sure about during the process, where things are going to be difficult to understand and where someone else on the team is going to have helpful contributions to the quality.<p>I think it is important for developer-managers to remember that programming is largely a craft and developers largely want to be proud of their output. People _like_ producing &quot;good code&quot; and it is easy to align the goals by having the process help improve their craft.