Code review is where your velocity goes to die

The average pull request sits in purgatory for 22 hours before someone even looks at it. Most of that time isn't spent thinking. It's spent waiting for a context switch that never comes.

We’ve convinced ourselves that a three-day turnaround for a 50-line change is 'normal' because we’re busy. We aren't busy. We're just bad at managing the flow of information.

At git11, we spend our time looking at how thousands of teams handle their repos. The data shows that code review is the single biggest bottleneck in the SDLC. It’s not your build times. It’s not your test suite. It’s the human in the loop.

The fallacy of the 'LGTM' queue

Most teams treat the PR queue as a stack. It’s actually a graveyard. When a developer hits 'Submit,' they immediately pivot to a new task.

By the time you leave a comment on auth_service.go four hours later, that developer is deep in a different headspace. You aren't just giving feedback; you're forcing a destructive context switch.

If a PR takes more than 4 hours to review, the 'mental cache' is cleared. The cost of fixing a simple bug triples because the author has to re-read their own code to remember why they wrote it.

Large PRs are an act of aggression

If you open a PR with 40 files and 1,200 additions, you are telling your team you don’t value their time. Nobody reviews a 1,200-line PR. They skim it, pray the tests pass, and comment 'Looks good' to get it off their plate.

This is where bugs live. Huge PRs are a defense mechanism—the author hopes the sheer volume of code will discourage deep scrutiny. It works every time.

We found that PRs with fewer than 200 lines of code are reviewed 4x faster and have 3x more meaningful discussions. If your feature is bigger than that, split it. Use feature flags. Ship the skeleton, then the muscles.

Stop using humans for syntax

If I see a comment about a missing trailing comma or a preferred indentation style, I lose my mind. That’s what Prettier and ESLint are for.

If your CI doesn't automatically fail a build for style violations, you are wasting expensive human brainpower on tasks a regex can handle. Your senior engineers should be looking at architecture, side effects, and race conditions.

Reviewing for style is bikeshedding. It feels productive because it’s easy, but it adds zero value to the product. It just slows down the merge.

The 'Nit' is a parasite

We’ve all seen it. A PR is perfect, but a reviewer leaves five 'nits' about variable naming. Now the author has to push a new commit, wait for CI to green-light again, and ping the reviewer for a re-approval.

That cycle takes hours. For what? A slightly more aesthetic variable name?

If a comment starts with 'Nit:', it should not block the merge. If you’re a reviewer, approve the PR and leave the suggestions as optional. Let the author decide if it’s worth the fix. Trust your peers.

The asynchronous trap

Slack is where PRs go to be forgotten. Sending a link to a channel and hoping for the best is not a strategy. It's a prayer.

High-velocity teams use dedicated review windows. Two hours a day, the whole team focuses purely on clearing the queue. No meetings, no coding, just reviews.

This creates a predictable cadence. If I know my PR will be reviewed at 2:00 PM, I can plan my next task accordingly. The uncertainty is what kills momentum.

Automated context is the fix

Reviewers fail because they lacks context. They see diff --git a/internal/db/store.go and have to spend twenty minutes figuring out what changed in the upstream dependency to necessitate this edit.

This is why we built git11. Humans shouldn't have what a diff does. An AI can analyze the call graph, identify that a change in api/v1 actually breaks a worker in services/billing, and flag it before a human even opens the browser.

When the reviewer arrives, they shouldn't be asking 'What is this doing?' They should be asking 'Is this the right way to do this?'

Make it hurt less

Reviewing code is a chore, and humans avoid chores. To fix your velocity, you have to lower the friction.

Move all 'is the code ugly' checks to CI. Limit PR size to 300 lines. Use tools to provide automated impact analysis so reviewers don't have to hunt for side effects.

If you can’t get a review finished in under two hours, your process is broken. Stop adding more features and start fixing how you merge them.