The Lazy Coder Series: Why Modern Code Review Tools Still Suck 🤬

The short answer is that there is no good reason. Someone should build an opinionated, streamlined and remote-work first code review tool that’s better than GitHub’s native code review and doesn’t require two weeks worth of integration time like Phabricator.

Let’s explore what really sucks about modern code reviews, why it’s in this state and what can we do about it 🙏.

What sucks about modern code review…

A good software engineer breaks down features into smaller commits which are easier to review, easier to understand and easier to trace once it‘s merged in.

Let’s say we are building an invites feature: we could split this by (1) adding an invite button, (2) presenting a share sheet and (3) adding analytics for logging.

In GitHub, we would create new branch invites_feature , push the new branch to remote, create a pull request with updates, etc. and sit and wait for our reviewer to come and read through the code.

The problem starts unfolding here; GitHub’s default code review is through the “Files” tab which shows all the edits, all at once. This creates a review process that quickly turns into 500 line reviews 🤦‍♂️ meaning more bugs and more wasted ⏰ & 💰

The more lines of code an engineer has to review at once, the fewer defects will be found. This is not very surprising to any engineer who has reviewed code .Read more about the findings in the largest code review study.