RuneScape is a popular MMORPG that reached its peak popularity in the late 2000s.

In the game, combat – colloquially known as PvP, or player vs. player – is limited to a specific map area (called the Wilderness) and otherwise people’s houses.

On 6/6/6 (sic!) a bug in RuneScape made it possible for a few players to start killing others outside of designated areas, without them being able to defend themselves. One of these players, Durial321, gained a lot of notoriety:

A player called Cursed You had invited some friends to his in-game house once he had maxed his construction skill, but decided to eject them all from the premises. Things turned sour, however, as a group of players marked as PvP in the house didn’t lose this PvP flag when ejected, allowing them to storm through Falador and massacre whoever they pleased. The most notorious of these players was named Durial321.

This event went down in internet infamy and meant that many players lost their items when killed as well as the banning of those involved.

I don’t have any context of RuneScape and I found it really funny to learn about this event from different retellings of the story.

This wiki entry reads almost as journalism:

Several others were able to use this glitch, but Durial321 abused it the most. His rampage lasted for about an hour, starting at Rimmington, where the house party was, then proceeding to Falador and subsequently Edgeville. At Edgeville, he gave Voodoolegion the green partyhat, who never gave it back to him. Soon after, he finally encountered a Jagex Moderator, Mod Murdoch, who disconnected him and locked his account. Durial321 was later permanently banned from RuneScape. In a 2006 interview, he said that player killing outside of the Wilderness was exciting, although he felt bad for the players who lost their belongings.

The 2006 incident later became known as the Falador Massacre.

(The tone is even more funny if you actually read the interview.)

There is also this more modern retelling that feels like scary story time by the campfire:

Reactions from players were initially kind of incredulous. Plenty of people were shocked and found the whole incident quite funny. Durial had essentially broken the game, after all. Some players wanted to be like him, whipping strangers to death and taking their items. But soon, as more players started hearing about what had happened and seeing the video, the mood shifted. Players wanted Durial321 hung, drawn and quartered, with his head displayed on a pike outside Lumbridge Castle.

You can witness the event PC Gamer called “one of the best all-time MMO bugs” by yourself since there is video capture of the Falador Massacre taken by one of the witnesses. At least to me, it’s rather incomprehensible.

Fear not, however, because there are many (!) documentaries. This recent one is reportedly the best one and also goes into the technical details:

Without spoiling too much, the bug was a classic Swiss cheese situation involving a new untested item, a race condition, peculiar timing, and a player with an unusually high uptime and a whole lotta luck.

An interesting crowdsourcing effort from Mimestream that asks users who want snoozing to pick up a phone and dial their representative put pressure on Gmail to add that feature to the API.

I wonder how much of a chance of succeeding this has. The issue has been open since 2018, and was reopened in 2023. It has over 5,100 stars. Those dates seem old and the numbers seem huge, but I don’t have a full frame of reference. Casual search shows there are only two more bugs that have been starred by more people.

I feel macOS these days starts feeling like Windows in the 1990s where occasionally some core component of it breaks, and a reboot is necessary to restore it to full functionality again.

But even with that in mind: this happened literally right after the reboot, with nothing much happening and no other signs of the system in distress.

It’s hard for me to even understand what would make this kind of thing pop up. Trash feels like one of the core tenets of a GUI – like undo, or copy/​paste, or windows gaining focus. You don’t expect it to just… stop working, especially with a circular error message like the above.

I think a lot about bugs or design decisions that make software appear dumb.

At some point in my career I started fitting everything against two principles: “don’t make your app treat your user as if they’re dumb” and “don’t make your app itself feel dumb.”

To wit:

This is, very obviously, my website. I have made it from scratch. I have visited it a million times. And yet, at some point my friend Noah shared a link of it with me, so now Safari occasionally announces that with glee when I check it out.

Me having visited something many times should outweigh someone sharing it with me once.

There is a close box here, although you have to hover over the bar to see it. (And, after closing, it seems to come back after a few days!) I can also right click and choose Remove which does… absolutely nothing.

