7 ms·

Bug Blindness

• sidewndr46 1mo ago
  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.
  • asimilator 1mo ago
    > 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.
    • sublinear 1mo ago
      > 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.
• theandrewbailey 1mo ago
  Bug: this blog has no max-width. Lines of text will grow infinitely long with width.
  • Conlectus 1mo ago
    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.
    • Cider9986 1mo ago
      It's less readable for me, never heard of any research. Whatever, there's reader mode.
    • lo_zamoyski 1mo ago
      Which brings us to one of the earlier claims "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.
    • andrekandre 1mo ago
      > he distrusts the research on the impact of line length on readability. whats the reason for that?
  • encomiast 1mo ago
    To say nothing of this bit of markup, which actually raises an exception in the browser: `<link rel="icon" href="data:;base64,=">`
    • jwilk 1mo ago
      Curiously, this makes Firefox display the default favicon (instead of no favicon): https://github.com/mozilla-firefox/firefox/raw/refs/heads/main/toolkit/themes/shared/icons/defaultFavicon.svg https://github.com/mozilla-firefox/firefox/raw/refs/heads/ma...
  • kmoser 1mo ago
    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.
    • socalgal2 1mo ago
      > I find it difficult/distracting to move my eyes to the beginning of the next line every few seconds. You must find it difficult to read books, magazines, newspapers, as all of them have short lines
      • lmm 1mo ago
        I am in the same boat as GP, and I wonder if it's one of the reasons I migrated hard to ebooks and online magazines/newspapers as soon as that became possible and never looked back.
      • mrob 1mo ago
        The bad text formatting in printed works (including the bizarre decision to sacrifice useful vertical position cues ("ragged right") to imitate the technique medieval scribes used to reassure their patrons they weren't wasting valuable parchment ("full justification")) is a big reason why I avoid them whenever possible.
      • roelschroeven 1mo ago
        I'm in the same boat as kmoser. I don't like narrow text lines either. In my experience, books are mostly OK, as long as they don't split up the text in columns. Magazines and newspapers often do have columns that are much narrower than I would like.
      • kmoser 1mo ago
  • skydhash 1mo ago
    > Bug: this blog has no max-width. Lines of text will grow infinitely long with width Are you maximizing your browser’s windows?
    • frabcus 1mo ago
      I do - I much prefer using computers with only one window visible. And use all the keyboard shortcuts (tab, window and desktop switching) to rapidly change what the thing it shows is. I reckon there's something interesting about human variety in focus and/or visual processing this tells!
      • layer8 1mo ago
        I, on the other hand, use the keyboard shortcuts to adjust the browser width to achieve the desired line width and line start, because even when the web page takes care to set these, it varies from site to site and rarely is what I want. (For sites I visit often, I use window manager automation to auto-adjust the browser window size.)
    • theandrewbailey 1mo ago
      No. I keep my browser to about half of my 27" 4k monitor.
  • PieUser 1mo ago
    Thank god for Reading Mode in browsers...
  • Terr_ 1mo ago
    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?
  • nottorp 1mo ago
    Someone always complains about that when a danluu link is posted. Every time I have to go back to the article (usually after having already read most of it) and notice "yes, it's using the whole browser window". I think you can obtain the common experience of one sentence per screen and lots of scrolling by pressing ctrl/cmd and plus a couple times.
  • chrisjj 1mo ago
    By that token every CSS1 page is bugged.
• ChrisMarshallNY 1mo ago
  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.
  • thelastgallon 1mo ago
    > 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.
  • CrimsonRain 1mo ago
    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.
• encomiast 1mo ago
  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.
  • deleted 1mo ago
    [deleted]
  • aesthesia 1mo ago
    Later in the article he uses "quality blindness" instead, which is probably a better description of most of the issues he talks about.
  • prmph 1mo ago
    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?
    • gavinsyancey 1mo ago
      The trouble is, there are three different "versions" of "the search didn't work," only one of which I would say is definitely 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.
    • 1mo ago
• deleted 1mo ago
  [deleted]
• nicoburns 1mo ago
  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.
  • bsder 1mo ago
    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)
    • jdm2212 1mo ago
      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.
      • miki123211 1mo ago
        This goes even deeper than that. Users don't choose their university by how good that university's software is (just as we don't choose apartment complexes and power companies this way). This gives university IT no incentive to deploy software that doesn't suck. Banks and cellphones also used to work this way, until they suddenly didn't, which was quite a shock to the existing players in the market.
• aljgz 1mo ago
  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.
• transcriptase 1mo ago
  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!
  • nlawalker 1mo ago
    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.
    • AlotOfReading 1mo ago
      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.
  • megagpt3 1mo ago
    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.
    • transcriptase 1mo ago
      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.
• spiderfarmer 1mo ago
  Is there also a thing called Readability blindness?
  • Y-bar 1mo ago
    What’s wrong with the browser default styles?
    • TulliusCicero 1mo ago
      It sucks.
      • Y-bar 1mo ago
        Ticks all the boxes for readability for me: + good contrast + good size + good line height + adjustable line width And so on. On the negative side, it’s a bit ugly.
    • spiderfarmer 1mo ago
      You have one of the symptoms.
      • Y-bar 1mo ago
        Like what? That my browser (Firefox) has no problem displaying the content with good contrast, font size, line height and so on?
• kmoser 1mo ago
  > 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.
  • scottg489 1mo ago
    Isn't the classic QA role typically about finding bugs not necessarily fixing them?
    • deleted 1mo ago
      [deleted]
    • kmoser 1mo ago
      Ok, but who do you think fixes the bugs? There must be countless devs out there who are slaves to fixing Jira tickets all day, so I still don't understand OP's assertion that full-time bug fixer isn't a thing.
• moyix 1mo ago
  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 https://blog.regehr.org/archives/861
  • jakevoytko 1mo ago
    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.
    • jay_kyburz 1mo ago
      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.
    • bentcorner 1mo ago
      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.
  • jodrellblank 1mo ago
    "Time passed, and they resented the defects no longer. The defects had not been remedied, but the human tissues in that latter day had become so subservient, that they readily adapted themselves to every caprice of the Machine. The sigh at the crises of the Brisbane symphony no longer irritated Vashti; she accepted it as part of the melody. The jarring noise, whether in the head or in the wall, was no longer resented by her friend. And so with the mouldy artificial fruit, so with the bath water that began to stink, so with the defective rhymes that the poetry machine had taken to emit. All were bitterly complained of at first, and then acquiesced in and forgotten. Things went from bad to worse unchallenged." - E.M Forster, The Machine Stops, 1909 http://emforster.de/hypertext/template.php3?t=tms http://emforster.de/hypertext/template.php3?t=tms
• sgentle 1mo ago
  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.
  • DrewADesign 1mo ago
    > 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.
• sorrybloke 1mo ago
  [dead]
• syngrog66 1mo ago
  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.
  • yyny 1mo ago
    "infinite looping, deadlocks, race conditions, memory leaks... these are the words I use to describe my ex-girlfriend"
• socalgal2 1mo ago
  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.
  • m463 1mo ago
    > 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)
    • socalgal2 1mo ago
      It shouldn't have that bug in the first place. It's not about yak-shaving
      • m463 1mo ago
        For me to spend time on it would be yak-shaving.
