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.
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.
I feel like a substantial source of everyday irritation are bugs like this in bad software. It’s frustrating that devs just don’t care.
You could make software that doesn’t require your users to work around its shortcomings.
I asked him why he does this. His explanation was really built on this operant conditioning idea: "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. He uses it differently than we do because he doesn't avoid all of its little problems. But if we have a really tricky problem, I get our manager's manager. I don't know if you've ever seen him try to use an xbox controller, but he has the spatial reasoning abilities of a goldfish. He's never failed to reproduce a really hard bug. If I ever needed an Einstein-level bug reproduction, I'd track down the head of the department and put him in front of it, but it's never come to that.
They were paying exorbitant amounts of money for the license too.
A University must comply with Laws and Regulations X, Y, Z, P, D and Q and a host of other regulations the University never heard of and Blackboard went through the process to "comply" with those checkboxes. So, if you deploy Blackboard, you tick all the checkboxes automatically.
The fact that Blackboard was a garbage content management system and a terrible grade recording system was irrelevant--because the "better" systems wouldn't check the boxes.
(I say this as someone who, as a lecturer, had to manage the account logins, mailing list, and Subversion source control system for an entire class. I only ever put grades that needed to be "secure" into Blackboard. I did all that because I HATED Blackboard that badly, but it was a LOT of work. And I probably wouldn't have passed any significant security audit; although my accessibility ratings should have been excellent since everything was plain text and plain HTML)
> he distrusts the research on the impact of line length on readability.
"I easily observe hundreds to thousands of bugs per week"
which should be rewritten as
"I easily observe hundreds to thousands of things that I consider to be bugs per week"
which is to say that the "bug" is in the eye of the beholder. It seems the author stretches the definition of "bug" to include cases where something functions, but in a manner that is open to improvement or not to his taste.
`<link rel="icon" href="data:;base64,=">`
Rather than having the website author wrap lines at a width that works for the average user or use case (which may only be optimum for a percentage of users or use cases, which may not include me), the user can simply make their browser whatever width they prefer the lines to wrap at. This way, everybody gets to choose what works for them.
What are the odds!
I'm pretty sure dedicated QA roles are a thing at many companies.
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.
> 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.
"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.