I believe this whole feature is called Shared With You. Elsewhere, on occasion, I find it useful. But its tentacle right here makes Safari appear just… kinda obtuse.

Also, speaking of obtuse: Can you spot a grave typographical mistake I made on this screenshot? (I already fixed it in production.)

I was embarrassed for Apple when I saw the recent bug fix for columns introduce a new bug, explained in this post by Jeff Johnson:

Without the path bar, the columns are now taller, but the vertical scrollers remain the same height as before, leaving vertical gaps, a ridiculous amount of space between the bottom of the scrollers and the bottom of the columns, looking silly and amateurish.

It’s impossible to talk about craft without talking about embarrassment, and pride, and shame, and lust, and a lot of other words – all tricky to describe, all fluffy. So, I tried to interrogate my feelings.

First, it was embarrassing that it broke. I’ve been there: you build a complex system, and forget about some lesser-known state. That’s why it’s important to invest in whatever it takes to shine a light on those states: quality assurance, automatic screenshotting, tests, and so on. Sometimes it’s simple hacks – like half of your team having scrollbars visible. And when you notice a bug, you try not to just fix it, but to rebuild it to be stronger (“leave the campsite in a better place you found it”) – be it by fixing the cause and not just the symptom, adding unit tests, changing practices, and so on.

But it also felt embarrassing how it broke. It feels clear there’s some manual calculation going on somewhere, and someone forgot to add this new change to it. One of the tricks I learned over time is that a well-designed system designs itself, but it takes effort and imagination to make a system resilient in this way. Here, if there was some abstraction of “adding stuff to the bottom,” then you wouldn’t have to worry about adding extra math. The system would take care of itself in many of these corner cases you will forget about.

I don’t want to shame (see, that word again!) individual people at Apple because I don’t know if it’s the lack of talent, or the whole system being wired in a way that doesn’t reward forward thinking or the kind of invisible work that needs to happen in those spaces. But the embarrassment should be there – if it doesn’t exist inside Apple, then that’s perhaps the sign of a real problem.

• The UI for filing bugs is inscrutable and has too many hoops to jump through.
• No one does anything unless every field has been filed meticulously and there is a clear repro.
• The designer is ridiculed if the thing isn’t actually a bug, is a duplicate, or if it was filed in the wrong place.
• Front-end bugs are automatically “minor” or “nice to have”s without listening (as there is no loss of functionality, and no data loss).
• The designer is always responsible for stating how it should work, without being able to say “I am not sure why, but this started feeling off and it’s in an important place. Can we investigate?”
• “This is as designed” is an automatic conversation ender.
• The tiniest of external reports, social posts, or blog posts, immediately are prioritized higher than in-house experience.
• Once every few years, a designer gets 20+ demotivating automated emails saying 20+ bugs they filed over the years have been closed automatically during a purge, without any word of explanation.
• Simple human touches like “thanks for filing!” or “nice catch!” never enter the picture.
• Engineers never file design bugs themselves.

If you’re an engineer, I can sense you might be getting frustrated, as most bullet points I listed look like extra work. I agree with you. It is. This post is as much about process, as it is about culture and the incentives it establishes. The best places I’ve worked were filled with shared trust and treated bugs as a joined responsibility of everyone, rather than a black-and-white division into “filers“ and “fixers,” with the ultimate end goal always being user’s experience – nothing else.

I also understand this dives right into an age-old tension between manufacture and craft. Bug-fixing processes have to be well-oiled bureaucracies with very specific rules so that they don’t turn into a pile of vibes and Brownian motions. But design (and, by extension, a lot of front-end) doesn’t work like that. Design needs room for taste, for careful exceptions, for escalation of immesurable things, and for a certain flexibility in even the basic definitions.

If it’s a tiny, but embarrassing bug, or a flow killer, or a thing that bothers your most valuable group of users, or something appearing in a well-trafficked place – it is no longer tiny. If it’s working as intended, but it feels buggy to the user – it ought to be a bug. If it’s a long-standing bug, it should be considered as cumulative damage already done, not “oh, this has been like this for a long time, no one cares.” If there’s a shaky repro, but the bug feels important, you need to work from principles or analyze the code. If it’s something no one mentioned externally (ergo: why fix it?), consider a lot of bugs rankle but never get reported, particularly if your company doesn’t project an external presence of caring about feedback and acting upon it. cough cough Apple cough cough cough cough cough dies coughing

