Pull requests (PRs) can slow down development by creating unnecessary bottlenecks, and I believe developers can work without them. Actually, I believe developers should work without them in a closed-source environment. Let’s explore why PRs may be holding your team back, what to do instead and ways to improve the process if you must keep them.
GitHub pull requests allow developers with access to the code to review open pull requests and approve or reject code merges depending on whether they meet certain requirements. If you have an open-sourced project, PRs are a must from outside developers. The main reason is to avoid introducing security vulnerabilities from developers with malicious intent.
The PR workflow is not well-suited for closed-sourced corporate environments, and it can lead to two major issues: frequent context switching during code reviews and delays in the CI/CD pipeline validation processes. These frequent interruptions significantly reduce productivity and flow. This makes it harder for your developers to maintain focus and complete their main development tasks efficiently.
To minimize these problems, you can assign dedicated code reviewers to review the pull requests on specific days. These individuals should focus solely on PRs without other responsibilities (e.g., development or meetings) blocking their ability to do code approvals.
How a company handles this depends on its size, resources, and organizational structure. So, there is a lot of variation that can happen here.
Here are two scenarios that come to mind:
Even with a strategy like dedicated code reviewers, context switching remains a challenge. Reviewers must mentally transition between different code sections and tasks during their dedicated review days. And developers face interruptions when they need to address review feedback or implement the requested changes.
This back-and-forth can disrupt the flow for the entire team. To further minimize the impact of context switching and interruptions, you can do PRs in certain scenarios.
For instance, you can only require a pull request from junior developers and newly onboarded senior developers. This will reduce unnecessary reviews that can slow down experienced developers on the team. At the same time, you can ensure code quality is maintained.
Additionally, you can make PRs optional for everyone else who needs feedback. That way, if a developer is not confident in their code, they can seek help from their peers.
A radical but better approach is to skip PRs entirely. This not only reduces context switching significantly but also brings other benefits: it improves collaboration by letting developers focus on what truly matters, and it increases developer autonomy by allowing them to merge code directly without delays.
Instead of PRs, you can do code discussions instead. While junior developers require regular meetings, mid-level developers will need them occasionally. Senior developers with proven track records can work independently since they understand the importance of code quality and won’t take shortcuts.
Success depends on developers being comfortable handling small tasks independently and adhering to The Boy Scout rule of coding—“Always leave the codebase cleaner than you found it.”
This system works best when combined with test-driven development (TDD) to ensure the code meets requirements while not introducing new bugs. Also, strong CI/CD pipelines and checklists should be enacted. These act as safeguards to ensure developers write quality code without too much manual oversight.
Keep in mind that if anything changes during the code discussion (e.g., coding processes or style guidelines), the documentation should be updated immediately. Anyone who needs to be updated should be informed of the changes via the appropriate communication channel, such as email, Slack, or Microsoft Teams.
Balancing the speed of skipping pull requests while ensuring robust testing, clear communication, and trust is key to making a workflow without PRs successful. Your team wants to ship products faster and work more autonomously. Ditching this unnecessary bottleneck and opting for code discussions can translate to quicker releases, happier engineers, and beating competitors to the market with a better product.