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.
> 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.
This is completely lost on most developers, which is why interface and UX designers exist. Developers, especially in FOSS projects, often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software. They’re smart enough— they just don’t want to have to learn about technical implementation details for the same reason most developers are perfectly content to use personal bookkeeping apps instead of learning the best ways to organize that data and making the spreadsheets manually. Most non-technologists get no dopamine hit from solving technical problems, have no need for the requisite knowledge needed to confidently do that, and are often just trying to make the computer do what it must so they can get back to doing what they’re actually passionate and knowledgeable about. When a competing product has an interface built for people without that mental model, it would have to be pretty fucking expensive to not be a no-brainier for most nontechnical users.
I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's impossible to do any amount of front-line support without collecting some horror stories.
One of my favorites is spending nearly 10 minutes trying to get someone to read a single word on their screen correctly, in a dialog box that was blocking them, containing fewer than 10 words, so I could find the cause of their problem. After nearly 30 minutes to figure out that they had a popup blocking them, and not "the computer doesn't work".
What eventually worked was getting them to spell it to me backwards. That strategy has worked out quite well in other cases too - I suspect because it avoids some of people's built-in autocorrect and dyslexia (autoincorrect).
(I honestly mostly enjoy tech support, and I've done it for many years, sometimes professionally. But some people do seem like lost causes, and are not just having a bad day)
The flip side of this is the pleasant surprise of working with a near-retirement age grandma who assures you that she "isn't technical" and "doesn't know how to use a computer", but will studiously write down every keyboard shortcut on little post-it notes and add it to their collection like they're porcelain cats she found at the Sunday markets. I've watched some of these people operate a computer in a manner reminiscent of watching an F1 driver at work, the screen just a blur as their fingers dance over the keyboard.
Absolutely, the ones that are clearly trying more than make up for the rest imo, and some are stunning. There are a lot of them. And many of the rest are just having a bad brain day and need help rubber-ducking to see the thing right in front of them - we've all been there, many times.
There's a selection effect here in that smart-enough users won't bother contacting support if they work around an issue on their own, or if something is actually a non-issue for 99%+ of the user base. The ratio of usage and support contacts can be monitored. I fear a lot of devs develop unproductive mental models of the user purely from a minority sample.
I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here.
Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable.
You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This makes for better experiences, as reality gets bound by.. well.. reality. So you don't get these weird failure modes that live in the gap between the narrative (e.g. "everything just works") and reality (e.g. "networks are always black magic").
This is also important for the user, because by having _a_ mental model (even if it is very low-res), they gain the ability to diagnose issues themselves and not be completely helpless once the magic box breaks down. They might not know exactly what to do, but the direction is very clear.
Agency is important. A lot more important than convenience. And fake convenience through frontloading short-term rewards for long-term systemic instability.
> Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc
Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.
That's one of the things that surprised me (in a positive way) about Mac OS X when I first got to use it -- it actually does indeed do lots of things in an _understandable_ and genuinely simple way. It's also clear how much work went into making the system behave in this way, it certainly wasn't an accident.
In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.
Nobody reads the docs. This will be even more true soon as LLM generated docs become more popular. I once read a user report "would be nice if I could move large Xs to uncover Y", filed a bug report myself to add the feature, and then realized that feature was already added and documented months ago, by me! I just updated it with an unobtrusive prompt/instruction to the UI when relevant. I definitely get lazy sometimes, but if you don't take the extra step to make sure a feature is easily discoverable and understandable in the UI, you're wasting almost all of its potential benefit.
Steve Krug's other book, Rocket Surgery Made Easy, got me into usability tests with real users, and how to get it in place in a corporate environment. It's shocking to watch real users use software.
the people without a model are also the easiest users to lose, they won't file a bug or explain what broke. they'll just click twice, decide the product is unreliable and use something else. then the team sees no bug report and assumes everything is fine.
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?
For me the idea that poor quality search results are a bug muddies the idea of what a bug is. It's like saying the colour of the paint in my living room is buggy because I don't like it. It might be an ugly colour that I don't like, but it is what it is. A bug would be if the colour doesn't match what was shown on the tin.
> If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.
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.
From the article: “For well over a decade, the reliability data that exists (and I think this is backed up by the anecdotal experience that mechanics who work on Volvos have) is that Volvo reliability is mediocre to poor, but of course Volvo forums are full of people who insist that Volvos are among the most reliable cars and that the data are all wrong.”
The author mentions one explanation, which is that most people driving a Volvo won’t experience a breakdown (and then generalize from that). Another one is of a very different kind known as post-purchase cognitive dissonance (https://en.wikipedia.org/wiki/Cognitive_dissonance#Consumer_...).
>I thought this had something to do with how I use computers but, over time, I've realized that it's mostly that people are hitting the same bugs and don't notice.
I suspect I know why they do not notice. See below.
>it works well, etc., but when I open up the thing and try it, it's in a state where the thing only works if you do quite a few non-intuitive workarounds.
I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them. A bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.
I can use a novel UI and figure out where to find what I need to do very quickly. In my experience with lay people, they can use the software for a decade longer than me and still not understand some of the capabilities and navigate to utilize them as I can within a few minutes or small amount of research.
>I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them. A bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.
This seems a weird thing to believe given that we know there are such things as black UI patterns designed to keep users from doing things they might want to do, but which the company might not want they do yet still are obliged to provide the possibility of doing.
As a general rule I think I am pretty good with finding out things about software, for example in pretty much every company I've worked at I'm one of the only devs who learns Jira's query language, and how to make my own dashboards to organize things, but I do at times experience UIs that I either must believe are malicious or buggy, and I stand by that interpretation no matter how they people who work at the company like to claim it is working as intended.
But I have also experienced some times when I think the way this UI works must be a bug, because otherwise the people who designed it must be incompetent idiots and also, given laws about accessibility requirements, potentially on the hook for some monetary payments in court soon.
My interpretation has been that I am often to quick to think things are bugs and not worthwhile using because I am familiar with how buggy things can be and still "work" somewhat, and also that normal uneducated users will try to soldier through things I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?
I find the ad blindness and bug blindness similar but on opposite ends: I also notice bugs easily, but I also notice ads (instead of skimming — when ad blockers do not work or apply), yet I consciously make an effort to not be tricked and sometimes explicitly decide to not buy the product if the ad is obnoxious or really abuses the psychological findings for business' gain.
Interesting topic, and funny that I personally consider the text width and font size of danluu’s blog to be a “bug”. It is well known that we can read faster with narrower text columns (remember newspaper columns when they were printed on paper). This is why I always read this particular blog with Apple’s Reader mode, which renders the text using larger font and narrower width.
That's a cop out in this specific instance: he knows the defaults are a bug, he can change it with maybe 2x lines of CSS, but he is blind to the fact that it's a bug.
After all, he is complaining about the defaults in other software, but he is blind to the defaults he presents the user.
>And, sometimes, the issues are severe, to the point where one might even say the thing actually doesn't work.
>I find this last category a bit mysterious, as when I look up discussions on how the thing got into this state ...
I'm currently on the dev side of such a product and can tell you one way it can end up like this.
Leadership decides a new feature is required, but refuses to commit to writing what they want. Through a bunch of meetings and calls developers have learned a number of vague requirements to the product, many which are conflicting, just as many are unclear if they are long term features or needed immediately.
The result is something that implements - to the letter, but not the spirit - of what the developers can agree on from this vague mountain of requirements.
The feature is returned to leadership in the hopes that having something tangible will make it clear what leadership actually wants.
However, leadership returns with a "Looks great, can you add?" and they sign off and we begin the next sprint.
Haha it’s just that the things these devices enable for us are so valuable. But life is full of suboptimal things just because that’s how it is. Some other constraint causes it.
I was at Oren’s Hummus years ago with a friend and I remember thinking that there was this heat lamp outside by the window that was very close to the glass. We were halfway through our meal when we heard a loud snap and a large crack formed in the glass. Error in process, my failure to report it, and costly consequence. Bug, eh?
It’s just that the world is full of detail and things are full of interactions. And complexity is something we’re all constantly grappling with.
Every time I do the 5 finger gesture to bring up launchpad (I think that’s what it’s called) on a Mac the text field doesn’t focus fast enough for the text. Every time I type then backspace backspace backspace and type again. That’s just life. Somewhere someone shipped something that does this. It didn’t use to be this way but it is now. I can’t really change it so I just live with it.
The world of software is complexity upon complexity created from the fact that the virtual world admits arbitrary amount of interaction at much lower cost than the physical world. Yep, the world is full of bugs. But you really have to care a lot to stop them and no one really wants to pay you to do that.
An interesting version of this is when a team basically internalizes some issues in the software they work on and it turns into something they accept as a fact of life or even turn into a joke. „X failed again? Don’t bother, it’s been a shitshow for years.” What?!
A few years ago I started leading a team working on a product that had a lot of „legacy” quirks like that. It took me a good while to set a strong quality bar, both mentally and technically. I would frequently point out where the mindset was wrong, prioritize certain fixes over project work, fix a lot of issues myself, fight with other teams to fix their stuff, run silly contests such as „who solves the most support tickets this month gets a prize” and sometimes even „stop the world” for a few days until we got something in order.
Some people might be prone to think their team will never have the time to do that (and some may be right) but in my experience quality pays back. Often fixing a small bug takes about as long as discussing if it’s important, properly filing it in JIRA and then communicating to the outside world it’s not the priority. And eventually you reach a point where you have way more calm and focus than before because nothing is burning.
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.
> 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.
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.
Applications like Blackboard exist because of the genre of "Checkboxware."
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)
It's not really regulation-driven. It's just what happens when the people buying software and the people using it are different. This is the standard problem of enterprise software is marketed to the IT department (which cares about cost, box-checking, vendor relationships, lock-in risk, bureaucratic turf wars, headcount preservation, SLAs, etc) with little or no regard for responsiveness to end user needs.
It is definitely true though that enterprise software for nonprofits (like education) sucks even harder than usual, because nonprofit IT departments don't even have the profit motive to align IT department and end user interests.
I'm with danluu on this, at least as far as the headline, and not actual details.
I run into 10 to 20 software bugs a day (feels like more). If it wasn't for the all the private data I'd leak I sometimes wish I could just put my phone and computer on screen capture for a week, with input data (keyboard/mouse/touchpad/screen) and then come back and post the 100 bugs I hit that week.
I've run into the MacOS one mentioned, getting a black screen on opening the lid. I've also run into iOS Camera app failing to open the camera. I've run into the iOS keyboard only using 80% of the width of the phone (all the keys smaller). No idea how to fix that. Closing the keyboard and re-opening does not. And killing the app, whatever app, is out because I'm in the middle of filling out a form and don't want to have to start over. I've had the phone's screen freeze quite often recently, no response to any finger presses. Locking and unlocking the phone recovers. This one is new (started happening 1-2 weeks ago)
Common/not-common. Any app that uses the phone camera to scan things (checks/ids) almost always fails in one way or another. Doesn't recognize the thing or times out like the only way they tested was in perfect conditions in their office and never tried with real users.
> I've also run into iOS Camera app failing to open the camera.
wow, you just reminded me.
From time to time I bring up the camera app, and I just get a blurry screen. I have to lock the phone and unlock it, maybe quitting the camera app before I get the camera app coming up showing what the camera sees.
I just worked around it and got on with my life and didn't yak-shave (search for a solution or file a bug)
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
This reminds me of my first job, where we did a lot of 3d modeling and mobile robotics research. When we were trying to reproduce motion bugs, a coworker of mine would track down our manager and put him at the controls. More times than not, the bug would surface and it'd trip our logging and we tracked it down.
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.
Reminds me of watching my wife use her computer. I'd help her with something and realize all the little things more regular computer users just put up with. Incorrect focus, focus stealing, windows popping up behind current windows, unclear window styling, invisible scrollbars, moving page elements, unclear instructions, the list goes on and on and on.
Unreal Engine is like this. You stab your toe about a thousand times for the first few months. Eventually you lean to stop pushing the buttons that crash.
For what it’s worth, the author would not consider this a bug. He does it (as I understand) because 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.
I had this same discussion on another HN thread a while back. I prefer lines to run as long as possible; I find it difficult/distracting to move my eyes to the beginning of the next line every few seconds. I'm sure I'm in the minority, but I have to believe I'm not the only one out there who feels this way.
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.
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.
Let's flip it around: Suppose someone put in code/markup to prevent any viewer from picking a larger or smaller font-size. Would that be "just fixing a bug", or would some of us be pissed that the author has dictated something in a way which infringes on our autonomy and disrespects our superior-knowledge about what constitutes our good reading experience?
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.
Sounds like credit card sites. Most everything is pretty creaky; “redeem rewards” is broken or offline for maintenance; “pay bill” is greased lightning all the way through.
I've noticed exactly the opposite with other kinds of lenders. Refinancing and renegotiation is optimized to the hilt, but the payments system seems to have an SLA of zero 9s.
If a website won't let you cancel, call your bank to force them to block the payment. This will cost the website $20 and a ding on their credit report. Be aware the website will ban you, so you'll need to make a new account.
Which is exactly why Amazon can get away with it. I’m not going to get permabanned from what is essentially a utility in the western world in 2026 by going nuclear with a credit card chargeback.
Hah in the AI era I noticed the agents are worse than the average person at noticing bugs. Agents use their own scale to decide if something is a success even if the output is broken. Agents are bug-blind to their own work. The consequence is that spotting bugs is now the key reviewer skill. The human’s job shifts to catching what the agent is blind to in its own work.
I usually agree with this sentiment. I have a general disdain for elaborations and novelization. Get to the point! Give me the necessary facts and make it concise!
In this case for some reason, I disagree. This post is engaging for me. I sometimes elaborate on how I came to a conclusion because that journey is equally as fascinating as the conclusion itself. While reading this authors post I was happy to see what seems like a very thorough thought process.
It was actually refreshing for me to see someone write at such length and find myself engaged.
It worked for me.
Now, putting my self in your shoes, as I have regularly had the same opinion, I have more empathy and understanding for how people consume and enjoy writing.
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.
I feel for you and I'm similar too. However, there's a fine line between what you are describing and "perfect is the enemy of the good". I've seen some who claim to be like you but in practice they are a net negative to everything because they can never agree to anything until it is perfect even when the perfect solution is beyond the capabilities and/or out of project scope/budget and/or take too long to implement ignoring business needs.
> 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.
Absolutely right. People come up with some of the most idiotic ideas, but you aren't supposed to point out the obvious flaws. These 'ideas' create a lot of jobs and success stories. The purpose of a system is what it does. Everyone wants to build an empire and they need more and more headcount, which means incredibly shitty ideas, and tons of people working on them. Everyone claims success and moves on to the next shitty idea next year for more success. Thats why, even if AI can make developers more productive, it doesn't really matter, the vast majority of projects in bigcorp are bad ideas. If your bad ideas go faster, doesn't mean it increases revenue or profit. It only helps the people involved to claim more 'success'. Now, with AI.
That's not what the term "backfire effect" refers to. The term "backfire effect" refers specifically to one specific consequence of this; namely, it refers to the idea that presenting evidence against something can make people more likely to believe it. (And my understanding is that in later studies this "backfire effect" appears to not actually exist after all, as Wikipedia appears to back up: https://en.wikipedia.org/wiki/Belief_perseverance )
I'm not sure what the term is for what you're referring to, although it's certainly a real and known effect.
Some developers treat their software like a baby when they test it or show it to others. Tapping cleanly and slowly, giving animations time to finish, scrolling slow and smooth, etc.
I like to beat the shit out of my software when testing. Constant erratic scrolling and zooming, multi-touch shenanigans, pressing multiple buttons as fast as I can, using back gestures and the browser back button (if it's a web app), changing the window size and orientation frantically, and just all kinds of rough usage.
If your software can't cope with these things then you're doing a disservice to your users.
I feel cursed with the opposite of this. I can't seem to go 12 hours without finding a bug in software which it's not my job to test. It's all so awful. I waste a lot of time trying to figure out how to report these bugs, because they offend me.
Just once I'd like to believe, for a little while, that this industry has produced something worth being proud of.
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.
Great post. Pins the tail on the donkey. As a lifelong Unix and Linux user, when I was forced to use Windows at work, this kind of thing struck me profoundly. Windows users just didn't notice how crippling the whole experience was. They'd write it off as "user error" when Word autocapitalized strings weven if auto caps was turned off, things like that, similar to "natural running motion".
Same for Linux and MacOS users. Fans are blind to their own OSes problems because they've become blind to its issues or gotten used to the workarounds. I use all 3, I run into issues on all 3 all the time.
Sure, but they're not the standard business operating system that the world economy depends on. We in the USA let Microsoft have a monopoly essentially because of this.
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.
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.
This is completely lost on most developers, which is why interface and UX designers exist. Developers, especially in FOSS projects, often love to condescendingly assert that users are just not reading the docs, or are not smart enough to understand the software. They’re smart enough— they just don’t want to have to learn about technical implementation details for the same reason most developers are perfectly content to use personal bookkeeping apps instead of learning the best ways to organize that data and making the spreadsheets manually. Most non-technologists get no dopamine hit from solving technical problems, have no need for the requisite knowledge needed to confidently do that, and are often just trying to make the computer do what it must so they can get back to doing what they’re actually passionate and knowledgeable about. When a competing product has an interface built for people without that mental model, it would have to be pretty fucking expensive to not be a no-brainier for most nontechnical users.
I worked at a small company that had a policy of putting devs on front-line support in a rotation, both because it was too small to have dedicated support staff and because the owners wanted devs to understand how users interacted with the system better.
I can assure you that while some users merely think differently than devs, there is cohort of users who are absolutely not smart enough. It's impossible to do any amount of front-line support without collecting some horror stories.
What eventually worked was getting them to spell it to me backwards. That strategy has worked out quite well in other cases too - I suspect because it avoids some of people's built-in autocorrect and dyslexia (autoincorrect).
(I honestly mostly enjoy tech support, and I've done it for many years, sometimes professionally. But some people do seem like lost causes, and are not just having a bad day)
Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible.
This makes for better experiences, as reality gets bound by.. well.. reality. So you don't get these weird failure modes that live in the gap between the narrative (e.g. "everything just works") and reality (e.g. "networks are always black magic").
This is also important for the user, because by having _a_ mental model (even if it is very low-res), they gain the ability to diagnose issues themselves and not be completely helpless once the magic box breaks down. They might not know exactly what to do, but the direction is very clear.
Agency is important. A lot more important than convenience. And fake convenience through frontloading short-term rewards for long-term systemic instability.
This is where skeuomorphism used to be king before computers ate the world. In the 90s everybody knew how a paper book worked, so document readers presented as books. Everyone knew how a tape deck worked, so audio apps presented as tape decks. Floppy disk as save icon, etc
Unfortunately, the passage of time is inexorable, and by the late 2000s we had a lot of users who had never actually seen a tape deck/floppy disk. And the whole skeuomorphic project came crashing down.
In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.
Well, Jira does that too in many of its input widgets: anything you type while the page is loading is cleared after the page is loaded.
At this point users have been conditioned to accept this sort of react crap.
There are some well reported bugs in Microsoft/Google/Apple that have persisted for years. Nobody cares.
"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.
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?
> If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.
A bad product perhaps, but not a bug.
- The thing the user searched for doesn't exist, so it wasn't found. This is not a bug.
- The user did a good job of searching, using relevant keywords etc, but the relevant thing (which exists) didn't come up. This is a bug.
- "Search didn't read my mind" -- if search is a core competency this is a bug, but otherwise I would consider it a deficiency or a missing feature.
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.
The author mentions one explanation, which is that most people driving a Volvo won’t experience a breakdown (and then generalize from that). Another one is of a very different kind known as post-purchase cognitive dissonance (https://en.wikipedia.org/wiki/Cognitive_dissonance#Consumer_...).
I suspect I know why they do not notice. See below.
>it works well, etc., but when I open up the thing and try it, it's in a state where the thing only works if you do quite a few non-intuitive workarounds.
I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them. A bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them.
I can use a novel UI and figure out where to find what I need to do very quickly. In my experience with lay people, they can use the software for a decade longer than me and still not understand some of the capabilities and navigate to utilize them as I can within a few minutes or small amount of research.
Shoutout to https://grumpy.website/. Love it.
This seems a weird thing to believe given that we know there are such things as black UI patterns designed to keep users from doing things they might want to do, but which the company might not want they do yet still are obliged to provide the possibility of doing.
As a general rule I think I am pretty good with finding out things about software, for example in pretty much every company I've worked at I'm one of the only devs who learns Jira's query language, and how to make my own dashboards to organize things, but I do at times experience UIs that I either must believe are malicious or buggy, and I stand by that interpretation no matter how they people who work at the company like to claim it is working as intended.
But I have also experienced some times when I think the way this UI works must be a bug, because otherwise the people who designed it must be incompetent idiots and also, given laws about accessibility requirements, potentially on the hook for some monetary payments in court soon.
My interpretation has been that I am often to quick to think things are bugs and not worthwhile using because I am familiar with how buggy things can be and still "work" somewhat, and also that normal uneducated users will try to soldier through things I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?
Seems like reader mode is needed due to bad defaults.
After all, he is complaining about the defaults in other software, but he is blind to the defaults he presents the user.
>I find this last category a bit mysterious, as when I look up discussions on how the thing got into this state ...
I'm currently on the dev side of such a product and can tell you one way it can end up like this.
Leadership decides a new feature is required, but refuses to commit to writing what they want. Through a bunch of meetings and calls developers have learned a number of vague requirements to the product, many which are conflicting, just as many are unclear if they are long term features or needed immediately.
The result is something that implements - to the letter, but not the spirit - of what the developers can agree on from this vague mountain of requirements.
The feature is returned to leadership in the hopes that having something tangible will make it clear what leadership actually wants.
However, leadership returns with a "Looks great, can you add?" and they sign off and we begin the next sprint.
Haha it’s just that the things these devices enable for us are so valuable. But life is full of suboptimal things just because that’s how it is. Some other constraint causes it.
I was at Oren’s Hummus years ago with a friend and I remember thinking that there was this heat lamp outside by the window that was very close to the glass. We were halfway through our meal when we heard a loud snap and a large crack formed in the glass. Error in process, my failure to report it, and costly consequence. Bug, eh?
It’s just that the world is full of detail and things are full of interactions. And complexity is something we’re all constantly grappling with.
Every time I do the 5 finger gesture to bring up launchpad (I think that’s what it’s called) on a Mac the text field doesn’t focus fast enough for the text. Every time I type then backspace backspace backspace and type again. That’s just life. Somewhere someone shipped something that does this. It didn’t use to be this way but it is now. I can’t really change it so I just live with it.
The world of software is complexity upon complexity created from the fact that the virtual world admits arbitrary amount of interaction at much lower cost than the physical world. Yep, the world is full of bugs. But you really have to care a lot to stop them and no one really wants to pay you to do that.
A few years ago I started leading a team working on a product that had a lot of „legacy” quirks like that. It took me a good while to set a strong quality bar, both mentally and technically. I would frequently point out where the mindset was wrong, prioritize certain fixes over project work, fix a lot of issues myself, fight with other teams to fix their stuff, run silly contests such as „who solves the most support tickets this month gets a prize” and sometimes even „stop the world” for a few days until we got something in order.
Some people might be prone to think their team will never have the time to do that (and some may be right) but in my experience quality pays back. Often fixing a small bug takes about as long as discussing if it’s important, properly filing it in JIRA and then communicating to the outside world it’s not the priority. And eventually you reach a point where you have way more calm and focus than before because nothing is burning.
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.
If the users are missing the mark so bad that they're wiping their asses with suede, I'd argue the documentation and examples are at fault.
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)
It is definitely true though that enterprise software for nonprofits (like education) sucks even harder than usual, because nonprofit IT departments don't even have the profit motive to align IT department and end user interests.
I run into 10 to 20 software bugs a day (feels like more). If it wasn't for the all the private data I'd leak I sometimes wish I could just put my phone and computer on screen capture for a week, with input data (keyboard/mouse/touchpad/screen) and then come back and post the 100 bugs I hit that week.
I've run into the MacOS one mentioned, getting a black screen on opening the lid. I've also run into iOS Camera app failing to open the camera. I've run into the iOS keyboard only using 80% of the width of the phone (all the keys smaller). No idea how to fix that. Closing the keyboard and re-opening does not. And killing the app, whatever app, is out because I'm in the middle of filling out a form and don't want to have to start over. I've had the phone's screen freeze quite often recently, no response to any finger presses. Locking and unlocking the phone recovers. This one is new (started happening 1-2 weeks ago)
Common/not-common. Any app that uses the phone camera to scan things (checks/ids) almost always fails in one way or another. Doesn't recognize the thing or times out like the only way they tested was in perfect conditions in their office and never tried with real users.
wow, you just reminded me.
From time to time I bring up the camera app, and I just get a blurry screen. I have to lock the phone and unlock it, maybe quitting the camera app before I get the camera app coming up showing what the camera sees.
I just worked around it and got on with my life and didn't yak-shave (search for a solution or file a bug)
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.
"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.
You must find it difficult to read books, magazines, newspapers, as all of them have short lines
Let's flip it around: Suppose someone put in code/markup to prevent any viewer from picking a larger or smaller font-size. Would that be "just fixing a bug", or would some of us be pissed that the author has dictated something in a way which infringes on our autonomy and disrespects our superior-knowledge about what constitutes our good reading experience?
Are you maximizing your browser’s windows?
What are the odds!
Wow, there's Obsidian, Kagi, and Apple in a nutshell.
In this case for some reason, I disagree. This post is engaging for me. I sometimes elaborate on how I came to a conclusion because that journey is equally as fascinating as the conclusion itself. While reading this authors post I was happy to see what seems like a very thorough thought process.
It was actually refreshing for me to see someone write at such length and find myself engaged.
It worked for me.
Now, putting my self in your shoes, as I have regularly had the same opinion, I have more empathy and understanding for how people consume and enjoy writing.
The world is fascinating.
> 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.
> Not the happy path. I get accused of being “negative,” my suggestion is shitcanned, and I’m shunned.
Absolutely right. People come up with some of the most idiotic ideas, but you aren't supposed to point out the obvious flaws. These 'ideas' create a lot of jobs and success stories. The purpose of a system is what it does. Everyone wants to build an empire and they need more and more headcount, which means incredibly shitty ideas, and tons of people working on them. Everyone claims success and moves on to the next shitty idea next year for more success. Thats why, even if AI can make developers more productive, it doesn't really matter, the vast majority of projects in bigcorp are bad ideas. If your bad ideas go faster, doesn't mean it increases revenue or profit. It only helps the people involved to claim more 'success'. Now, with AI.
I thought this is due to the "backfire effect", because humans perceive criticisms of things they like as threats.
https://theoatmeal.com/comics/believe
I'm not sure what the term is for what you're referring to, although it's certainly a real and known effect.
I like to beat the shit out of my software when testing. Constant erratic scrolling and zooming, multi-touch shenanigans, pressing multiple buttons as fast as I can, using back gestures and the browser back button (if it's a web app), changing the window size and orientation frantically, and just all kinds of rough usage.
If your software can't cope with these things then you're doing a disservice to your users.
This is why I find that it is better to wait a couple of months before actually do the final test before shipping your own software.
Just once I'd like to believe, for a little while, that this industry has produced something worth being proud of.
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'm pretty sure dedicated QA roles are a thing at many companies.
The whole "I see bugs where others do not" reminded me of that same phenomenon.