Bug Blindness

I think there are two opposite causes here: either an overly-aligned or completely unaligned mental model.

For developers, bug-blindness tends to be because their mental model is so close to the system's model that both have the same blind spots, and the developer can't effectively think outside the system (the classic "QA walks into a bar, orders 0 beers, orders -1 beers, orders 0.999 beers" vs "customer walks into a bar, asks where the bathroom is, bar immediately bursts into flames").

On the other hand, a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. 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.

You can see this in the article: "Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten". That's a developer forming a model of the system. The lay alternative is to simply learn that sometimes when you type in a box, the text appears. Other times, it doesn't. If it doesn't, you try again.

You don't need to understand the system if you abandon the assumption that the system was designed to be understood. And, in practice, the widespread plagues of shitty engineering, anti-features, and lack of respect for the user often combine to make that model the more information-theoretically optimal one.

In that sense, the very thing that makes us miserable is our perverse need to treat Google Docs as an engineered product rather than a cross between a djinn and a symbiotic fungus.

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.

This is rather interesting to read. But it reinforces something I've seen in my career. The majority of users of software I've helped build, they use it in ways that are mind bending to me. Workflows I would never think of, that somehow do what they need.

The second one is most software contains bugs. Users that expect to get things done simply choose workflows to avoid the worst consequence of those bugs very quickly.

Parts of this reminded me pleasantly of one of my favorite John Regehr posts, "Operant Conditioning by Software Bugs" https://blog.regehr.org/archives/861

Blackboard is definitely a really strong contender for the worst software I've ever had to use. When I was in uni, I went so far as to write an alternative that scraped the content from blackboard and published it on a site that I could actually browse sensibly.

They were paying exorbitant amounts of money for the license too.

Bug: this blog has no max-width. Lines of text will grow infinitely long with width.

My absolute favorite bug is the one where the “cancel your Amazon Music subscription” is seemingly the only one of what must be tens of thousands of UI elements in the Amazon app that simply loads a blank white screen no matter what.

What are the odds!

Did I write this?

I choose tools I use, configure them, report bugs, and occasionally contribute fixes. But when I can't, I work around them, yet never get used to the workaround.

"Habitual mitigation" does not happen in me, and it's partly intentional.

I have created bad software in the past, but when I saw how people work with it, I could not be proud. Learned to look at software like a user, and don't want to unlearn that.

I believe (or maybe I hope) software will be democratized and people will start to demand good software.

> At times, I've tried to see if I can get a job somewhere where I just fix quality issues all day. This has never panned out, due to some combination of this not being a very high priority and it also not being a normal role that companies have a role for.

I'm pretty sure dedicated QA roles are a thing at many companies.

I’m really anal about the Quality of my own software, and tend to be hard on others’ software (doesn’t make me too popular).

> I've had multiple jobs where directors/VPs/execs/etc. sometimes ask me to evaluate something when they want an actual opinion from someone who is relatively likely to notice issues (and fix them or drive fixes for them if necessary).

I’ve had the experience where I need to be asked, and even then, if my opinion isn’t “ist güt,” it’s often ignored.

When someone makes a proposal, I tend to immediately see the potential issues, and used to point them out, and suggest workarounds or mitigation strategies, without being asked.

Not the happy path. I get accused of being “negative,” my suggestion is shitcanned, and I’m shunned.

I’ve learned to just keep my mouth shut, and if the situation calls for it, start quietly preparing for when the wheels fall off.

I have also learned to never say “I told you so,” as that is a petty and vindictive statement. Doesn’t help at all.

Long ago I realized I had the ability to see race conditions in source code, at least more easily/accurately than others on average. It was helpful when reviewing the code of others, esp more junior. And I once briefly considered getting a custom T-shirt made with the words "I see race conditions." (in the spirit of the famous scene from The Sixth Sense with "I see dead people.") and wearing it to the office during formal code review meetings. But a friend talked me out of it when he pointed out it might get misinterpreted as being something racist rather than having to do with threading and concurrency.

The whole "I see bugs where others do not" reminded me of that same phenomenon.

Is there also a thing called Readability blindness?