As I delve into unconventional approaches to software development, I think it's worthwhile to share my thoughts on pull requests. While they are undoubtedly helpful, having another developer review your code after you've completed it, I find the traditional approach to pull requests to be somewhat cumbersome and potentially demotivating.

Throughout my years of experience, I've worked with numerous teams, each with a distinct company culture surrounding pull requests. Time and again, I've observed common issues such as developers not responding to pull requests promptly, leaving the original author unable to commit code. I've seen pull requests stall due to nitpicky issues, and I've noticed developers rubber-stamping pull requests without thoroughly reviewing them simply to avoid the hassle.

From my experience, less than 5% of my pull requests have revealed fundamental bugs or issues in my code. Most often, these issues are discovered during the QA phase or once the code is released to production. This suggests that there may be a significant amount of overhead for relatively little impact.

Rarely do I see developers downloading and running the code during a review. They tend to skim through the changes on GitHub, which often results in important details being overlooked and ultimately renders the code review ineffective.

I believe pull requests are far more useful and effective when the required reviews are at the developer's discretion. For instance, if you're a new developer on the team, frequent pull requests can help your team review your work and guide you through any knowledge gaps in the codebase. Additionally, if you've built a complex section of code and would like a confidence boost, requesting a code review can be beneficial.

However, many commits to a codebase are routine and straightforward. Having to wait for a coworker to review your code when making minor changes, such as updating text or colors, can be demotivating and hinder overall progress. I appreciate environments that encourage discussions about whether code requires a peer review or not.

While shipping broken code is never ideal, and thorough reviews can help prevent it. I believe that a robust QA workflow is more crucial than strict code reviews. I've seen numerous development shops undermine the QA process, assuming that the pull request and code review process is sufficient.

For large companies with abundant resources and a massive customer base, skimping on quality control may not be an option. However, the reality is that most software development projects can afford to move quickly and occasionally break things.

Although many people may disagree with my relaxed approach to code reviews, we may be entering an era where this becomes a moot point. With the rise of sophisticated AI models, such as ChatGPT, it's highly likely that someone is working on software to automate code reviews. An AI-driven model could potentially perform code reviews more efficiently and effectively than any human, addressing the current issues caused by traditional human-led code reviews.

Until AI bots resolve these problems, I will continue advocating for a code review process that is less stringent, more at the discretion of the software developer, and strikes a balance between impact and efficiency.