• bediger4000 1mo ago
  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".
  • socalgal2 1mo ago
    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.
    • bediger4000 1mo ago
      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.
• __MatrixMan__ 1mo ago
  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.
• m3kw9 1mo ago
  A bit of perfectionism helps with esp UI bugs. A little flash, slight unusual pause, trying different ways to break the code..
• kid64 1mo ago
  > I get that people who are fans of things tend to be blind to the thing's faults. Wow, there's Obsidian, Kagi, and Apple in a nutshell.
• omoikane 1mo ago
  > humans have a high ability to ignore negatives in things they're a fan of, including (and often especially) their own work I thought this is due to the "backfire effect", because humans perceive criticisms of things they like as threats. https://theoatmeal.com/comics/believe https://theoatmeal.com/comics/believe
  • Sniffnoy 1mo ago
    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 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.
• ghastmaster 1mo ago
  >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. Shoutout to https://grumpy.website/ https://grumpy.website/. Love it.
  • bryanrasmussen 1mo ago
    >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?
• jose_zap 1mo ago
  That’s how perception works. We only see what we want to see, and discard or explain away the rest.
• coder-pm 1mo ago
  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.
• meling 1mo ago
  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.
  • watermelon0 1mo ago
    There is no CSS configuration for text/font on the website, so it's using browser defaults. Seems like reader mode is needed due to bad defaults.
    • lelanthran 1mo ago
      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.
      • lmm 1mo ago
        There is no way to specify a good size in CSS - a size that looks good on current computers will be too big on old computers, and a size that looks good on old computers looks too small on current ones. Browsers and users are the ones who can fix this.
        • Tepix 1mo ago
          I think your knowledge of CSS might be outdated. What's wrong with the following CSS snippet for example? body { max-width: 70ch; /* Limits the text column to a comfortable reading width */ margin: 0 auto; /* Centers the text column on large screens */ padding: 1.5rem; /* Prevents text from touching the edges on small/mobile screens */ line-height: 1.6; /* Gives the lines room to breathe */ } As for font size, you can use font-size: 1rem; to respect the browser's default font size.
