One Week of Bugs (2014)
danluu.com
danluu.com
Installing linux is my go-to example. To the intuition of a typical technologist, it's a trivial and highly reliable task. Whenever I go through the exercise in TFA and force myself to actually pay attention to the places where I must apply expertise to work around issues that would otherwise be extremely difficult to navigate, I usually count around 5 showstoppers and a dozen minor bugs. Things like "the install instructions say to hold down F2 or F10 to get into the BIOS, but per the blink-and-you'll-miss-it BIOS info page it's actually F11 and if you actually hold it down the stuck-key detection ignores it so you have to spam-press the key instead." The world is full of these things and it's easy to lose sight of them if you don't force yourself to remember.
> and if you actually hold it down the stuck-key detection ignores it so you have to spam-press the key instead
Fuck this shit. How many pointless boots I triggered just because I could not manage to get the right key to be pressed at the right time? This is so pointless, so much time lost on this for nothing.
Just show the one key I should press at what time and give me feedback when you understood I wanted to do this.
Now my strategy is to spam the whole Esc + Fn keys row and delete, rinse, repeat until it computes.
He's talking about bugs that he encounters, using everyone else's software.
Yeah, this was written years ago, but it looks like things have not improved with age.
Once you're looking for bugs you'll start to notice them everywhere. I've built up a lot of habits around reloading and restarting various screens on my phone that were completely invisible to me until the list I was keeping caused me to start paying attention: https://twitter.com/bmc_/status/1309209159695388672
That said, some bugs in Music that I thought would never get fixed (they were there for years also), did eventually get fixed, so I can keep some semblance of hope.
One Week of Bugs (2014) - https://news.ycombinator.com/item?id=22094844 - Jan 2020 (5 comments)
Why is software so buggy? - https://news.ycombinator.com/item?id=15838200 - Dec 2017 (1 comment)
Dan even admits fixing them is the hard part:
> why don't you fix the bugs yourself? I do fix some bugs, but there literally aren't enough hours in a week for me to debug and fix every bug I run into.
Fixing them, is often relatively fast.
Crashes are good. If I can reproduce a crash, I can usually enact a fix fairly quickly. The issue is that "reproduce" part. For example, threading issues can be a bear. They might crash, once a week, and the crash dumps are near-worthless. I can often do better with a Ouija board.
I've always been a very good bug-fixer and problem-solver, but I've learned that the best way to solve problems, is to not have them, in the first place; so good design, and high-quality development methodology, pays dividends.
I write about my approach here: https://littlegreenviper.com/miscellany/testing-harness-vs-u...
One category of bug I file coming out of that is NullPointerExceptions. NPEs are always a bug, and they come with a stack trace and messages about which variable was null. Yet only about 10 percent of the bugs I've filed came back fixed. Often months later. The rest are either still open or closed without fixing in an effort to purge the backlog of old bugs.
Ugh. :(
I like to run on a "constant beta" basis. I fix every bug that I can find -even the small ones- immediately; halting work going forward, until they are fixed.
As you can imagine, this was not popular with my employers, so I was not allowed to work that way. Since leaving my last company, that's exactly how I've worked, and the results are nothing short of miraculous.
As a result, I actually had to dismantle a JIRA reporting system that I set up, because I get so few reports. A sticky note is usually all I need.
Without that context, some of the criticisms seem unfair (like Julia being version 0.3 and rapidly iterating; 4 years before its late 2018 1.0 release).