I had to give up when the first example of a "bug" that the author could see, which others are blind to, was search results.
"In some cases, people sent me their actual search results. In every such case, the search results did not contain a good result that I could see"
Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, is not a 'bug'. That's like saying there is 'bug blindness' in the publishing industry because when I pick up a random book, it sucks, even though others think it's fine. Sure, maybe something is wrong, could even be improved, but lets save the word 'bug' for something more specific.
At what point does search quality degrade to the point where is becomes a bug?
A bug is when actual behavior does not match stated or intended behavior. If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.
Or maybe you mean to say we should reserve the word bug for deviations that are unintentional?
Later in the article he uses "quality blindness" instead, which is probably a better description of most of the issues he talks about.
Dan isn't necessarily Bertrand Russell so ill give him a pass for not using the perfect word in every place.
But this article is in my opinion one of the best attempts at explaining a fundamental problem in software product work that has never (in my experience) been laid out this well. I will implore you to finish it.