Code Review Can Be Better
TigerBeetle's experiment with git-review: storing code review state in the repository itself and using local tools instead of web interfaces, exploring how we might reimagine development processes beyond current tooling constraints.
tl;dr
TigerBeetle experimented with git-review, a tool that stores review state in the repository and allows reviewing code locally in your editor rather than through web interfaces. While the basic idea worked well, practical issues with merge conflicts and git workflow friction led them to shelve it. The experiment highlights how current code review processes might be reimagined.
My Thoughts
It’s interesting how we got stuck on tooling and process (such as GitHub PR review). git-review is just a different way of facing the same problem, but it reveals something deeper: we’re not questioning the fundamentals enough.
What other processes should we reimagine with AI (sorry, I needed to bring some AI in the mix)? I think even commit history needs to be reviewed on a “feature wise” basis instead of change-based commits. The way we structure our development workflow is built on decades-old assumptions that might not serve us anymore.
I’ve never been proficient on git practices nor on high-efficiency tooling, and I think there’s value in that. I believe some parts of the process are ok to be slow to give some space for thinking. Not everything needs to be optimized for speed.
But making tooling around solving actual issues instead of technology wrapping solutions is my way to go. The difference matters: are we building tools to solve real problems, or are we just wrapping existing technology in new interfaces? And this is a broader topic, but if we are already missing this in the tooling, what aren’t we missing in the things we build with it?
This is my personal commentary on the original article. Please read the original article for the full context.