• qsera 1mo ago
  > Bug Blindness 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.
• gieksosz 1mo ago
  Unnecessarily long post. It could have been 4x shorter and conveyed the same message better.
  • ghastmaster 1mo ago
    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. The world is fascinating.
    • nottorp 1mo ago
      If you think a bit, you'll notice that it's long but it's not padded for content length. It does not repeat the same thing 100 times with different wording. Every "bug" he talks about is somewhat different.
  • zhivota 1mo ago
    He would have written a shorter post, but he didn't have the time.
    • ragall 1mo ago
      He only gave himself 30 minutes to write the post and publish it.
• wodenokoto 1mo ago
  >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.
  • simon84 1mo ago
    While I agree on the fact, this is the typical case where you need a business analyst in between to 'translate' that requirement and confront the leadership if it is unclear. If you mean that leadership IS the business analyst, then you are in trouble :D
  • patrickmay 1mo ago
    This is why you write the PRD if you don't have a competent Product Manager to do so. Get sign off before implementation.
• arjie 1mo ago
  Fun post. Enjoyed it. 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.
• bschwindHN 1mo ago
  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.
• XRG 1mo ago
  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_behavior https://en.wikipedia.org/wiki/Cognitive_dissonance#Consumer_...).
  • ragall 1mo ago
    A mistake that both Dan and the forum users made, was to discuss averages instead of reliability for certain platforms and/or engine types. Most manufacturers have models with wildly different reliability.
• necovek 1mo ago
  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.
• goyozi 1mo ago
  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.
• ksec 1mo ago
  I do think a lot of these are not Bug Blindness, but a bar for acceptable quality standards. A low bar means people walk past without realising it, a medium bar may take notice but it doesn't bother them and tends to get throw out within min or seconds. A high bar gets insane irritation that some may even call OCD. And unfortunately, these spectrum follows an S curve. If you have a high bar, you are likely in the single digit percentage monitory. And the same is across all things not just software.
  • crabbone 1mo ago
    I've met with this attitude before. It's when developers interpret the function of QA to exclusively search for the situations where the expected functionality and actual don't match. They would reject anything coming from QA saying that the expected functionality is wrong. So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? I'm in the later camp, because I'm not aware of even a single company that has any department or a process that would systematically address the existence of bad expectations. And, if anyone should be given the power to act on it, the QA seems to be the most likely candidate.
    • sakjur 1mo ago
      > So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? Good thoughts and framing, thank you for that. I think I'm in the former camp, because I think fixing bad expectations is a matter of thoughtful redesign that should follow a slightly different process to fixing bad implementations (what I would call a bug). Not every issue in a program is a bug, and that has nothing to do with the importance or urgency to fix the issue. Assuming a rigid product organization, I think developers _should_ ask testers to escalate "works according to spec" even if the spec is unreasonable. Otherwise developers might be torn between QA, UX, and architects fighting about how something should or shouldn't work. At least for me, finding myself in such a position is a recipe for excessive meetings and losing focus on other equally important matters.
• danjc 1mo ago
  This hits. Ive had an annoying issue with Codex VS Code extension for weeks if not months when queuing up a follow up. Often it just disappears, I think it's just a UI glitch is actually queued but I can't click steer if the UI doesn't update and I find myself automatically going CMD+A, CMD+C before sending a follow up message.
