Building a High-Trust Engineering Culture: No Code Reviews by Default

The core of Raycast's engineering culture is built on trust, enabling remarkably fast development without mandatory code reviews. Engineers are empowered to push directly to the main branch, requesting reviews only when deemed necessary. This post details the principles and practices behind this unique, high-velocity approach.

The Genesis of Our Approach

In the early days of Raycast, co-founders Petr and [Author] worked side-by-side, rapidly iterating on features. This initial phase was characterized by intense collaboration and implicit trust, bypassing formal code reviews. Technical questions were resolved instantly and in person, with changes committed directly to the main branch.

As the team expanded and transitioned to a distributed model, the question of adopting traditional code reviews arose. While conventional wisdom often touts pull requests as a best practice for high-performing teams, we valued the inherent trust, collaborative spirit, and speed of our existing "no-review" process. Consequently, we made a deliberate decision not to mandate code reviews. Instead, every engineer retains the autonomy to push changes directly to the main branch. Reviews are optional, initiated by the engineer if they desire an additional perspective, sometimes even after the code has been integrated into the trunk.

Responsibility Over Convention

While GitHub, our chosen source control platform, inherently supports pull requests (PRs) for code review, we found the conventional PR model impractical for our team, despite its suitability for open-source contributions. Our rationale stems from several observations:

• Discouragement of Trust: Requiring approval for every code change can undermine a culture built on high trust. We believe in fostering more efficient and trust-based methods of collaboration.
• Ineffectiveness in Bug Prevention: Code review is inherently challenging. While obvious errors might be caught, consistent in-depth scrutiny is difficult to maintain. Many critical issues only surface during extensive use, a scenario not replicated during a typical code review. Our strategy prioritizes rapid iterations and real-world user feedback for bug detection.
• Development Slowdown: Code reviews often become a lower priority for engineers, leading to accumulating review queues and delays. They can become an afterthought, detracting from core development work.

At Raycast, we champion full responsibility, with engineers owning features from initial concept to ongoing maintenance. Our engineering culture empowers this by granting them the freedom to push directly to the main branch, reserving code review requests for situations where they genuinely perceive a need.

Practical Implementation

Our methodology centers around rapid dogfooding of changes. By working directly on the main branch, we maintain a continuous flow of updates that are immediately available for internal testing. Our continuous integration system builds and tests every commit. Furthermore, an internal release is triggered nightly, incorporating all daily commits and automatically deploying to the entire team. This ensures new changes are tested within 24 hours.

These daily internal releases facilitate extensive feedback collection, crucial for identifying and resolving bugs or usability issues. Features deemed production-ready by the team are included in the next public release. If further refinement is required, we use feature flags to keep them internal. This streamlined workflow allows us to consistently ship updates bi-weekly.

Side note: We utilize git rebase instead of git merge to maintain a clean project history, free from unnecessary merge commits.

While not mandatory, specific scenarios prompt us to request code reviews. For instance, when modifying unfamiliar or critical parts of the codebase, such as implementing a database migration for the first time, a pull request is opened for thorough double-checking to safeguard the production environment. New team members often initiate code reviews during their initial weeks to acclimate themselves to our codebase, gradually gaining confidence to directly commit larger changes.

Beyond formal PRs, "post-commit messages" serve as an effective communication tool. After committing a change, engineers might tag relevant colleagues in a dedicated Slack channel or directly on the GitHub commit to draw attention to changes that could impact others. This approach is particularly useful for overcoming time zone differences that might delay traditional reviews. For more complex problems requiring multi-engineer input, we leverage quick video calls with screen sharing, ideal for collaborating on significant refactoring efforts or aligning on interdependent features.

This approach has proven more effective for us, circumventing the isolation of long-lived branches and building momentum through continuous application updates.

Forge Your Own Path

Every organization and team is unique, yet all share the common ambition of developing superior products efficiently. The path to achieving this varies. Our approach at Raycast is founded on deep trust in our engineering team, empowering them to decide when external code reviews are beneficial. While this model may not suit teams with stringent security or compliance needs, it has been highly effective for us. It facilitates rapid feature iteration, attracts top engineering talent eager to solve complex challenges, and fosters an asynchronous communication culture perfectly suited for our fully distributed team.

Ultimately, the responsibility for defining your team's operational rules lies with you and your colleagues. Avoid dogmatically adopting "best practices." Instead, critically assess whether others' circumstances truly align with your own, as it's likely you'll discover a more appropriate and effective approach tailored to your specific context.