The Quiet Cost of Knowing Your Own Software Too Well

Ask a group of programmers why they ship buggy software and you’ll get a range of predictable answers: deadlines, tech debt, unclear requirements. Ask them how they know the software is good, and you’ll get a much more revealing response. The people closest to a product are usually the least able to see its flaws. This is “quality blindness,” and for those not afflicted, the evidence is everywhere.

Developers who report seeing bugs everywhere and believing “nothing works” are often told they’re being negative. But the reality is that other users are hitting the same bugs—they just don't notice them. Perceiving defects is a skill, but it’s also a curse. While non-programmers may have a more peaceful experience of technology, trained software professionals benefit from cultivating this awareness. Pointing out bugs to friends for a few weeks is enough for most receptive people to start spotting them on their own. This matters because teams rife with quality blindness routinely ship products with greatly reduced or even no chance of success, thinking they’re delivering something excellent.

When External Reviewers See What Insiders Don't

When an executive or director wants an unvarnished opinion on a product or project, they will often call on someone known for noticing issues. This kind of expert review almost never finds nothing. The issues discovered usually range from moderate annoyances to outright failures—cases where the product functionally requires non-intuitive workarounds for a “normal” user to accomplish basic goals. In such cases, internal discussions are still praising the thing as great and working well. A user's tolerable experience typically requires doing several non-obvious things to make software behave, or the product is simply unusable.

Perhaps such defects are rare, because expert reviewers intentionally use software unusually? But products that launch and then fall flat on their face, with users running into the very same issues the reviewer found beforehand, prove this isn't just a matter of exotic workflows. If a product seems severely flawed upon first use, it probably is. With modern LLMs, it’s even possible to prove the consistency of these failures by simulating how a normal user would interact with the product.

What “Moderate” and “Severe” Actually Mean

It helps to define what quality failures look like. A web search that returns pages full of low-quality SEO spam and some scam sites, for example, is a moderate defect. It’s bad, but the search engine still returns results. Severe is defined entirely differently: it means a normal user likely won’t be able to use the thing at all—not that they get a subpar experience. A severe case would involve a search engine returning 500 errors half the time or the majority of results being outright scams.

When a review finds moderate issues, for instance with major search engines, the response can be telling. Fans of a specific product will argue with the characterization and insist the results are good, sometimes even providing their own search results to prove it. But virtually every time, those provided results are just as full of spam and fail to link to an accurate or up-to-date answer. For the product’s most zealous users, acknowledging product defects is cognitively difficult. For instance, Volvo owners will insist on the car’s reliability despite a decade of data showing mediocre-to-poor outcomes and mechanics corroborating that anecdotal experience. This “fan blindness” is a real phenomenon that applies to search engines, automobiles, and course management software.

Loving a Product Users Hate: The Blackboard Effect

In the case of the hugely unpopular university courseware Blackboard, the gap between perception and reality was massive. Widely disliked by both students and professors to the point of being one of the most detested software products in education, its own employees were blindsided. When one developer was asked how they could work on software so widely disliked, they responded with confusion—they genuinely thought it was a well-loved product. They could summon no awareness of the near-universal dislike reflected in news articles, Wikipedia pages, and basic water-cooler conversation.

A similar blindness affects Discourse, the forum software. Employees were confident in its supposed excellent performance. Yet the engineering reality included code that artificially gamed Core Web Vitals metrics like LCP, actually slowing down page loads to cheat on benchmarks. This game did nothing to help the user and was purely marketing-driven. The developers behind such a feature had to know their app performed poorly, but mental barriers kept that knowledge from affecting their claims.

Sports Fans as a Metaphor for Engineering Teams

The capacity to filter out negatives is perhaps most obvious in sports. One basketball player is widely and subjectively considered the dirtiest player of his era, and he objectively dominates measures like punching, kicking, and kneeing fellow players in the genitals. Yet fans of his team rationalize these flagrant fouls away with absurd phrases like “natural rebounding motion.” This is classic willful blindness, and it’s universal.

Those in charge of a codebase are a lot like those sports fans. They are likely to obsess over the best parts of what they have built and easily dismiss or ignore its genuine and observable flaws. While it is easy to see this blindness in sports fans or company fanboys, it is much harder to see that same bias in your own reaction to your work. For many engineers, the thought processes inside their own heads feel like the opposite—an immediate jump to flaws and faults, especially in anything they have created.

Accumulated Habits Are Camouflage

A large fraction of what we call computer literacy is really the development and retention of deep-set habits for working around software bugs. These workarounds become subconscious, so the workarounds are invisible to their own users. One story from the mechanical mouse era illustrates this. As gunk accumulated on the mouse ball over time and tracking became erratic, the user unconsciously compensated with violent countervailing hand movements. To them, the pointer moved perfectly smoothly. For anyone else, it was entirely unusable. A user can be so well-adapted to a broken system that the breakage becomes invisible to them.