• dusted 1mo ago
  I also think it's due to normalization of deviance, people are just used to it.. - You can't build a model, because everything will be changed with the next update, so, even if not consciously, people won't do it, why bother learning something that's not going to be of any use next time you use the application. - because you basically don't know how anything works, it's a coin toss whether it's actually not working, or you're just "using it wrong". - most things won't do the thing you expect of them consistently, so you don't expect anything of them. Last night, I uploaaded some documents to my insurance company => modal: - Title: "Files successfully uploaded" - Text: "An unknown error occurred" - Button: "Ok" Thank you.
• paganel 1mo ago
  > so the non-LLM options here are some posts that are much sloppier than my normal posts (in a human slop kind of way), or almost no posts. I'm a little confused, but as far as I understand this is a LLM-written post, isn't it? That would explain the very big length of it. Or maybe I've understood things wrong, in which case my excuses to the writer (which, in that case, could reasonably be called a writer).
  • mrob 1mo ago
    The author uses LLMs for research but writes the articles by hand: "with LLMs, it's so much easier to look at data and figure things out, but the time it takes to write something up hasn't fundamentally changed"
    • paganel 1mo ago
      Thanks for the input, wasn’t sure if he was just copy-pasting his finds directly or not, looks like he isn’t.
• bambax 1mo ago
  Our brain is geared towards efficient signal processing, and is actively working to delete signals it deems "unnecessary". It wants us to notice only the new and the unexpected; that's why after a short while you don't notice the same smell or the same recurrent noise. They are just ignored as "already detected / not new". The reason for this may be evolutionary (although we don't know what traits were the most effective to help us survive in the wild); but there is a very practical reason to ignore signals, which is that there's so may of them: if we did process every data sent from every sensor and thought about odors, light, temperature, noise, etc. then we would be overwhelmed and could not do anything else. That's also why we usually don't "see" things or people: we identify them. We don't see faces, we simply identify Alice or Bob. Which in turn explains why most people can't draw: the concept of Alice can't be drawn; to draw Alice we need to actually follow the features of her face. Being an artist means being able to unlearn (or disable) that identification process. And I think the reason most people don't see bugs is similar: they're not interested, all they want is to get something done. If there's a simple workaround that makes the thing work, then that's good enough; all the rest is irrelevant. This is not bias or benevolence: this is efficiency.
• gmm1990 1mo ago
  It’s interesting the author ponders what they might be missing now. it seems like it’s the deterioration of the writing due to llms. I’ve liked some of the authors posts in the past. And might look in more detail at the differences between the old posts and new ones because it could be a great example for what to watch out for when using llms for writing and maybe coding. There weren’t any concrete examples of bugs besides the Google Docs issue. Like what was so bad about blackboard (I also remember thinking it was terrible). There was a link to a great article about search but again no specific example here. There are a lot of words but not a ton of new information. Maybe I’m just bias against llms, this could have been written entirely without then for all I know.
• ludicrousdispla 1mo ago
  I think at least half of the software developers out there simply don't test their code in the final product (or at all). And why would they when their revision is being reviewed in a pull request?
• aghhelmut 1mo ago
  Reading the first part of the article I thought it was about real bugs and I was like "Wow we are surrounded by hundreds to thousands of bugs a week, but are blind to them somehow".
• raverbashing 1mo ago
  Does having a website with no set-width and unusable without reader mode counts as bug blindness?
  • stavros 1mo ago
    I'd say it does, since it doesn't work well.
  • mrob 1mo ago
    No. Designers shouldn't force their own preferences on third parties. Everybody likes different text presentation, so websites should stick to the defaults and let readers configure their browsers as they prefer.
    • raverbashing 1mo ago
      > Designers shouldn't force their own preferences on third parties. Fallback to the default is a design choice, even if it doesn't look like it
• alanuhoo 1mo ago
  Is that why your blog is plain white text on a black background, so it's less buggy?
• youngtaff 1mo ago
  What does the author have a against a text size that’s readable?
  • munch117 1mo ago
    The page does not set a text size. You are complaining about your own browser's defaults.
    • TulliusCicero 1mo ago
      Browser defaults suck, then. This is classic "works fine on my machine".
      • munch117 1mo ago
        The default for paragraph layout does suck indeed. But at least the font you should be able to customize.
  • lkbm 1mo ago
    It's larger than HN on my browser. It seems to just be what you have your browser default to.
• Sniffnoy 1mo ago
  Responding to something from the linked Patreon post: > Blackboard (as well as Epic and SharePoint) are classic examples of software where the user and the purchaser are different and the purchaser basically doesn’t care about the user, so you don’t expect the software to be good and it would be a bit of a surprised if the software didn’t deliver a bad user experience. But it was even more surprising to me that someone working on some of the most reviled software out there could think that the software was widely loved. I worked briefly at Epic and the attitude there seemed to be more like "yes we know people hate Epic but they're wrong". :P People there didn't think Epic was widely liked! (The explanations given were basically, 1. people hate Epic because their IT department configured it wrong, if they configured it in a more suitable manner they wouldn't have these problems, and, 2. it's not Epic per se that's the problem it's all EMR software, if you think Epic is bad you should see the competition, they're even worse. I'm not sure that second one is really such a good excuse, but, that was what I remember hearing.)
  • m3047 1mo ago
    A close acquaintance was on Medicaid, and then got a new job and was moved off of Medicaid onto an insurance plan they were paying for. Medicaid is administered by insurance companies; the same company administered both their Medicaid plan, and the plan they were now paying for. As it so happened, within a week of this occurring they needed urgent care, badly, no joke. We have basically three choices here (at least, which would take this insurer), and none of the three would see them, and the reason was the same in all cases: 1) they no longer had Medicaid, and 2) the provider couldn't let them pay cash and sort it out with the insurance company themselves. It took three days calling the insurer, providers, the State health exchange, finally getting the insurer on the phone DIRECTLY with one of the providers... at a clinic rather than in admin... the insurer directly telling the clinic administrators that the person was insured and the insurance company would give them a claim number right now, or something like that... before we could get them in to see a doctor. When we got to the clinic they looked them up and STILL told them they couldn't see them we had to demand to speak to an administrator and basically THEY COULDN'T CHECK THEM IN TO THEIR APPOINTMENT in their computer. All of these providers used Epic. I made some additional phone calls and had some additional conversations, made a writeup, and sent it to the insurer, the benefit exchange, and the provider who ultimately saw us. Never heard anything from anyone.
