Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bug Blindness

danluu.com

Post reply on HN
Print view View original

181–190 of 285 posts

Re: Bug Blindness

#181

Post by bryanrasmussen »

socalgal2 wrote: post #35

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 mention…

>I've run into the MacOS one mentioned, getting a black screen on opening the lid.

this is similar to what happens to me, if the screen goes dark to save battery and I move it to start back up too quickly, like within a couple of seconds, it will crash and restart.

So sometimes I see it is going to go dark and I move to stop it but it goes dark a microsecond before I touch the touchpad and then everything needs to start up again.

Re: Bug Blindness

#182

Post by lmm »

Tepix wrote: post #154
lmm wrote: post #100

Earlier quoted context omitted.

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.

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 ca…

> What's wrong with the following CSS snippet for example?

It doesn't achieve a reasonable readable font size which was presumably the goal. Your padding won't be the right size for all screens either. (And personally I hate excessive line height).

> respect the browser's default font size

The browser's defaults are also bad. But they shouldn't be. The browser is in a position to actually fix this; the webdev isn't.

Re: Bug Blindness

#183

Post by chrisjj »

meling wrote: post #64

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.

> It is well known that we can read faster with narrower text

Speak for yourself.

Font size is client setting, and there's where lies any bug.

Re: Bug Blindness

#184

Post by bariumbitmap »

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.

Re: Bug Blindness

#186

Post by Xymist »

eru wrote: post #132
atmavatar wrote: post #45

Earlier quoted context omitted.

> They’re smart enough 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…

> 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. In the 2010s Mathworks, the company that makes Matlab, had a policy that everyone started in frontline support. Including developers. (They probably still have thi…

The shaping isn't necessarily productive, though. My company has a policy wherein a the dev team are on a rota to assist the support team (and by extension clients) with technical queries. The net effect has been to make me hate customers with a passion usually reserved for opposing political regimes and childhood bullies.

Re: Bug Blindness

#187

Post by hakesson »

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.

Re: Bug Blindness

#188

Post by bariumbitmap »

encomiast wrote: post #5

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, i…

> the first example of a "bug" that the author could see, which others are blind to, was search results

The author explicitly says he is using less specific and compelling examples for good reasons:

> I don't want to give any specific examples where it was my job to see how well the thing worked because, even if the internal examples are meant in a constructive, blameless, way, they may not always read that way when re-posted externally, so I'll give a few less interesting and less well supported "random" examples.

https://danluu.com/bug-blind/

I also think it's reasonable to use the term "bug" in a broad or colloquial sense. If a web server is overloaded, that isn't a bug in the strictest sense, but it sure feels like a bug to the person trying to use the website. A search engine is software, and if it fails to surface the most relevant document from its index then I'd say that counts as a bug. Also the author acknowledges this SEO spam issue, e.g. in this quote for the linked post:

> Here's a fun experiment to try. Take an open source project such as yt-dlp and try to find it from a very generic term like "youtube downloader". You won't be able to find it because of all of the content farms that try to rank at the top for that term

https://danluu.com/seo-spam/

Re: Bug Blindness

#189

Post by fireflash38 »

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.

Re: Bug Blindness

#190

Post by [deleted] »

nextaccountic wrote: post #135
mcbishop wrote: post #50

Earlier quoted context omitted.

I love the UX-design book: Don't Make Me Think.

There's an idea in this book, that when using a mouse, smaller buttons are harder to click because you need to stop the cursor inside its hitbox, but moving the cursor to the edge of the screen is easy because it's effectively a huge button whose height is infinite (or infinite width for lateral edges). And hitting a corner is even easier because it effectively has both infinite width and height! This means that if t…

[deleted]
Post reply on HN