Of course, designers have responsibilities in the process also, among them mutual respect and understanding of engineering, clarity of communication (particularly about things that are hard to reason about mathematically), seeing patterns that could be grouped into bigger bug bundles to make fixing more efficient, (occasionally!) helping figure out a fix if the obvious fix isn’t available, and shared understanding with their team about what actually matters. There is always a thousand details that could be better, but for every thousand only a hundred might actually be worthwhile. Flooding the bug process with irrelevant minutiae that won’t realistically ever be fixed is not very helpful.

This is the only way I know of to capture the full spectrum of bugs that ruin software – from front-end to back-end, from visual/​interactive quality to works-or-not functionality, from what can be measured to what never will be. And this is not just about designers, of course. It’s not even about any non-engineering function. Design serves everyone; if your bug-filing UI or your process or your definitions are not well-designed or -balanced, I strongly believe you’re also hurting engineers on your team. And you’re definitely hurting your users.

This 9-minute video from the fun game show Lateral (with Tom Scott!) covers a particularly interesting bug in the 1984 game Karateka:

If you don’t want to watch the video and try to figure it out alongside contestants, you can read more about it here, and also see it in action.

Karateka was made by Jordan Mechner and I bet his name will come up again.

This is a really funny story happening in the online universe of Final Fantasy 11:

Once killed, a notorious monster shouldn’t respawn until after the next monthly tally, but lately defeated notorious monsters in Limbus have been reappearing early. That’s because, Square Enix said, “the server-side data recording the defeat status of notorious monsters is unexpectedly being cleared.”

Thus, there’s only one way to guarantee no players are robbed of hard-earned Limbus loot: Square Enix is dispatching Game Masters to personally murder every notorious monster in Limbus so the FF11 servers can properly verify that they’re really, truly dead.

“To achieve this, Game Masters will visit each World in sequence and defeat each motorious monster individually,” Square Enix said. “We apologize for the inconvenience.”

I know this is not a bug fix per se, but it’s interesting to be doing some bug cleanup from the inside.

A nice counterpart to my post from a few days ago – a 5-minute video by philive of more kill screens from various classic arcade games, with simple explanations.

I liked the angry website Bugs Apple Loves because it’s hitting on something that got me worried in recent months: Apple has been bad at bugs for a while now, but we might be overfocusing on giving them crap solely for some of the most visible – even visual – Tahoe stuff.

This is a condensed list at the time of writing, as the site itself doesn’t make it easy to see it:

• Mail search doesn’t work
• Autocorrect won’t take no for an answer
• Apple Pay: card icon changes address
• Google Contacts sync is a black hole
• AirDrop: Looking for devices...
• iCloud Photos: ‘Uploading X Items’
• Spotlight: ‘Indexing...’
• Personal hotspot won’t auto-connect
• Apple Watch widgets won’t let go
• iOS text selection is pure chaos
• AirDrop shuffles targets mid-tap
• macOS 26 window resizing doesn’t work

There are themes here: “the interface doesn’t remember my preference,” and “things move around as I interact with them,” and “some process gets clogged up,” and “a thing gets stuck and doesn’t respond to interface actions.”

What I appreciate about this is that none of this is very “visible” stuff, but the insidious things that add up and bother on the daily basis, chipping away at your flow first and sanity second – which the site tries to quantify via a formula:

I think this is really interesting, even as a satire.

I found it’s really hard, if not impossible, to justify design or experience bugs using the same frameworks as other engineering bugs. As Mike Swanson wrote: “You cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another […] pop-up.”

A lot of it is utterly subjective. Various small frustrations add up in non-linear ways. A lot of it doesn’t subscribe to binary “data loss or not” or “does it function or not” classifications. A lot of it feels heavy to fix in terms of context switching, so it’s timeboxed and then discarded when the time box overflows.

