Over-the-Shoulder Review

What Is an Over-the-Shoulder Review?

An over-the-shoulder review is the most lightweight form of code review practiced in software development. The code author invites a colleague to look at their changes by physically sitting next to them, joining a video call, or sharing their screen. The author walks the reviewer through the diff, explaining the reasoning behind each change while the reviewer asks questions and points out potential issues in real time.

Unlike tool-assisted reviews that happen asynchronously through pull requests and code review platforms, over-the-shoulder reviews are synchronous and conversational. There is no formal checklist, no recorded comment thread, and typically no written record of the feedback exchanged. The reviewer relies on the author’s narration to understand the context, and feedback is given verbally rather than as inline annotations on a diff.

This approach has deep roots in software engineering. Before platforms like GitHub and GitLab made pull-request-based reviews the default workflow, over-the-shoulder reviews were one of the most common ways teams caught bugs before code reached production. Even today, many teams use them as a complement to asynchronous reviews when a change is particularly complex or time-sensitive.

How It Works

The typical over-the-shoulder review follows a simple sequence. The author finishes a set of changes and asks a nearby teammate, “Can you take a look at this?” The reviewer pulls up a chair or joins a screen share, and the author walks through the modified files one by one. The conversation might sound like this:

“I refactored the authentication middleware to use a strategy pattern. Here is the base interface, and here are the two concrete implementations for OAuth and API key auth. The routing layer picks the right strategy based on the request header.”

The reviewer watches the code scroll by, asks clarifying questions (“What happens if the header is missing?”), and flags anything that looks off (“This catch block swallows the error silently — should we log it?”). Once both parties are satisfied, the author proceeds to merge or submit the code.

Some teams add a small amount of structure by requiring the reviewer to verbally confirm approval before the code is merged. Others keep it entirely ad hoc, treating it as a quick sanity check rather than a gate in the development process.

In remote and hybrid teams, over-the-shoulder reviews typically happen over video conferencing tools like Zoom or Google Meet, with the author sharing their IDE or terminal. This works reasonably well but loses some of the spontaneity of tapping a colleague on the shoulder in a shared office.

Why It Matters

Over-the-shoulder reviews deliver value in scenarios where speed matters more than traceability. When a critical hotfix needs to go out in the next thirty minutes, waiting for an asynchronous pull request review cycle is impractical. A quick over-the-shoulder check with a senior engineer can provide enough confidence to ship the fix safely.

This review style also excels as a knowledge-sharing mechanism. Junior developers benefit enormously from watching a senior engineer react to their code in real time, observing not just what the reviewer catches but how they think about code quality, edge cases, and design tradeoffs. The immediate, interactive nature of the conversation makes it one of the most effective mentoring tools available to engineering teams.

However, the lack of documentation is a significant drawback. When a bug surfaces months later and the team tries to understand why a particular design decision was made, there is no comment thread to reference. The knowledge exchanged during an over-the-shoulder review lives only in the memories of the two participants.

Best Practices

• Time-box the session. Set a clear expectation that the review will take fifteen to thirty minutes. Without a time limit, over-the-shoulder reviews can turn into extended design discussions that derail both participants’ schedules.

• Let the reviewer drive. Instead of having the author narrate every line, hand the reviewer control of the screen and let them explore the diff at their own pace. This catches issues the author might unconsciously skip over.

• Take brief notes. Even though the review is informal, jot down action items in a shared document or issue tracker. This creates a minimal paper trail and ensures nothing slips through the cracks.

• Use it as a complement, not a replacement. Over-the-shoulder reviews work best when paired with asynchronous tool-based reviews. Use the synchronous session to discuss high-level design, then follow up with a pull request for line-level scrutiny.

• Rotate reviewers. Avoid defaulting to the same reviewer every time. Rotating reviewers spreads knowledge across the team and prevents bottlenecks.

Common Mistakes

• Skipping the review for “simple” changes. Teams that rely solely on over-the-shoulder reviews often start skipping them for changes they consider trivial. These “trivial” changes are frequently where typos, off-by-one errors, and missing edge-case handling hide. Without a formal gate in the workflow, it becomes too easy to bypass the review entirely.

• Author-dominated walkthroughs. When the author controls the pace and narration, they tend to gloss over the parts of the code they are least confident about. This defeats the purpose of the review. Effective over-the-shoulder reviews require the reviewer to actively interrogate the code, not passively listen to a guided tour.

• No follow-up on feedback. Because feedback is delivered verbally, it is easy for suggestions to be forgotten or deprioritized once the session ends. Without written records, there is no mechanism to verify that identified issues were actually addressed before the code was merged.