PRs: The worst possible way to review code (1/7)
We used to talk when reviewing code. Now we throw a pointer to a diff over a wall, and trust that others care enough to do a good review. (Or cynically, hope they don't care enough to find things we must fix.)
// @tottinge
We used to talk when reviewing code. Now we throw a pointer to a diff over a wall, and trust that others care enough to do a good review. (Or cynically, hope they don't care enough to find things we must fix.)
// @tottinge
@tottinge PRs: The worst possible way to review code (2/7)
No one really wants to spend time on PRs, and as such most of us minimize such efforts. We find surface-level problems and move on. The resulting rubber-stamp process creates false confidence and pointless delay.
No one really wants to spend time on PRs, and as such most of us minimize such efforts. We find surface-level problems and move on. The resulting rubber-stamp process creates false confidence and pointless delay.
@tottinge PRs: The worst possible way to review code (3/7)
Even when people put their heart into PRs, they can miss deeper, significant problems--partly because they missed the deep conversations & decisions that got distilled into decisions in the code.
Even when people put their heart into PRs, they can miss deeper, significant problems--partly because they missed the deep conversations & decisions that got distilled into decisions in the code.
@tottinge PRs: The worst possible way to review code (4/7)
Even smaller problems can be hard to spot. Anyone who's ever done JavaScript knows, for example, that it's possible to write a couple lines of code that look great but don't do anything near what you'd think.
Even smaller problems can be hard to spot. Anyone who's ever done JavaScript knows, for example, that it's possible to write a couple lines of code that look great but don't do anything near what you'd think.
@tottinge PRs: The worst possible way to review code (5/7)
Even when we find significant problems, it’s often too late and too expensive to fix them. A cycle of code / review / rewrite / re-review isn’t effective. Nor is code / review / release-bad-code.
Even when we find significant problems, it’s often too late and too expensive to fix them. A cycle of code / review / rewrite / re-review isn’t effective. Nor is code / review / release-bad-code.
@tottinge PRs: The worst possible way to review code (6/7)
As easy as it for folks to get offended in person when someone is critiquing their code, it's often easier for many to take things the wrong way when reading comments on a github page.
As easy as it for folks to get offended in person when someone is critiquing their code, it's often easier for many to take things the wrong way when reading comments on a github page.
@tottinge PRs: The worst possible way to review code (7/7)
Far more effective: Come to consensus before we get too deep in a bad design, and talk things through as we build the code.
Far more effective: Come to consensus before we get too deep in a bad design, and talk things through as we build the code.
@tottinge I just wonder often how we got to something so bad. PRs are 100% not valuing "individuals and interactions over processes and tools."
well... 8/7. Should've had someone review this stream.
well... 8/7. Should've had someone review this stream.
the implicit summary if you're reading this far: Do something better than PRs that involves actual discussions.
Fagan inspections, pair programming, mob programming, ...
Fagan inspections, pair programming, mob programming, ...
• • •
Missing some Tweet in this thread? You can try to
force a refresh