I have seen engineers say “Oh, it’s a long-standing bug, it’s been like this for 3 months” as a justification to deprioritize something, while to me it feels like that should be an accelerant. The users have already been suffering for 3 months!

So maybe metrics like these could actually help? Quantifying at least the blast radius (affected users + usage per day) seems valuable, not to mention the embarrassment of seeing something like “9.1 years unfixed by Apple.” (And yes, internal embarrassment and shame should also be a metric.)

This would be harder to do for creators of the site, but easier inside Apple: I would also try to quantify vocal user frustration. One of my tricks when thinking about bugs has been “Notice when your users are really angry about invisible stuff.”

…for example someone going on and on about Finder.

If you plug in a CD drive (he said with a straight face in the lord’s year 2026), and then eject too soon, the system offers this dialog, which allows you to say: Eject whenever you’re done with whatever you have to do.

But more modern media, like SSD drives, don’t show that window. The best case scenario is that you get a dialog box like the 1990s never ended:

It gets worse. Often, you get zero help in identifying what the “programs” actually are. (The word on the street is that it might be stuff like Spotlight indexing, which you can’t really control.)

More often than not I just click Force Eject or jank the drive cable out, which feels really unpleasant. I would guess many people do the same.

So at this point we are two steps worse than the original CD experience, which… wasn’t even that great! A pretty clear improvement on this already exists elsewhere in macOS, and could be reused here – “hey, you don’t have to do anything, just give me a second while I finish up here.”

(Can’t help but notice the discrepancy of visual styles of these windows, and even the inconsistency between calling things “applications” vs. “programs.”)

Reported to Apple as FB21787458.

I’d guess a lot of people know that the original 1980 Pac-Man ends accidentally with an iconic, glitchy, and impassable “kill screen.” Many people will also nod with recognition at hearing the kill screen is level 256, a number that immediately gives some ideas on what might have happened.

But this fun 11-minute video from 2017 by Retro Game Mechanics Explained doesn’t stop there. It shows, step by step, exactly what is going on when you reach level 256, and how each one of the glitchy things appear on the screen.

It’s a little mesmerizing, like watching a building demolition in slow motion.

Found listening to this 2-hour episode of The Talk Show podcast with Daniel Jalkut very enjoyable, and more thoughtful than just “bitching about Tahoe.”

One particular thing that stood out to me was a discussion of shame and embarrassment and pride that all come with shipping software. And looking to Apple itself for direction that the company is not really providing, as many of their apps are not using the new Liquid Glass interface – or when they do, they use it in ways that are inconsistent or disappointing.

Some other good themes:

• it’s okay not to change something if the alternative is change for the sake of change, a posture Apple’s hardware team feels more comfortable with than Apple’s software team
• internal Apple politics and the story of the Control Strip
• loved this phrase from Gruber about the macOS’s Tahoe release: “they vandalized it.”

Also, this:

A fair criticism of Apple over the years is that sometimes fixing 50 little misaligned text boxes or divider bars… using your time to do that, is time better spent than adding another user feature.

Fun little story by Bruce Horn on folklore.org about the original Mac and how modes are sometimes good:

We went to quite a few stores in the week or so after the introduction, and found that, without exception, every Mac’s floppy disk had a garbage name! They were all named something like ”;lkakl;rt;klgjh”, as if someone had just randomly typed characters to see what would happen. Which is exactly what they did.

In the Finder, the startup disk would appear on the desktop, in the top-right corner, ready to be opened. The Finder would initially select it; once selected, typing would replace the current name, following the modeless interaction model that I had learned in the Smalltalk group from Larry Tesler. This meant that whatever anyone typed when they first came up to the Macintosh would end up renaming the disk.

On the early Mac, just typing with any item selected renamed it, which caused all sorts of trouble.

The eventual solution for renaming that survives until today was: click to select and then click again to rename… but don’t click too fast, because that’s double-clicking, and that means something else. Windows, starting in Windows 95, did something similar, but also put rename under F2 – so at least you didn’t ever have to wait.

