Luu argues that support ticket volume and internal dashboards attenuate the real bug signal by 10x to 1000x, because most users who hit bugs simply leave or blame themselves rather than filing reports. Product managers reading these metrics as quality proxies are consuming data that has already been silently filtered through two orders of magnitude of user attrition.
Luu contends that employees use their own products under privileged conditions — corporate networks, accumulated account state, edge-case permissions — that immunize them from cold-start bugs, low-bandwidth failures, and session-expiry issues. This means dogfooding gives leadership false confidence while the actual user experience remains invisible to the people building it.
By submitting Luu's essay to HN where it reached 186 points and 87 comments, davidmckenna amplified the argument that internal engineering perspectives systematically diverge from user reality. The strong engagement from senior developers signals broad recognition that dogfooding as practiced does not surface the bugs that matter.
Dan Luu published another one of his long, meticulously-cited essays — this one titled *Bug Blindness* — arguing that most software organizations dramatically underestimate how buggy their own products are. The piece, sitting at 186 points on Hacker News with a comment thread full of engineers nodding grimly, isn't a scoop or a news event. It's a diagnostic. And it lands because almost every senior developer reading it has lived some version of the story.
Luu's thesis is deceptively simple: the mechanisms companies use to measure product quality are structurally biased toward underreporting bugs. Internal dashboards look green. Support tickets trickle in at manageable rates. The team ships. Meanwhile, on the other side of the screen, users are hitting broken flows, giving up, and quietly churning — and none of that shows up in any metric anyone is looking at.
He backs this with a pattern he's observed across companies from FAANG-scale operations down to small startups: the ratio of users who hit a bug to users who report a bug is routinely 10x, 100x, sometimes 1000x. The rest just leave, or work around it, or assume it's their fault. If your product manager is reading ticket volume as a proxy for quality, they are reading a signal that has been attenuated by roughly two orders of magnitude before it reaches them.
The interesting part of Luu's argument isn't that bugs exist — everyone knows that. It's *why* the measurement systems fail, and the failure modes are more structural than most engineering leaders admit.
First, dogfooding is a lie most companies tell themselves. Employees use the product on corporate laptops, on corporate networks, with corporate accounts that have edge-case permissions and years of accumulated state. They don't hit the cold-start bugs. They don't hit the low-bandwidth bugs. They don't hit the "my session expired mid-checkout" bugs. When a Stripe engineer uses Stripe or a Google engineer uses Search, they're using a version of the product that has been implicitly configured for them by their own environment. Luu points out that this isn't dogfooding — it's kibble-tasting from a bowl the chef prepared personally.
Second, telemetry has a survivorship problem. Your analytics pipeline captures events that fired. It doesn't capture the events that *should have fired but didn't* because the page crashed, the network dropped, or the JavaScript threw before the tracking pixel loaded. The bugs that hurt you most — the ones that prevent conversion, prevent signup, prevent the user from ever becoming a data point — are precisely the ones your data infrastructure is worst at seeing. This is the observability equivalent of only counting the survivors of a plane crash: your dataset is defined by the absence of the failure mode you're trying to measure.
Third, support tickets are a rate-limited channel with a high activation threshold. Filing a ticket requires the user to (a) know the product is at fault rather than themselves, (b) find the support channel, (c) care enough to write it up, and (d) believe someone will actually read it. Most users flunk at least one of those gates. Luu cites experiences at companies where a proactive outreach — literally calling users who hit a specific error — surfaced hundreds of bugs for every one that had been ticketed. The ratio is not a rounding error. It's the whole picture.
Fourth, and this is where the essay gets uncomfortable for engineering leadership: the incentives inside most orgs actively reward bug blindness. If your OKR is "reduce reported P1s by 40%," the fastest path is not fixing bugs — it's making bugs harder to report. Move the support link. Add a chatbot triage layer. Require a repro case. Reported bugs go down. Actual bugs stay the same or increase. The dashboard turns green. Someone gets promoted. This is not a hypothetical; it's the modal outcome of measuring what's easy to measure instead of what's true.
The HN thread reinforces this with war stories. One commenter describes a fintech where the mobile app's crash rate was reported as 0.3%, until someone noticed the crash reporter itself was crashing on the affected devices — real rate closer to 4%. Another describes a SaaS product where onboarding "completed" for 92% of signups, but the definition of "completed" had been quietly loosened over three quarters to include users who bounced on step 2. The metric held. The business did not.
If you take Luu seriously — and you should — the practical implications are unglamorous but concrete.
Stop treating user anecdotes as low-signal noise. When one user tells you something is broken, the default engineering assumption should be "this is broken for a hundred users I'll never hear from," not "this is a weird edge case." The prior is empirically wrong in the other direction. Weight anecdotal reports much more heavily than the raw volume suggests, especially when they come from users who had to work to reach you.
Instrument the negative space. Your funnel metrics should include not just "users who completed step N" but "users who arrived at step N and then vanished without completing anything else." That silent-drop cohort is where your worst bugs live. Session replay tools (LogRocket, FullStory, Sentry's session replay) exist for exactly this reason, and yet most teams either don't deploy them or don't watch the recordings. Watching ten sessions of your actual onboarding flow will teach you more than a quarter of dashboard-staring.
Do outbound support, not just inbound. Pick a cohort — new signups who didn't activate, existing customers who suddenly stopped using a feature, users who hit a specific error code — and have a human email or call them. This is expensive. It's also the highest-leverage bug-discovery mechanism most teams have never tried. Intercom-style "we noticed you had trouble with X, can we help?" outreach converts silent frustration into signal.
Audit your dogfooding for reality. If your entire engineering org is on the enterprise tier with elevated permissions, none of them are experiencing the free-tier product. Rotate. Give people burner accounts. Make someone use the product on a $200 Android phone on a hotel wifi network for a week and report back. The results will be humbling.
Bug blindness isn't a technical problem — it's an organizational epistemology problem, and Luu's essay is really an argument about how companies come to believe things that aren't true about their own products. The tooling to fix it mostly exists. The willingness to look at what the tooling reveals is the actual bottleneck. Expect the essay to circulate in engineering leadership Slacks for a few weeks, produce a flurry of "we should really watch some session recordings" resolutions, and then largely be forgotten — because the incentive structure that produced the blindness in the first place hasn't changed. The teams that internalize it will quietly ship better software than their competitors and won't be able to fully explain why.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.