Why I Don't Like The Pull-Requests + Review Combination.

What alternative I prefer

In the last months, I discussed the common challenges of dealing with complex systems and workflows, which can eventually overwhelm companies. One point that sparked considerable conversation was the suggestion to rethink pull requests and code reviews as potential bottlenecks.

This topic struck a chord with many, as evidenced by the feedback I received through various channels—Slack groups, LinkedIn, and conference discussions.

This issue runs deep in nearly every software company, touching a nerve for teams grappling with scale or modernization.

Today, I want to tie up these thoughts and address the insights gathered over the past few months.

The Feedback: "My Team Isn't Ready for This"

One typical response was, “My team isn't ready to work this way.” Is this true? In The War of Art, Steven Pressfield describes resistance as a natural human mechanism that blocks progress.

This resistance often manifests as insecurity or fear, making people reluctant to adopt a more trust-based environment that fosters growth. Yet, teams often see their processes improve organically if a culture is nurtured where learning and trust thrive.

Feedback: The Sacred Pull Request and Code Review

Many see the idea of eliminating mandatory code reviews as a significant risk, fearing it would undermine communication. They believe that PRs and code reviews are cornerstones of collaborative development.

However, my goal isn't to remove communication but to integrate it more seamlessly into the development process itself. Code reviews that happen days or weeks later often become disconnected from the original context, losing their value. In such cases, they are no longer about collaboration but an afterthought. As time passes, the relevance of these reviews fades.

We enhance communication and knowledge-sharing by encouraging developers, operations, and QA to communicate throughout development. This collaborative environment naturally fosters growth, where team members are more likely to help one another and maintain the momentum of progress. Regular, all-hands review meetings could then serve as retrospectives—where the team reflects on the work completed that week rather than isolating feedback in 1:1 sessions.

This approach is like running a continuous Hackathon, where desks are pushed together, and everyone tackles issues head-on as a team. 🚀

Feedback: Small Tasks Mean Losing Sight of the Big Picture

Some worry that breaking work into small, manageable tasks will cause developers to lose sight of the broader project. While this is a valid concern, it’s only accurate if developers work in isolation. When the team collectively tackles tasks, the opposite happens—everyone has a stake in understanding the bigger picture.

Of course, this requires careful task planning, which usually falls on senior developers. This is often why organizations maintain strict code review processes; they see it as a way to manage risk and build trust, especially when the team is a mix of junior and senior talent.

The key is to balance this risk without stifling the development flow.

Feedback: Hidden Bugs in Production

One concern is that bugs and bad code will slip into production unnoticed without mandatory reviews. This is inevitable to some degree—issues will always occur. But the real question is how quickly your team can identify and address them.

A delayed code review doesn't guarantee bug-free releases. Instead, a fast-paced, agile development cycle combined with a robust CI/CD pipeline and a team that takes ownership of the entire process can be more effective.

By keeping tasks small and focused, developers can better evaluate the scope of their changes and ensure their work meets the acceptance criteria. Writing tests during development further reduces the chance of issues. In this workflow, problems can be spotted and resolved quickly, often before they impact customers.

Trunk-based development and staging environments provide another layer of protection, giving teams time to catch any issues before they go live. Over time, as the team matures in this process, staging may no longer be necessary.

Why I Challenge the Traditional PR and Code Review

I firmly believe that a workflow built on collaboration and trust is far superior to one bound by rigid constraints.

When I advocate for eliminating code reviews as a mandatory step, it’s not about removing accountability—it's about pushing that accountability into the present, during the actual development. Pair programming and real-time collaboration encourage growth and improve skills while nurturing a stronger team culture. The restrictive nature of PRs often hinders the completion of work, creating unnecessary barriers.

Senior developers who bring experience and wisdom to the table should not wait until later to offer feedback. They should be available to support and guide their peers in real time.

Building a Strong Team Culture

The core of this strategy revolves around fostering a culture of communication, learning, and collaboration.

The team thrives when there's no divide between team members and questions are welcomed openly. Tasks become team efforts, with the assignee leading the charge but relying on collective input. Keeping tasks small and encouraging constant collaboration makes code reviews an on-demand resource rather than a mandatory hurdle.

This approach creates a steady workflow, one of the core principles of the DevOps mindset.

Keep the Team Together

Whether your team embraces pull requests and code reviews, it is essential to keep them working together. Collaboration should always remain at the heart of the process, regardless of your chosen tools or methods.

This applies to both on-site and remote teams. Even in different time zones, fostering a sense of community and ensuring everyone works toward a common goal is possible.

Developers working alone or in silos often do so for various reasons—whether it's a personal preference for uninterrupted work, other team commitments, or fear of exposing skill gaps. These challenges need to be addressed. These barriers can be broken down by integrating everyone into the team’s daily rhythm.

Final Thoughts

Tony Robbins once said, "Progress equals happiness." Whether or not you agree with the approaches I’ve outlined, remember that complexity is the enemy. It distracts us from our true purpose—solving problems and delivering value.

By simplifying workflows, fostering open communication, and trusting in your team’s ability to collaborate, you'll find that the development process becomes smoother and more effective.

Stay focused, stay collaborative, and have a fantastic day!

Adrian