Why Small PRs Aren’t Always the Best Solution: Lessons from Startup Development

We often hear experts say, "Compose small PRs! The smaller the PRs, the easier they are to understand." But that's not always right! 🤔

I used to believe that small PRs were the cleanest and best way to develop.

But in recent times, I've realized this approach doesn't always work.

This might be effective for companies moving at a slower pace.

However, for startups pushing out at least one release a week, this can slow things down significantly. 🐢

In most startups, developers own large chunks of features.

Splitting these into smaller tasks and raising separate PRs not only wastes time but also makes reviewers lose context about the feature as a whole. 😵‍💫

But then, reviewing a PR with 100+ file changes is no walk in the park either. So, what's the solution?

Here's what works for me:

Provide a clear description of the changes.

You don't need to be overly detailed, but a high-level summary of the changes goes a long way.

Avoid unnecessary changes

Skip alignment changes or edits unrelated to the feature you're working on.

Annotate unrelated changes

If some unrelated changes are unavoidable, add comments explaining why they're included. This helps reviewers stay on track.

Streamline priority reviews.

Let's be real---no one jumps to review a massive PR immediately. If it's a priority, set up a quick call with the reviewers to explain the changes. It makes the review process faster and more efficient.

Respect the reviewer's time

Ask your reviewers when they can reasonably review the PR and follow up after the deadline. Respecting their time is key.

Follow up without annoying

Reviewers have their own priorities, and forgetting your PR is natural. Gently remind them without being pushy to get it reviewed.

---

This is how I approach or request PR reviews at my workplace.

How do you handle your PR reviews? Let me know in the comments! 💬

And don't forget to follow Navayuvan Subramanian for more tech insights! 🚀