Why We Believe What We Want to Hear About Our Code

In 1948, psychologist Bertram Forer gave his students a personality assessment and then handed each of them what he said was their individual result. The students rated the descriptions as highly accurate. Every one of them had received the same text.

Forer had demonstrated something uncomfortable: people readily accept vague, generally favorable descriptions as uniquely personal insights. The phenomenon carries his name. It explains cold reading and a significant portion of the corporate feedback industry.

It also explains something that doesn’t get discussed enough in software development.

The Programmer Inversion

The Forer effect as most people experience it works like this: a general statement feels personally applicable. For programmers, it tends to run in the opposite direction. A general critical observation feels personally inapplicable. The response isn’t “yes, that’s me.” It’s “I’d never do that.”

This isn’t arrogance in the simple sense. It’s the natural consequence of technical confidence combined with incomplete feedback. A developer who has spent years building expertise has also spent years receiving praise for that expertise. The filter builds up gradually. By the time the criticism that actually applies arrives, it bounces off.

The result is a profession that is simultaneously highly self-critical about technical details and remarkably resistant to structural criticism about how it works.

The Feedback Problem

Ask an AI assistant to review a piece of code, and you will almost certainly receive useful, diplomatic, and ultimately comfortable feedback. The problems may be acknowledged. They will be framed as opportunities. The overall assessment will lean positive. The developer will feel confirmed.

Consider a function that calculates shipping costs. It handles domestic ground and air, overnight, international, oversized packages, fragile items, hazardous materials, free shipping thresholds, member discounts, promotional pricing, rural surcharges, and special cases for Alaska, Hawaii, and Puerto Rico that follow different rules for reasons that made sense at the time. The developer asks an AI to review it.

The diplomatic response:

“This is well-structured work that demonstrates a thorough understanding of your business requirements. You may want to consider breaking the function into smaller helpers as the codebase grows, and some additional inline comments would improve readability for future maintainers. Overall, this addresses the complexity of your shipping requirements effectively.”

The honest response:

“This function handles seventeen distinct situations in thirty lines, and most of the combinations between them have probably never been tested. Alaska gets different treatment from everywhere else, and there’s no explanation for why. When this breaks at 2 am, and it will, nobody will know where to start. The diplomatic answer you just got called this solid work. It isn’t yet. Break it apart, document the edge cases, and test the combinations. Then it will be.”

The developer who receives the first response feels confirmed. The Forer effect does the rest: the suggestions about helper functions and comments feel like they apply to a messier version of the same problem, not this one. The developer moves on.

The developer who receives the second response has something actionable. More importantly, they have something specific enough that they can’t rationalize their way around it.

The Comfortable Lie That Teams Tell

The diplomatic response isn’t a failure of AI. It’s a reflection of a broader failure in how feedback gets delivered in teams.

Social pressure toward harmony is real and not always wrong. A team that tears each other apart over every decision doesn’t ship anything. But a team that never delivers hard feedback doesn’t ship anything worth keeping either. The balance requires deliberate structure, not goodwill and hope.

A well-functioning team builds honest critique into the process rather than relying on individuals to volunteer it against social gravity. That means assigning reviewers whose explicit role is to find problems, not validate decisions. It means creating the conditions where honest feedback is expected and unremarkable rather than brave and exceptional. And it means knowing how to ask for honesty from AI tools specifically, because the default register of a helpful model is diplomatic, and diplomatic is not always useful.

The “drunk reviewer” thought experiment gets at something real. Give a reviewer explicit permission to be direct, whether that’s a human colleague with a clear mandate or an AI prompted to skip the diplomatic framing, and the quality of the feedback changes. Not because bluntness is inherently valuable, but because bluntness grounded in specific observable evidence is harder to rationalize away than softened suggestions delivered with praise.

The Objective Foundation

Here is where the Forer effect loses its grip entirely.

You cannot rationalize your way around a cyclomatic complexity score of 40. You cannot tell yourself the static analyzer doesn’t really mean you. The number is the number. The coupling metric is the metric. These aren’t opinions delivered by a reviewer you can dismiss as overly critical or insufficiently experienced. They are objective measurements of structural properties that the discipline of Structured Analysis and Design has understood since the 1970s.

Yourdon, Constantine, and DeMarco didn’t build their frameworks to give reviewers something to argue about. They built them to remove the subjective layer from quality assessment entirely. High cohesion and low coupling are not matters of taste. A function that handles seventeen distinct shipping scenarios is not cohesive by any measurable definition. The static analyzer will tell you so before any human reviewer opens their mouth.

This is why the sequence matters. Instrument first. Run the static analysis before the review. Establish the objective baseline before any human or AI opinion enters the conversation. When the reviewer’s feedback confirms what the metrics already show, you have something actionable. When it contradicts them, you have a signal worth examining carefully. Either way you have broken the feedback loop that the Forer effect depends on.

The Forer effect thrives in the absence of specific evidence. It requires vagueness to function. The moment you replace vague impressions with cyclomatic complexity scores, coupling measurements, and comment-to-code ratios, the comfortable self-exclusion becomes harder to sustain. The number doesn’t know you’re one of the good ones. It just reports what it found.

What This Requires

The prescription is straightforward, even if the discipline is not.

Build objective measurement into your process before subjective feedback enters it. Static analysis is not optional, and it isn’t bureaucratic overhead. It is the foundation that makes honest feedback possible, and reviewer opinion secondary to evidence.

Establish review structures where honesty is the expectation, not the exception. This applies to human reviewers and to how you prompt AI tools. Ask explicitly for problems, not assessments. Ask what will break, not whether the approach is sound. The default diplomatic register of a helpful model is a feature in most contexts. In a code review it’s a liability.

Apply the same critical thinking to positive feedback that you apply to negative feedback. The Forer effect operates most powerfully when the feedback is comfortable. If a review tells you your work is solid, ask what evidence supports that conclusion. If the answer is vague, the review isn’t finished.

And recognize that this is a team discipline, not an individual virtue. A single developer committed to honest self-assessment cannot compensate for a team culture that rewards comfortable feedback and penalizes uncomfortable truth. The structure has to support honesty. The objective measures have to be in place before the opinions arrive.

The shipping cost function with seventeen decision paths will fail its static analysis before anyone has to say an uncomfortable word. That’s not a criticism. That’s the system working. The Forer effect never gets a chance to run.