Work Without Pull Requests

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.

If You Require PRs, Do Them Right

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-source 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-source 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 (for example, 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:

• Rotate reviewers on different days: For instance, if a company has about 50 developers, it can assign five of them to code approvals. In this scenario, one would work on Monday, another on Tuesday, and so on.
• Cycle reviewers based on time zones: This is a rare scenario that is only possible for large companies with huge code bases and enough people to do code reviews across multiple time zones. When one code reviewer is done in one time zone, another takes over in a different one. This ensures that there is always someone reviewing the code.

Specific Scenarios to Do PRs

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 only certain scenarios.

For instance, you can only require a pull request from junior developers and newly onboarded senior developers. This reduces unnecessary reviews that 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.

Middle Ground: Skip Pull Requests Entirely

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 need them occasionally. Senior developers with proven track records can work independently, since they understand the importance of code quality and will not 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. Strong CI/CD pipelines and checklists should also 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 (for example, coding processes or style guidelines), the documentation should be updated immediately. Anyone who needs to be aware should be informed via the appropriate 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.

Designing a process this loose only works if the people on the team can carry it, so see the companion post How to Build 10x Developers for the talent side of the equation. The engineering-process redesign is itself a typical fractional CTO engagement, and a code review is often the diagnostic that surfaces whether your current PR friction is actually about the process or about the codebase underneath it.