I liked the emergent behaviour from some graphic apps which put rename under ⌘R. It’s not that hard to make Finder work that way – see below – but I have always been curious why Mac or Windows didn’t steal this solution.

(Added later: People reminded me that of course Enter also renames, and does so immediately. I wonder why it slipped my mind in this context – possibly because in any other list or similar place, Enter would be the equivalent to opening? Maybe I’m discovering in slow motion how unusual Finder can be in its details compared to conventions we established after.)

I have been thinking about this a lot since the pandemic, and Rob Napier on Mastodon summarized this really well:

I spent a lot of time in the 90s working on Y2K. It wasn’t a huge panic. It was just a slice out of everything else we spent auditing code. It wasn’t “spend 80 hours a week fixing this.” It was just boring. Incredibly boring. And we made it be ok by being bored and fixing stuff.

And the one thing I never thought would happen was that people would say it was never a problem. Oh good grief, it was a problem. All over. We just fixed it. Like we thought grownups should do when there’s a problem.

There are some good responses to the post and the original post it quoted. This one was brilliant in its vulgarity:

My analogy for this is that I work to maintain a kind of public sewer system. You never think about sewers... until you’re up to your neck in shit.

This isn’t just about Y2K and COVID, of course. It’s also about the invisible work of people who make well-behaved menus, and all the other things like that.

An absolutely fantastic post about software nudges and pop-ups by Mike Swanson:

If you’ve ever read about “choice architecture” and nudging, this will feel familiar. The modern language for it was popularized in the late 2000s, and the core idea is simple: how choices are presented changes what people do, even if nothing is technically forced.

Then product teams go one step further. Instead of just shaping choices, you can shape timing. Prompts start showing up in the middle of workflows because that’s when the user is “most engaged.”

The industry also has a whole discipline around persuasive design and how to move someone from intention to action with prompts, friction removal, and well-timed triggers. B.J. Fogg’s behavior model is one of the more cited frameworks in this space.

Some nudges are genuinely helpful. But the same machinery that helps you discover a feature can also be used to push you into something you didn’t come here to do. And once the machinery exists, it gets reused.

I am finding myself wanting to quote most of it.

You cannot easily measure the resentment. Or the rage clicks when they smash a button to dismiss another “did you know” pop-up. You cannot easily chart the moment a user thinks, “I used to like this product, and now it feels needy.” You cannot easily quantify the slow erosion of trust.

I have long been frustrated by how the “growth” interfaces haven’t really evolved past cheap and loud pop-ups and defaulting to “let’s just show it.” One of the behaviours that bother me a lot that’s not listed in the post is, for example, installing an app and receiving one or even more “here’s what’s new” onboarding callouts. Hey. I just installed you. Everything is new.

Anyway, maybe one more quote:

Optimize for trust, not just return visits. Short-term engagement can be increased by annoyance. Long-term loyalty is harder and more valuable. The best products I use don’t constantly remind me to use them. They quietly do their job so well that I come back when I need them. That’s what tools are supposed to do.

Worth reading the whole thing.

A wildly fascinating 12-minute video from the always-hilarious YouTube channel Map Men about the reason for a surprising black spot that could be seen on Google Earth until 2012.

Reading the Wikipedia entry after watching the video adds extra color to the mystery, turning it more squarely into a “software quality” story:

Some scientists were initially skeptical that such an error could exist, since a signature was present in various global terrain data sets, such as the bathymetric data from the General Bathymetric Chart of the Oceans, which reported an elevation of 1 metre (3 feet) over the location of Sandy Island. Some data sets derived from satellite imagery indicated that sea surface temperatures were absent in the location, suggesting the presence of land.

I saw this screenshot the other day (link):

I never particularly liked those “cute” app updates that were all the rage some… 10 years ago? Or app updates that are too generic. I always felt the updates should be informative, and I occasionally like seeing what’s actually being fixed, and sometimes learning from it.

The post above is about a game called Dwarf Fortress that I have never heard of, despite it going on since 2006. In that game, actual descriptions of bug fixes often feel better than those creative app updates. Some examples:

