✳flâneur — a map of the web's best reading

Mistakes I see engineers making in their code reviews

seangoedecke.com · 2,341 words · saved by 1 readers

In the last two years, code review has gotten much more important. Code is now easy to generate using LLMs, but it’s still just as hard to review1. Many software engineers now spend as much (or more) time reviewing the output of their own AI tools than their colleagues’ code. I think a lot of engineers don’t do code review correctly. Of course, there are lots of different ways to do code review, so this is largely a statement of my engineering taste. The biggest mistake I see is doing a review that focuses solely on the diff2. Most of the highest-impact code review comments have very little to do with the diff at all, but instead come from your understanding of the rest of the system. For instance, one of the most straightforwardly useful comments is “you don’t have to add this method here, since it already exists in this other place”. The diff itself won’t help you produce a comment like this. You have to already be familiar with other parts of the codebase that the diff author doesn’

In the last two years, code review has gotten much more important. Code is now easy to generate using LLMs, but it’s still just as hard to review 1 . Many software engineers now spend as much (or more) time reviewing the output of their own AI tools than their colleagues’ code. I think a lot of engineers don’t do code review correctly. Of course, there are lots of different ways to do code review, so this is largely a statement of my engineering taste . Don’t just review the diff The biggest mistake I see is doing a review that focuses solely on the diff 2 . Most of the highest-impact code rev

Explore this link on the map →

saved by

related reading