Bug amnesia is very real! As technologists, I feel it is important for us to cultivate the skill of noticing and remembering bugs, because the default seems to be that we apply all of our expertise and faculties to develop workarounds and then we internalize the workarounds and forget about the bugs. This is fine for lone-wolf tasks but leads to all sorts of mismatched expectations in groups.
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.
Something I really love about thinkpads is that they have that big blue "thinkvantage" button at the top of the keyboard, which is totally tacky 99% of the time, but! when you want to get to firmware configuration, you know what button to hit.
I've seen such a key on a Sony Vaio. The label was nothing but explicit, I actually had to look for help. But the button would turn the computer on, and get to the setup menu. Nice touch. Obviously, it was the only nice thing about this terrible machine but that's a different story.
Even if you don't intend to publish your list I highly recommend keeping a note of every bug you run into.
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
The iOS mail app has had the inbox bug for years, where it displays the unread messages app before it downloads the messages and sometimes retains it after the messages have been read.
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.
IMO, this post takes a left turn off the freeway when it segues into fuzz testing. Those are super effective, no doubt, but I've come to the conclusion that finding bugs isn't the hard part.
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.
My experience, is that finding bugs is the time-consuming part.
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.
In my professional SRE experience, you are an outlier. I analyze canaries on a regular basis for bugs. Like, the only thing lazier than fuzzing is using your customers to fuzz.
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.
> 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).
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.