Code Review
What review is actually for once tooling handles formatting, what a useful checklist asks, and why review size predicts defect detection better than reviewer skill.
Correctness, design, maintainability, security and knowledge sharing — five things a person can do. Formatting is not one of them, because a tool already did it.
Six questions, in the order attention runs out: behaviour against requirement, invariants moved, failure modes added, simpler alternative, meaningful tests, and whether you could debug it at three in the morning.
The same reviewer finds real problems in a sixty-line change and waves through a nine-hundred-line one. Diff size predicts what review catches better than almost anything else about the reviewer.
Critique the code and what it will cost, never the person. Then the two harder halves: disagreeing with someone senior, and taking twenty comments on work you were proud of.
Formatters, linters, type checkers, tests and static analysis exist so that human attention is spent only on what is arguable. Every mechanical comment a person still makes is a missing rule.
By the time a change reaches review the boundary already exists. That is why "this belongs somewhere else" is the comment most often agreed with and least often acted on.