• frabcus 1mo ago
  Just a general pitch - please everyone use LLMs more to fix bugs and polish software to make it better for users. It feels like too much of the benefit from it has been optimising, rushing new features/markets, tripping over ourselves with new processes, vibe coding things just for ourselves. When maybe it could actually make things better for most people using software in their daily lives.
• gregates 1mo ago
  > On the topic of Michael's comment, I think it's easy for programmers to not notice ads. Almost all programmers I know use an ad blocker and, in real life, their eyes seem to just skim over ads and not notice them. How do you write this article and not notice that this should be the topmost example of people adapting to buggy software that doesn't at all work for its users without workaround cognitive hacks?
  • inigyou 1mo ago
    Banner blindness has been studied since a few years after ad banners were invented and advertisers started getting pissy they didn't magically triple their revenue, heh
• theginger 1mo ago
  What I see a lot is working with developers who believe the goal is to write software that can complete the task. They demo it, release it and watch it immediately fall apart with first contact with the user. What they should be doing is having a goal of software that cannot fail to complete the task.
• crabbone 1mo ago
  > Who else uses the Shift key to end the screensaver, because in case the event goes through to an actual program it's least likely to do have unintended effects? Hahaha. Yup. That's me :) Not the screensaver in my case. I leave my desktop "suspended to memory" overnight, and when I come back in the morning / afternoon, to wake it up I press the Shift key. But, more on the subject, I kinda find it disappointing that the post doesn't try harder to analyze why this happens to the developers. The explanation doesn't feel satisfactory to me. This was my experience working on a product that was virtually universally believed by its programmers to be of good if not excellent quality, while, in reality it was atrocious. Just to give you a taste of the quality: Jenkins landing page didn't work because it would take too long for it to load and various timeouts that happen when it fails to load would kick in and just mess it up so much it wouldn't have been useful anyways. Jenkins tests were generated from some horror-show templates written in YAML (some RHEL tool, forgot what it's called) and because there was no other way to test what the template generated other than to deploy the new test into the actual Jenkins server, the server was full of dysfunctional "orphan" (no longer tied to any template) tests that were never deleted. The only way to navigate to the test results of the job you were interested in where to memorize the way the templated name would expand into the URI components of the Jenkins job URL, have some other test results bookmarked, and then modify the URL of the bookmarked page to get the URL of the job you want. The CI/CD team, however, decided to combat this situation by developing their own server which collected data from Jenkins and displayed a table with the most recent results for select jobs. Green and red being used to indicate whether the job succeeds or fails, the table was mostly red most of the time, with some jobs being continuously red for many months. Initially, I was hired into CI/CD team, but when I remarked on the desperate state of events in CI/CD department... they wanted me fired, but the company was going through acquisition and they wanted a higher headcount, so, they kept me, but transferred into the least relevant department where I would be as useless as possible: the quality control! My life as SDET (because QA is a curse word nowadays) exposed me plenty to the situation described by the author. The aspects that the author didn't touch on is that programmers working on such a product that I've experienced a lot are: * Unwillingness to accept that a large proportions of the product is bad. People have this intuition that some parts might be bad. After all, that's why QA exists: they find a few things, things get fixed, and everyone moves on. And this is how it works in passable quality products. But the situation when everything is on fire and is going to hell in due course sounds alarmist to the people who are on fire and are going to hell in due course. After a certain amount of complaints, all further complaints are dismissed. * Unwillingness to accept the existence of strategic mistakes. The QA simply is not allowed to voice their opinion on product or feature design. The only way a tester can initiate a fix is if they can create a test that illustrates the problem. Saying, for example, that "our error reporting is bad because it's useless to the customer and it cannot be meaningfully reported back to the developers" was dismissed as "nothing to do here" (but, actually, meaning: it's above your paygrade). I don't believe either of these would've been fixed by "simply pointing out the bug", as the author claims. Our industry came to a particular way of doing things that are pathologically bad. The way QA works is OK-ish, when the product itself is of an OK-ish quality. When the product is really bad, the QA is powerless to initiate a fix. QA isn't trusted enough, and, usually, is perceived as a liability, and furthermore, stuffed with engineers nobody else wants. Unless this is changed, the pathologically bad products (like the Blackboard) will have no hope of ever improving (eventually, they will just die either under their own weight, or replaced by something else).
• amadeuspagel 1mo ago
  > Almost nobody objected to my characterization of Google and Bing search results, but people told me that I was wrong about Kagi. Paying for a product makes you defensive, especially if there are free alternatives.
  • chrisjj 1mo ago
    More significant I think is paying for software indicates you are more selective - inc. against defects.
• javascriptmick 1mo ago
  I once asked my brother in law (a mechanic) to help me look over and buy a new secondhand car. The car we ended up buying had good fundamentals, low cost, good brand, big trunk, high top speed. After owning it for a while, I came to learn that it was not a great car. Things constantly broke and the repairs cost me more overall than the cost of the car. A complete disaster. I came to realise that to a mechanic, little problems like an old fuel pump or poorly maintained engine were "easy" problems to fix. To my brother in law, what mattered was the low price and the fundamentals. Repairs, to him, were easy. To me (not a mechanic) they were expensive and inconvenient. I think, for a developer, problems with software are a bit like this. Little things that are easy to fix can be overlooked because the grand design of the system is very clever or it has some advantage over other software like handling a particular file format, or processing a high volume of transactions. Personally, I find it very difficult to sit down and expend the attention and effort to really look at and test my own software. I think because every little issue that I see becomes another job, another hassle, another delay in releasing. Maybe thats my "Bug Blindness", not sure if it's the same.
  • lukan 1mo ago
    That is the reason why too many nerds recommended Linux as a "easy" windows alternative. What for us is easy to fix and often not even worth thinking about it, is impossible for a normal person.
    • dcminter 1mo ago
      Maybe? I think you may be underestimating how many papercuts of the same kind are there on Windows and on Macs. They're just harder to see when you're used to them.
      • lukan 1mo ago
        Having giving support with windows and linux - I don't think so. Recently things got way better with hardware support - but just making a printer work, used to be a unsolvable problem for my dad for example, who has a electro engineering background (but doesn't speak english, and error messages in linux are very seldom localized). In windows he put in the CD that came with the printer and it worked.
• Hl1b 1mo ago
  [dead]
• weinzierl 1mo ago
  That is something that should be obvious to any developer who worked with a real QA-team or person. They just have a different mindset. The problem with contemporary software development is not only that often the majority of QA work is shifted left (meaning to the existing devs) but also that the developer mindset is contagious. Have QA-people, who are usually in the minority, work too long and too closely to the devs and they become blind. I worked in V-model teams where the only communication between the development team and QA-team was supposed to be the spec. I still think that is the best way to develop software that works.
• janpeuker 1mo ago
  I agree quality blindness is curable. Many communities (e.g. Japanese, Swiss, Yemeni, Peruvian etc) have shown attention to detail is just a learning and, most importantly, social status process. Bugs are just the opposite of caring, and caring is at odds with hustle culture. I think Apple is a great example here - used to be meticulous and now every day the amount of tiny defects is just infuriating (just now I realised, for example, that Photos can't scroll with a mouse).
• elharo 1mo ago
  I also see bugs others, especially developers, are blind too. I've wasted I'm not sure how many hours reporting bugs to unresponsive companies and teams. Often the problem is not only that the developers cannot see or believe the bugs, but that there is no channel for reporting them. Even many open source projects resist receiving and addressing bug reports submitted by users. Commercial companies actively shield developers from users to the point where 9-figure customers have to escalate to a VP (who they can actually talk to because they're a hundred-million dollar customer) to get action on a serious bug affecting them, instead of just emailing the SWE 3 who's ultimately going to make the one line fix after the message gets passed down through many layers of emergency meetings. When I worked at Google, it was at least possible to report bugs internally with some hope they would be addressed. Sometimes you could even fix them yourself, given enough time and the relevant skills. Bug bankruptcy was still a thing. Teams would simply throw away all the SWE-years that had gone into documenting and reporting issues in their systems. But there was some possibility you'd get action, at least if you were a squeaky enough wheel and used the right back channels. But now that I'm outside the plex, there's basically no mechanism to report issues unless you're a tech vlogger with a large following inside Google or a >= $100,000,000 customer. Most other companies are much the same. They're not just blind to bugs. They're deliberately putting bags over their heads to keep from seeing what users are telling them.
• bariumbitmap 1mo ago
  One of the things I love about reading a bug report for a bug I've experienced is the feeling of solidarity it gives, a sort of "wow, me too, I thought I was the only one". I immediately recognized this issue, for example: > when opening a new Google Doc, I used to immediately put the title I wanted into the doc. At some point, maybe ten years ago or so, 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, so I now have this habit where, after opening a Google Doc, I do something else and then I change the title. I seriously doubt Google is going to do anything about this behavior, though.
• hakesson 1mo ago
  I've had to live with shipping software with really poor quality that had loads of small bugs. My Product Manager forced me to. However, at the end, the customers seemed happy, and I have to admit that I was partially wrong. The QA guys flushed out the big bugs and many of the small ones. Without any proof, I imagine something like 99% of the customers would hit only a few bugs, that they are used to compensate for (reloading pages etc), leading to a view of the product as having good quality. I was wrong: the sw quality is poor, but the percieved quality is good. I would of course prefer to do sw of much better quality.
  • mystifyingpoi 1mo ago
    Matches my experience. I think that 98% of the people that used our software were using only 2-3 battle-tested happy paths, and just never hit any bugs, not because there weren't any (there were hundreds of bugs in JIRA spanning 3+ years of development) but simply they didn't trigger the non-hot code path ever. The software was crap, but it made money, so it wasn't crap.
• fireflash38 1mo ago
  I think having my career be started in testing has broken my brain. Having seen so many different failure scenarios, it makes actual development difficult. Failure handling in particular is exceptionally difficult, especially when you're hitting low level filesystem errors. If you can't write to the filesystem, almost everything you do in an embedded system will fail. So you can't undo a partial write. Your logging will probably fail too. A relatively big database (a tier 2/3 database) that I was using handled this in a really bad manner: it'd just segfault. Depending on when this happened you could get data corruption and never be able to open the DB even in read-only mode. It's one of the core principles of a database! And it didn't even do that correctly.
• ashsingh777 1mo ago
  [flagged]
• stephenlf 1mo ago
  Asking others for feedback is absurdly powerful.
• jartan2002 1mo ago
  [flagged]
• jobuildsstuff 1mo ago
  [flagged]
• 1970-01-01 1mo ago
  >Almost nobody objected to my characterization of Google and Bing search results, but people told me that I was wrong about Kagi. 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 (e.g., for the seasonal forecast query, the search failed to return an up-to-date seasonal forecast) and was full of SEO spam. In one case, a person passed me both their list of Kagi filters as well as the search results they got without making claims that the results were good or bad, but people generally insisted the results were good even though the results both failed to link to a useful result and were full of spam except in cases where the user did something like pin GitHub to the top of their results, which worked for the queries where the goal was to download software that's hosted on GitHub, but of course completely fails for the other queries from the post. This deserves to be a separate post. Kagi would be great if it were 10x less expensive. For the price that is paid, the very first click should deliver the answer or most relevant information to the search with five nines accuracy. Clicks that require a user to perform more digging or are simply rejected as spam should come with some SLA of 0.0001%
  • hilariously 1mo ago
    Have you ever done anything wrt search? What you ask is basically mind reading.
    • 1970-01-01 1mo ago
      Google made it work from 1999~2006 before SEO was a thing.
      • topaz0 1mo ago
        Unfortunately we won't get a chance to see whether kagi could make it work before SEO was a thing, so this isn't a fair comparison. (Not defending kagi necessarily, I've never tried it, no opinion on how it fares on today's Internet but comparing it to how 1999 Google did on the 1999 internet is absurd)
• deleted 1mo ago
  [deleted]
• deleted 1mo ago
  [deleted]
• generationP 1mo ago
  Those habitual mitigations go a long way. Just like there is defensive programming, there is defensive usage. Under Windows: Don't put your files into "My Documents" or similar folder hierarchies; you never know if old software will correctly deal with the abstraction. Working with files in general: Avoid nonstandard unicode names or long paths so your external hard drive doesn't choke on them. Avoid case sensitivity even when it is allowed on Unix systems, since you can't assume Windows won't ever touch them. Avoid whitespaces in names because sooner or later, some script won't escape them. On the internet: Never draft long comments in the browser; always use a local text file. Anything can happen in the browser. In games: Never save your game during what looks like a complex scripted scene even if the game does allow saving. Using search engines: Avoid keywords that are likely to confuse/distract the search. With dropbox-likes: Give it some time to sync even after the icon is green; god knows what is being predictively shortcutted under the hood. Everywhere: Restart the program or system if certain signs of corruption appear. You don't know what's going wrong, but you know something is, and barring some unusually careful compartmentalization, a piece of software is still a state machine which, once it has strayed from the right path, cannot be trusted at all. OSes nowadays are adapted to this, but much of software is not, and you do not want to have it corrupt your file.
• tonymet 1mo ago
  there’s a general dismissive attitude with these bugs. When you report them, customer service responds with incredulity, and continues to explain that’s how the software is supposed to work. CS has been trained to close conversations, not to resolve issues. I’ve reported critical issues with my bank where the accounting was broken, money was missing, transfers were inconsistent. Customer service loves to explain “well that’s just how the system works”. Sorry no, the system has failed. It’s an accounting system, and by definition needs to be accurate, or at least report an error if it can’t remain consistent. The same standards that would fail an interview are completely ignored for paying customers.
• kaiji1126 1mo ago
  [flagged]
• deleted 1mo ago
  [deleted]
• IshKebab 1mo ago
  I want to use some of this guy's software to see how amazingly bug free it is, lol. This is weapons grade hubris & probably autism. Although I do have to agree with him about Linguist. I also have a PR that was reviewed and then just never merged, despite multiple very polite prompts over several years.
• MetroWind 1mo ago
  Lmao I thought it was going to be an article discussing insects' ability to see.