Confetti on a Merge Lifts Second-PR Reviews 14%
The pull request had been sitting for nineteen hours. Two approvals, one stale comment from a reviewer who'd gone to lunch and never come back, and a CI pipeline that had gone green twice. By any reasonable reading of the team's contribution guidelines, it was done. It merged forty minutes after someone dropped a single emoji into the thread — not a thumbs-up, not a checkmark, but a small animated burst of confetti rendered as a GitHub reaction. The author, a backend engineer at a mid-sized SaaS shop, later told me it was the first time in months that shipping code had felt like anything at all.
That anecdote is not evidence. It's a hook, and I want to be honest about the difference, because the question underneath it is genuinely interesting and genuinely contested: does the emotional texture of a code review — the tiny dopamine hit of a reaction, the small social reward of being seen — actually move engineering metrics? Or is it decoration we bolt onto a process that runs on deadlines and dependency graphs?
There's a number floating around internal tooling discussions that keeps pulling me back: second-PR review rates rising 14% in one team's experiment after they added lightweight celebration reactions to merged pull requests. I don't have the original study in front of me, and I'd be skeptical of anyone who claimed the figure generalizes. But the mechanism it implies is worth taking seriously, because it sits at the intersection of two things I spend a lot of time on: web platform engineering and the behavioral psychology of why humans do things they don't strictly have to do.
The Baseline Problem: Review Is Unpaid Cognitive Labor
Start with the structural reality. Code review is one of the few high-leverage engineering activities that is almost never in anyone's job description as a first-class deliverable. You are measured on features shipped, incidents resolved, systems designed. You are not measured on how many diffs you read carefully, how many edge cases you caught, how many times you left a comment that saved a colleague two days of debugging six weeks later.
This is a classic principal-agent mismatch, and it produces a predictable failure mode. The first review on a PR — the one that determines whether the work is directionally right — usually gets done fast, because it's attached to a person you're collaborating with, often in a synchronous channel, often with visible urgency. The second review, the one that catches the subtle race condition or the missing index, is where attention collapses. By the time a PR is one approval deep, the social pressure is gone. The work is "basically done." The marginal reviewer has no stake, no deadline, and no reward.
Behavioral economists have a name for the general shape of this problem. It's a form of diffusion of responsibility crossed with present bias — the costs of reviewing are immediate and certain (twenty minutes of focused attention, context-switching cost, the risk of being wrong in public), while the benefits are delayed, probabilistic, and mostly accrue to someone else. Under those conditions, rational agents under-invest. Not because they're lazy, but because the incentive gradient points downhill.
So the interesting question isn't "how do we motivate engineers to review more." It's narrower and more tractable: what small, cheap, honest signals can we add to the review loop that shift the perceived payoff of the second pass without turning the whole thing into a Skinner box?
What Variable-Ratio Reinforcement Actually Predicts (And Where It Misleads)
The obvious frame here is B.F. Skinner's work on variable-ratio reinforcement schedules — the finding, from mid-century operant conditioning research, that behavior reinforced on an unpredictable schedule is more resistant to extinction than behavior reinforced consistently. It's the mechanism behind slot machines, and it's the mechanism a lot of product teams consciously or unconsciously reach for when they design notification systems, streaks, and badges.
The temptation, if you're building internal tooling, is to import that machinery wholesale. Random rewards, unpredictable drops, a leaderboard that reshuffles. And this is where I want to push back hard, because the analogy breaks in an important way.
Variable-ratio schedules work best on behaviors that are low-cost, repeatable, and don't require deep cognition. Pulling a lever. Checking a feed. They are terrible for behaviors that require sustained, careful attention, because they train the subject to optimize for the frequency of the reward rather than the quality of the act. If you gamify code review with unpredictable rewards, you will get more reviews. You will also get faster, shallower reviews, because the reward is attached to the act of reviewing, not to the finding of a bug.
Daniel Kahneman's work on loss aversion — the finding that losses loom roughly twice as large as equivalent gains — points at a related trap. A lot of engineering gamification leans on loss: streaks you can break, rankings you can drop, "review debt" dashboards that turn red. Loss-framed mechanics are powerful and they are corrosive. They produce anxiety, they encourage gaming, and they make the underlying activity feel like a threat rather than a contribution.
The confetti-on-merge idea is interesting precisely because it does neither of these things. It's not variable-ratio. It's not loss-framed. It's a deterministic, positive, low-stakes social signal attached to a completed act of collaboration. That's a much narrower intervention, and it's the kind that cognitive science actually supports.
Three Mechanisms That Plausibly Explain a 14% Lift
If the number is real — and again, treat it as a hypothesis, not a fact — there are at least three well-documented mechanisms that could produce it. None of them require believing that engineers are lab rats.
1. Completion signals and the Zeigarnik effect
Bluma Zeigarnik's 1927 finding, that interrupted tasks are remembered better than completed ones, is usually cited in productivity writing as a reason to avoid multitasking. But it has a second implication that matters here: the human nervous system is bad at registering completion without a marker. An open PR is an open loop. It sits in the back of your mind, generating low-grade cognitive load, until something closes it.
Most engineering tooling closes loops silently. The PR merges, the branch deletes, the ticket auto-transitions. No signal fires. The confetti reaction is, functionally, a completion marker — a small, visible, socially-shared acknowledgment that a loop has closed. That's not a gimmick. It's addressing a real gap in how distributed teams experience their own work.
2. Social proof and the second-reviewer problem
Robert Cialdini's work on social proof describes the tendency to look at others' behavior to determine correct action, especially under uncertainty. The second-reviewer problem is a textbook case of uncertainty: the PR has one approval, so the "correct" action is ambiguous. Is it done? Is another pass expected? Is it rude to re-open something that looks settled?
A visible reaction on the merge — even a trivial one — is a form of social proof that this work was seen and valued by more than one person. It makes the norm explicit: reviews here end in acknowledgment, not silence. Over time, that norm can shift the perceived value of being the second reviewer. You're not doing invisible janitorial work. You're participating in a ritual the team has agreed to perform.
3. Identity reinforcement and the "good teammate" frame
There's a body of work in organizational psychology — Teresa Amabile's research on intrinsic motivation and the "progress principle" is the most cited — showing that small wins and visible progress are among the strongest drivers of engagement in knowledge work. The mechanism isn't reward per se. It's identity: the accumulation of small signals that tells you what kind of engineer you are in this organization.
If your tooling treats review as invisible labor, engineers will treat it as invisible labor. If your tooling marks it — lightly, publicly, without ranking anyone — you nudge the identity frame toward "I'm someone who shows up for my teammates' code." That's a much more durable motivator than any badge.
A Concrete Example: What a Lightweight Implementation Looks Like
Let me make this less abstract. Suppose you're building internal tooling on top of GitHub's API — a Node.js service that listens for pull_request webhooks, filters for closed with merged: true, and posts a reaction to the PR conversation thread. The entire thing is maybe eighty lines. Here's the shape of it:
You receive the webhook, verify the HMAC signature, and check the merged flag. You fetch the PR's review history to count distinct approvers. If the count is two or more, you post a reaction — not a comment, because comments generate notifications and noise, but a reaction, which is quiet by default. You might vary the reaction based on the number of reviewers, or the size of the diff, or whether the PR sat open for more than a day. You might not vary it at all.
The important design choices are all negative: no leaderboard, no public ranking of who reviews most, no streak tracking, no notification to the whole team. The signal goes to the PR thread, where the people who already care about that PR will see it. It's ambient, not broadcast.
I've seen teams run variants of this. One pattern that seems to work is attaching the reaction to the second approval specifically — the moment the review crosses from "one person looked" to "the team looked." That's the behavior you're trying to reinforce, and it's the behavior that's currently invisible. Another pattern is a weekly digest, posted in a low-traffic channel, that lists merged PRs with two or more reviewers. No names ranked, no counts compared. Just a list of things that happened.
The 14% figure, if it holds anywhere, probably comes from something like this: the second-review rate goes up not because reviewers are chasing confetti, but because the norm of second-reviewing becomes visible in a way it wasn't before. People do what they see other people doing. The confetti is just the visible trace.
Where This Goes Wrong
I'd be a bad journalist if I didn't flag the failure modes, because this is exactly the kind of intervention that curdles.
The first failure mode is metric capture. The moment someone puts "second-review rate" on a dashboard that a manager reviews, the behavior changes shape. Engineers start approving PRs they haven't read to hit the number, or splitting PRs to inflate counts, or gaming the reaction trigger. Goodhart's law is not a metaphor; it's an empirical regularity in software teams.
The second is performative enthusiasm. If the celebration feels mandated — if there's a bot that posts "🎉 Great job team!" on every merge — it becomes wallpaper. The signal has to be sparse enough to mean something. A reaction on every PR is noise. A reaction on the PRs that actually involved collaboration is information.
The third is exclusion by design. Anything that publicly counts contributions will, over time, disadvantage people who work part-time, take parental leave, do unglamorous maintenance work, or simply prefer deep work over visible activity. If you're going to add social signals to a review loop, you have to be deliberate about what you're not measuring. The safest version measures nothing about individuals and everything about the state of the queue.
What I'd Actually Build Next
The forward-looking version of this isn't confetti. It's a broader rethinking of how engineering platforms surface the social dimension of technical work — which is, historically, the dimension we've been worst at instrumenting.
Consider what we currently measure well: build times, deploy frequency, incident counts, test coverage. Consider what we measure badly or not at all: how often a review caught a real bug, how often a comment saved someone an hour, how often a teammate unblocked another teammate on something that wasn't their job. These are the signals that predict whether a team holds together under pressure, and they're almost entirely invisible to the tooling we build.
A few directions I think are worth exploring:
Review-quality signals over review-count signals. Instead of counting approvals, look at whether a review comment led to a code change, whether a review caught something a test didn't, whether a reviewer engaged with the design rather than the style. These are harder to compute, but they're closer to what you actually want.
Ambient acknowledgment over broadcast celebration. The confetti works because it's local. Scale it up and it dies. Build for the thread, not the channel.
Explicit opt-in for social features. Not everyone wants their work celebrated publicly. Give people a way to receive acknowledgment privately, or to opt out entirely, without it being a statement about their engagement.
Instrument the loop, not the person. The most useful thing you can build is a system that tells you where PRs are getting stuck, which reviewers are overloaded, and which work is going unreviewed — without attaching any of that to individual performance.
The confetti-on-merge story is a small story. It's one team, one number, one reaction. But it points at something larger: the emotional infrastructure of software teams is mostly unbuilt, and the parts that exist are usually adversarial — dashboards that shame, streaks that threaten, leaderboards that rank. There's a lot of room between "no signal at all" and "full gamification," and most of it is unexplored.
The next time you're building a webhook handler or a Slack integration or an internal dashboard, ask what loop it closes and who feels it. That question is cheap to ask and surprisingly hard to answer well. The teams that answer it well are the ones that keep their engineers for years, and the ones that don't are the ones whose PRs sit for nineteen hours while everyone waits for someone else to look.