The same happens today. To avoid a Google Docs glitch that overwrites the document title when typed too soon after opening, an experienced user might sit idle for a moment or go do something else before setting the title. Others might toggle their laptop’s WiFi switch off before logging in to a corporate network, to avoid a service error, or restrict typing to when they are in a certain app state. These habits are so engrained that they may not even know why they perform them—they just know that is “just the way software is.”

Consider logon failures at a large company. One service could fail a user’s login attempt with “There are currently no logon servers available to service the logon request.” A workaround was to disable WiFi completely before logging in, in which case the failing check would be bypassed entirely. Developers who built up these habits stopped noticing that those behaviors are aberrations, not features.

Why Dogfooding Fails

Dogfooding your own software is a commonly prescribed antidote to quality blindness. In practice, though, it doesn’t work because dogfooding is done by developers already conditioned to work around whatever issues exist. They have already built up a giant library of habits (such as knowing to search after a delay, or clicking through to a certain panel) that they will perform at a non-conscious level. From a developer's perspective, the task is easy: "just do X" through a complex sequence of actions that only a highly initiated user could derive.

To improve user experience significantly, a product must eliminate the need for these weird habits. But that is difficult, because the developers don’t even realize the habits exist until someone without them tries and fails. Those conditioned to solve problems in software will likely have already found their own way around barriers, making feedback like “I can't do X” confusing to them.

The Rewards of Noticing

Curing someone of quality blindness is achieveable. Pointing out unexpected flaws is often enough to make a receptive person start seeing bugs everywhere themselves. This isn’t unmitigated negativity. The people who gain this skill are the ones whose software is genuinely better, as they see what build engineers, product managers, and even senior leaders miss.

There is an optimal productivity tradeoff: most projects are deliberately low quality. What works is targeting the highest-ROI testing and not polishing beyond what’s sensible. A conscious decision to trade quality for speed is acceptable and even wise. The real danger is when a team is so blind to quality that they don't realize they're making that tradeoff, thinking their low-quality output is high quality.

More than ever, this is critical in the age of LLM coding agents. Churning out vast amounts of broken code is easier than ever and is a behavioral trap. Yet AI also gives us tools to improve both performance and quality to previously impossible levels.

Advertising Blindness and the Efficacy of Ads

Quality blindness isn't limited to software makers. Take advertisements. Programmers overwhelmingly consider themselves immune to them, assuming everyone uses ad blockers and filters them out mentally. But data from geo-segmented A/B tests at large companies shows a very high return on ad spend. Ads demonstrably create real revenue and new-user gains. In a study that turned ad spend on in some geographic regions and turned it off in others (split by US states, Canadian provinces, etc.), tangible lift from the ads could be seen.

Why do ads work for normal people if they’re supposedly useless to “savvy” users? Because most people don't realize which results on a search page are ads. When many people search on Google, they click the top result believing it to be the best organic result, unaware that it is paid for. This informational asymmetry is what makes advertising effective—and is why many developers have a skewed perspective on its value. The same blindness that prevents programmers from seeing bugs on screen prevents them from seeing the bugs that other demographics also encounter online.

On Mittel-Level Insights and the Modern Pressures of Noticing

Even acknowledging quality blindness, some argue that one can succeed commercially while shipping near-broken products. Anthropic had the best growth numbers in tech history while Claude was still very buggy. It had the best model, though, and even they eventually spent significant engineering effort on quality. If you have monopoly power, a powerful enterprise sales team, or network effects, subpar quality might be tolerable for a while. Blackboard was long protected by its #1 market share. It declined to become a niche minority player in its market. When the protective barriers fail, the quality problems won't protect you.

The path forward is to hold onto that awareness — to see software as it is, not as we hope it to be. For engineers, especially those working with the new crop of powerful AI tools, this is the ultimate edge.

Thanks to Yossi Kreinin, Dennis Snell, Michael Malis, Emu Chu, Gary Bernhardt, Jon Surrell, and Matt Mullenweg for comments/corrections/discussion.

Appendix: Habitual Workarounds, Shared and Silent

  • Em Chu: When waking and unlocking a Mac laptop, it’s easy to end up in an unusable state where the screen is black or showing only a cursor. The only fix is to physically close the lid and reopen it. To mitigate this, users often wait a second, interact with the trackpad, and then unlock to avoid something going sideways.
  • Gary Bernhardt: While reading a draft of this post in Google Docs, the UI broke, making it impossible to scroll up to read comments. This exact bug is known and has multiple available workarounds, often used without thinking.
  • Daniel Gibson: Who else uses the Shift or Esc key to deliberately close out of programs or stop processes, specifically because it’s the least likely keystroke to cause unintended actions in a given program?

Note: Unintentionally on topic—the <abbr> tags worked on mobile browsers last week, but have since stopped working across all iOS browsers (Safari, Chrome, Firefox).

This jibes with a traditional joke from Russian-speaking developers: to save a field’s data, you have to click your mouse on the adjacent field. Any keyboard-oriented user will notice the issue neatly; everyone was so conditioned by prior quirks that these unwritten rules simply become the way things are. Like earning a reputation as a dirty basketball player, perceiving quality problems positions you as having a unique, and highly valuable, view into your own products.