Three perfect scores in a row kills your skill meter

There’s a weird moment that happens when you’re building a website and everything just works. The form submits without a refresh. The mobile menu slides out like butter. The Lighthouse score hits 100 across the board. You feel like a god. Then you ship it, and the client sends through a screenshot from their iPhone 6, and suddenly your perfect score means nothing because the hero image is squashed and the font is rendering like a ransom note.

That moment — where confidence curdles into confusion — is not just about bad luck. It’s about a cognitive trap that behavioural psychologists have been poking at for decades. We’ve all felt it: the more consistent our wins, the more fragile our actual skill feels. And for anyone building websites for a living, that feeling is a signal, not a bug. Let’s unpack why three perfect scores in a row might be the worst thing that happens to your judgment this week.

The Illusion of Mastery Through Repetition

Here’s the thing about web development: it’s a domain with a lot of feedback loops, but most of them are slow. You push a change, you wait for the build, you refresh, you squint, you tweak. That’s a classic fixed-ratio schedule — you get a reward (the site looks right) after a predictable amount of effort. Your brain loves this because it’s safe. But safety breeds overconfidence.

Daniel Kahneman’s work on System 1 and System 2 thinking is the obvious reference here. System 1 is your fast, intuitive, pattern-matching brain. It’s what tells you “this button looks clickable” or “that shade of blue feels trustworthy.” System 2 is the slow, deliberate, logical brain — the one that actually reads the CSS spec or double-checks the contrast ratio.

When you nail three audits in a row, System 1 starts running the show. It sees the same patterns, the same stack, the same layout structure, and it screams “we’ve got this.” But here’s the kicker: your skill meter isn’t actually rising. You’re just getting faster at recognising familiar territory. The moment the client throws in a weird request — “can we make the header sticky but only on Tuesdays?” — System 1 is useless, and System 2 is out of practice because you haven’t needed it in a while.

This is the fluency heuristic in action. We judge our own competence by how easily information comes to mind. Easy recall = feeling smart. But in web dev, easy recall often just means you’ve done the same cookie-cutter brochure site four times this month. The skill is in the unfamiliar, not the fluent.

Variable-Ratio Reinforcement: Why the Bug Hunt Feels Addictive

Now, let’s talk about the flip side. If perfect scores make you complacent, then the occasional bug should make you sharper — but only if you don’t tilt. There’s a reason why debugging feels so strangely compelling, and it’s straight out of B.F. Skinner’s playbook.

Variable-ratio reinforcement is when a reward comes after an unpredictable number of responses. Think of checking your inbox for a client reply, or refreshing a staging URL hoping the cache finally cleared. You don’t know when the fix will appear, but you know it will eventually. That unpredictability is precisely what makes the behaviour stick. It’s why developers will spend 45 minutes hunting a missing semicolon when they could have just read the error log.

But here’s the trap for Australian builders specifically: we love a good “she’ll be right” attitude, and that can slide into loss aversion territory. Once you’ve had three perfect scores, the fourth build feels like it should be perfect. When it isn’t, the pain of that failure outweighs the pleasure of the previous wins — Kahneman and Tversky showed that losses hurt roughly twice as much as gains feel good. So you overcorrect. You triple-check everything. You start rewriting perfectly fine code because you’re scared of the next imperfection.

That’s not skill. That’s anxiety wearing a developer hat.

The “Hot Hand” Fallacy in Your Deployment Pipeline

There’s a classic study by Gilovich, Vallone, and Tversky (1985) on the “hot hand” in basketball. Players and fans believed that a player who hit three shots in a row was more likely to hit the fourth. The data said otherwise — each shot was essentially independent. But the belief persisted because our brains are wired to see streaks where randomness exists.

Now, swap basketball for deploys. You push three updates in a row without a single regression. You start to feel hot. You think your judgment is calibrated, that your code is clean, that your browser support matrix is bulletproof. So you skip the cross-browser check. You don’t bother testing the form on a slow 4G connection. You push straight to production because the last three times worked.

That’s the hot hand fallacy in your own workflow. Your skill didn’t change between deploy two and deploy four. The environment did. The client’s hosting provider updated PHP, or a third-party plugin dropped an API change, or someone on the team made a data entry error. None of that is about you. But because you felt invincible, you took risks you wouldn’t have taken cold.

The fix isn’t to stop feeling confident — it’s to separate feeling confident from being certain. The best developers I know treat every deploy like a fresh coin flip. Not because they lack skill, but because they respect the variance.

The Skill Meter Is a Myth — Here’s What to Track Instead

So if three perfect scores don’t mean you’re getting better, what does? Let’s get practical.

First, stop measuring your skill by outcomes and start measuring by decision quality. A perfect Lighthouse score is an outcome. A good decision is choosing to build a static site instead of a bloated React app because the client only needs five pages. That decision doesn’t show up in a score, but it saves the client money and saves you a headache. Track how often you ask “what could break here?” before you ship, not how often you ship without breaking.

Second, build in deliberate variability. If you always use the same framework, the same plugins, the same CSS reset, you’re not building skill — you’re building muscle memory. Once a month, pick a project and use a tool you’re awkward with. It’ll feel slower, your scores will drop, and that’s the point. That discomfort is System 2 firing up. That’s where actual skill lives.

Third, adopt a pre-mortem before every big deploy. Sit down with your team (or just yourself) and ask: “It’s three months from now, and this site is a disaster. What happened?” Write down three specific reasons. Maybe the client’s marketing team will upload a 10MB image and kill the load time. Maybe the booking form will fail on Safari. Maybe the SEO plugin will conflict with the new update. When you name the risks before they happen, you’re not being pessimistic — you’re being realistic. And realism beats optimism every time when it comes to building things that last.

Finally, reframe the perfect score. It’s not a validation of your skill. It’s a snapshot of a moment in time where the variables aligned. Enjoy it, take the screenshot, put it in the portfolio. But don’t let it fool you into thinking the next project will be easier. It won’t be. It’ll be different, and different is where the growth is.

The next time you get three flawless builds in a row, don’t pop the champagne. Go break something on purpose — a staging server, a test branch, a side project. Remind yourself that the skill was never in the score. It was in the uncomfortable, messy, uncertain work of making things that work for real people in unpredictable conditions. That’s the work that keeps you sharp. And that’s the work that’s actually worth bragging about.