Bug Blindness
TL;DR
Dan Luu argues that most people hit the same bugs he does and stop seeing them. The teams that build software are the worst at it. People learn unconscious workarounds, or they are fans of the product. Luu thinks pointing bugs out cures this quality blindness, and that coding agents make the cure more urgent.
The article
- Luu notices hundreds to thousands of bugs a week. For years he suspected he was doing something unusual. But products he judged badly broken kept launching and failing on the exact issues he had found. So he now trusts his judgment. He can even have LLMs act as normal users to show the failures reproduce.
- Fans and builders overlook flaws that outsiders find obvious. Kagi users sent him result pages full of SEO spam as proof the results were good. Volvo forums dismiss poor reliability data. A Blackboard employee believed the widely hated product was loved. Discourse staff believed the forum had great performance, while its code delayed real page loads to game LCP.
- Much of computer literacy is a library of habits that work around bugs without conscious thought. One example is compensating for a dirty mouse ball. Another is waiting before typing a Google Docs title, because early typing gets overwritten. At Microsoft he switched WiFi off to log in, because a failing login check was skipped when it couldn't connect.
- Dogfooding helps only until developers learn the workarounds and forget them. When users complain, developers usually reply with a complex sequence no new user would guess, or with a pointer to page 43 of the manual.
- He has cured friends of quality blindness by pointing out bugs until they see them too. He has seen blind teams, sure they shipped high quality, launch products with little or no chance of success. Coding agents make it easier to churn out junk. They also make it easier to fix quality, if someone notices the problem.
- An appendix argues that ads work. Geo-segmented A/B tests he saw showed good return on ad spend. Programmers with ad blockers underrate ads. Data from his time at Google suggests most users don't realize a top search result is a paid ad.
Why it matters
Worth reading for engineers and product leads who dogfood their own software and think that settles quality. The original has the full anecdotes and a footnote on Anthropic's growth while Claude was buggy. It also has Tumblr's claimed moderation fix and an appendix of readers' own unconscious workarounds, which the summary only names.
The discussion
A large, mostly sympathetic thread that drifted fast from Luu's examples to who is at fault when users struggle. The longest branch argued whether users are confused because software is bad or because some of them can't be helped. A noisy sideline turned the post's premise on the blog itself, which sets no text width.
Users without a mental model
The top comment said developers miss bugs because their mental model matches the system, while lay users have none and just retry. With badly built software, retrying can be the rational response. Former support staff said some users truly can't be helped; others answered that people of all abilities drive cars, so engineers are at fault. codeflo added that designing only for users who never learn has made software hostile to the ones who would.
The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't really form expectations in the first place. The computer is more genie than machine.
It's still a wild logical leap to me that we went from this observation, that maybe the bottom half of users never learn how the software works, to the idea that we should build software that is actively learning-hostile.
Fresh eyes find the bugs
Many confirmed the operant-conditioning idea with stories. A robotics team reproduced hard bugs by handing the controls to managers who had not learned to avoid them. One commenter tests his app with erratic scrolling and frantic resizing, and others draft long comments outside the browser. Two developers who shipped buggy software said customers were happy anyway, because most users stay on a few well-worn paths.
we use this stuff for 8 hours a day and we train ourselves to avoid all of its little pitfalls. So I get the most available person who hasn't used it all day, which is our manager.
I was wrong: the sw quality is poor, but the percieved quality is good.
Why organizations stay blind
Blackboard and Epic were cast as software bought by people who never use it, so user pain never reaches the vendor. A former Googler said outside users have no channel to report bugs. An SDET said QA gets sidelined once the whole product is bad, so pointing out bugs does nothing. Others had been labeled negative for raising problems and learned to stay quiet.
It's just what happens when the people buying software and the people using it are different.
They're not just blind to bugs. They're deliberately putting bags over their heads to keep from seeing what users are telling them.
Is bad search a bug?
The second-ranked thread rejected Luu's first example: spammy search results are a bad product, not a bug, and stretching the word makes it meaningless. Defenders replied that users don't care about the distinction, and that Luu said up front his public examples were deliberately weak. A related branch split on whether a bug is a mismatch with the spec or with reasonable expectations. QA people said nobody in a company owns fixing bad specs.
Bugs vs. bad design is a useful distinction to make imo.
I'm in the later camp, because I'm not aware of even a single company that has any department or a process that would systematically address the existence of bad expectations.
The blog's own unstyled layout
A recurring jab said danluu.com, which sets no max-width or font size, shows the same quality blindness the post describes. Defenders said browser defaults and window width are the reader's to control. Forcing a line length, they said, takes choice away from people who like long lines. Critics cited readability research and WCAG's 80-character limit, and many just reach for reader mode.
After all, he *is* complaining about the defaults in other software, but he is blind to the defaults he presents the user.
I don't see that as a code-bug but a difference in implied requirements. Namely, the expectation about *which person* can/should choose the width of the lines everyone had to read.
Consensus
Most agreed that people adapt to broken software without noticing, and that developers are the worst at seeing their own product's flaws. Watching a real user, or someone fresh, is the fastest way to find them.
Dissent
A minority found the post long and thin on concrete examples, and said search quality and page styling aren't bugs. They argued the problem is organizational. Pointing out bugs won't help when the people in charge have no reason to listen.