• Zombies start conversation with necromancer adventurer who tries to sleep in their house
• Cats dying for no reason - alcohol poisoning?
• Giraffe is trainable for war
• Added mouths

PC Gamer some fun ones in 2016, or you can just go to Dwarf Fortress Wiki and explore on your own.

The game seems fascinating, by the way.

Speaking of hardware: Always loved this 1998 Australian story (magazine scan or an easier-to-read transcription) of a very particular computer virus that did not require any software to spread “like a Sydney bush fire”:

Now it all became clear. One of the female sockets must have deformed when I first reconnected the CD-ROM burner. This forced the two pins into the same hole and shorted them out. Later when this cable was plugged into the JAZ drive, the pins, now bent to go into one hole, deformed the female connector on the JAZ drive. Again pushing the separating plastic over the hole. Plugging another good cable into this newly damaged socket caused the pins of the new cable to be forced together and short, and when this new cable was inserted into the good SCSI socket on the new JAZ drive it did more damage to it. Before I knew it I had four damaged sockets and three bad cables.

I believe the cables and sockets looked something like this:

The story ends with:

I am only glad the [hardware] virus was contained and did not spread to the rest of the world! Can you imagine if this sort of thing happened in a big computer assembly plant?

Turns out, it did actually happened at a computer assembly plant, in 1997.

A fascinating deep dive look at one of the most well-known bugs in computing history, the 1993 Pentium FDIV bug. Ken Shiriff actually grabbed a microscope to analyze the processor and mapped out exactly what happened on the hardware level, and the details of Intel’s (surprising) fix.

Also, an interesting detail of what ended up being Intel’s self-own:

The problem might have quietly ended here, except that Intel decided to restrict which customers could get a replacement. If a customer couldn’t convince an Intel engineer that they needed the accuracy, they couldn’t get a fixed Pentium. Users were irate to be stuck with faulty chips so they took their complaints to online groups.

When home computers were new, there was this enduring myth of “killer poke.” POKE was a pretty low-level BASIC command that allowed you to write any number to any place in the memory, as there was no memory protection. From that developed a set of myths of the right magical pairs of numbers that could be input and cause permanent damage to the hardware of the computer, shared in nerd circles almost like campfire stories.

Wikipedia has a pretty dry set of those. The most exciting one there is annotated with [citation needed], and the message seems to be: by the 1980s, this was no longer possible. Even in the earlier version of this idea, Halt and Catch Fire, the “catch fire” was an exaggeration. Before then? Sure, I bet some user actions could damage the computer, but computers themselves, with their high-voltage vector CRTs, electromechanical parts, and even liquid mercury tanks early on, were not that hard to damage.

Unsurprisingly, there are more modern versions of “killer poke,” too. At this point, the best they can do is crash or hang your operating system, but they are still chased, and coveted, and mysterious.

This 10-minute 2021 video from Mrwhosetheboss is a fun story of a wallpaper that could crash your Android OS. I’m not going to spoil the surprise, but it’s not what I expected – although the moment you see the wallpaper in question, you might figure it out.

It’s a fun video, and of that good kind that actually teaches you something.

A 6-minute video from JHR about the 1980s British game Jet Set Willy, a big prize for its completion, the bug that made it unplayable, the copy protection, the hackers, and the mess of it all.

This appeared when trying to delete (even when trying to Delete Immediately, skipping the trash altogether):

Same thing right after, when trying to tag some existing items, for which I don’t imagine any new space should be necessary:

Also, why are these dialogs so different?

I feel like not so long ago there were literal books making fun of bad dialogs like these.

Reported to Apple as FB21509633.

I have never before heard of this story of an absolutely botched deployment of a new accounting system at the British post office, and “the widest miscarriage of justice in UK history.” More on Wikipedia:

Between 2000 and 2015, 736 subpostmasters were prosecuted by the UK Post Office, with many falsely convicted and sent to prison. The subpostmasters were blamed for financial shortfalls which actually were caused by software defects in the Post Office’s Horizon accounting software.

Some of these bugs sound absolutely horrendous, and remind me of Therac-25:

The Horizon IT system contained “hundreds” of bugs. Some of those that came to light were named after the post offices where the bug first occurred. These bugs included: the “Dalmellington bug”, where the system would enter repeated withdrawals in the ledger every time the user pressed Enter at a frozen interface screen; and the “Callendar Square bug”, where the system would create duplicate database entries in the ledger.

This bit feels absolutely crucial and it seemed to me we have learned this lesson decades ago:

And while the technology had changed, the contract between the Post Office and subpostmasters, who owned their own businesses but were agents for the Post Office, remained the same. It stated that any accounting shortfalls were the responsibility of the subpostmasters unless they could prove otherwise. But without the chain of evidence created by paper-based accounting methods, proving the losses were not their fault was near impossible for many.

You might not encounter them often in polished fonts unless you’re knee-deep into typography, but: fonts have bugs, too.

Paul van der Laan on Mastodon:

Did anyone ever notice that Avenir LT has some serious errors in the descender lengths of p and q in certain weights?

Florian Hardwig adds:

It’s one of the things that got revised in Avenir Next. But it’s bonkers that it hasn’t been fixed in the “legacy” Avenir that’s still being sold – and bundled with Mac OS – after all these years.

Downthread there’s an original Avenir drawing that for some reason I found very evocative:

Perhaps the only ever musical that’s about a buggy piece of software. From the inimitable Cabel Sasser, this 2006 video about Saints Row, with three songs and a goddamn reprise at the end.

It’s very good.

my car door’s freaking out
it seems to be forever in the concrete barricade
I wonder how I’m ever gonna drive away
this really is isn’t my day
the sparks are flying
people dying
metal frying
and I wonder if there’s more to life
or if I’ll find that this is really it
this game is a piece of work

A really fun 2021 story by Fabien Sanglard at the perfect-for-me intersection of bugs and typography.

In 1991, just days before the final deadlines, Akira Nishitani, one of the graphic designers of the absolutely seminal arcade game Street Fighter II realized they misspelled the world “Warrior” as “Warrier.”

The typo was there for months and no one noticed. But the moment it was noticed, the graphic ROMs were already burned and impossible to change, and the code was due in three days.

What would you do? I’ll let you click through to read, but I really enjoyed this short story.

An absolutely eviscerating 18-minute walkthrough of Apple Music for macOS Catalina, from a few years ago. More funny than anything else, but a reminder to test the “boring” edges of your app – like a state with a lapsed subscription, or coming back after a few months.

There’s no way to drag and drop. […] If I want to add this to here, I have to go through this bullshit, and when I do, it takes seconds again.

Also, an ode to a well-functioning back button, and well-behaving loading states. Those things add up so quickly.

(My debugging brain understood what populated the confusing History entries – I bet it was the early play sequences that went through a bunch of stuff without playing.)

Tom Forsyth wrote about a fun bug in a Half-Life 2 reissue, of a particular flavour I have never heard before.

So I started it up, selected new game, played the intro section. It’s a fairly well-known section - you arrive at the train station with a message from Breen, a guard makes you pick up a can, and then you have to go into a room and... uh... I got stuck. I wasn’t dead, I just couldn’t go anywhere. I was stuck in a corridor with a guard, and nowhere to go. Bizarre.

From Nina Kalinina’s excellent revival of a forgotten 1983 GUI, a discovery of a hilarious accessibility bug:

VisiOn loves to beep at the user. It beeps every time a menu option is chosen or an on-screen button is clicked.

If you are tired of the noise, you’d appreciate that Application Manager has an option to replace the sound with a “visual beep”. It is implemented as a flashing area of 32x16 pixels around the mouse cursor. Every time the flashing is about to happen, an image “below” the cursor is preserved in RAM to be restored after the “visual beep” is over. However, the memory allocated for this bitmap is never freed. It takes between 200 and 1000 clicks to fill the RAM with useless copies of the mouse cursor, and then the system crashes.

If you have never heard of VisiOn, The Digital Antiquarian has a fun walkthrough that also happens to be the first chapter of an excellent series about the history of graphical user interfaces.