I can’t remember if I told the story before, but in the Before Times™ I opened a trading account with CommSec, the public brokerage associated with Australia’s largest bank. Or I tried to, at least. After registering, I got an email welcoming me to CommSec, in which they referred to me by my full name. Except, it had a problem: Welcome, Ruben Middle Schade. Just in case it’s unclear, my middle name is not “middle”! I thought it might have been a mail merge issue, but I logged in and confirmed my name was listed as “Middle” everywhere. Likewise, every piece of correspondence in print and email referred to me as such. How did this happen? I had a few theories: I absent-mindedly wrote my name as “middle” on the signup form, which slipped through. A system internal to CommSec transcribed my name incorrectly. I have family and friends who work in finance, and it’s surprising how many manual processes are still involved. Cocaine’s a hell of a drug. Number (1) seemed more likely at first, so I was ready to blame myself. Except, there are systems that are supposed to catch such mistakes. Signing up to a new financial account in Australia requires 100 points of ID. These documents clearly, and unambiguously, refer to you by name. If I did write my name wrong, how did CommSec’s systems not flag this obvious discrepancy between that mistake and my real name, and immediately fail to activate the account? To be crystal clear, “Middle” wasn’t listed as my middle name on any of my provided documentation, yet their identity verification erroneously matched them, and proceeded to create the account. That’s… more than a bit worrying. I’d blame people using “AI” for this mistake in 2026, but they didn’t even have that as an excuse back then. So what about option (2)? How likely was it that I failed verification, but that my account was created in their system anyway? Or was it a transcription error? Again, I find both of these difficult to understand. As for option (3), I wouldn’t dare cast stereotypes about people who work in a specific industry. This was merely a joke, like listing someone’s middle name as “Middle”, then verifying it against documents where the person’s name isn’t “Middle”. That’d be funny. Fixing my name What proceeded felt like a comedy of errors. I enquired to CommSec asking if I could change my middle name to… my middle name. I expected this to be easy, because it was such an obvious mistake. That was on me. Their support team rejected my initial request, telling me I’d need to request a “change of name form”. I objected, because I wasn’t “changing” my name, I was correcting a mistake with my real name. But fine, I downloaded the form, completed it, and returned it with a cover letter explaining the bizarre situation. CommSec’s system denied the request, citing insufficient evidence for my name change. I wasn’t changing my name, I was fixing my name! GAH! I’ll admit at that point I lost interest, and went with another broker. This turned out to be a fateful decision, because I ended up paying much lower fees, and I got access to some foreign markets. The capital gains from these investments were instrumental in Clara and I buying our first home. So, thanks CommSec! I think? Closure Every month or so since, I’d receive a newsletter from CommSec advising me of market conditions, and new features I couldn’t use. This was quite funny. But it wasn’t to last: Dear Ruben, We are writing to let you know that your account(s) will be closed, as they have no holdings or balances and have not been used to transact for an extended period of time. These accounts may have been opened directly with CommSec, CommBank, or with one of the brokers CommSec has acquired. Please note that your account may be suspended prior to closure. As part of this account closure process and in accordance with ASX Settlement Operating Rule 7.1.11(a) and CommSec’s Terms and Conditions, we are also formally notifying you of the termination of your CHESS sponsorship agreement. Goodbye, Mr Middle, we hardly knew ye. By Ruben Schade in Sydney, 2026-11-02.

Podcast: Play in new window | Download 37:37 – A feedback episode, reading comments about the show from Adam, Alistair, and Abdullah. Discussing my favourite personal shows that are still going (Into Your Head, The Overnightscape Underground), task management (Getting Things Done™, the spark to get something started), 1980s British retrocomputers (Spectrums, Amstrads, Orics, and Acorns), coffee (my own snobbery, instant coffee, how supermarkets sell it), and what constitutes a mathematics coprocessor! Recorded late September 2026. Recorded in Sydney, Australia. Licence for this track: Creative Commons Attribution 3.0. Attribution: Ruben Schade. Released October 2026 on The Overnightscape Underground, an Internet talk radio channel focusing on a freeform monologue style, with diverse and fascinating hosts; this one notwithstanding. Hosted graciously by the Internet Archive. Subscribe with iTunes, Pocket Casts, Overcast or add this feed to your podcast client. By Ruben Schade in Sydney, 2026-10-01.

Snow Leopard was a version of Mac OS X released in 2010. It was billed by Apple as having “0 new features”, with a focus on refining the system, improving efficiency, and fixing bugs. Those of us using Macs at the time welcomed the news after living with updates that seemingly broke as many things as they introduced with each release. This idea is so powerful—and so longed for—that it’s escaped containment among the Apple crowd. I’ve seen everything from Linux distro to phone updates referred to as Snow Leopard releases, when their vendors cite stability and bug fixes over new features. Likewise, people plead with their vendors for a Snow Leopard release when they feel quality has slipped. The reality at the time was a bit different. As I wrote at the time: This could be the first time I’ve ever downgraded an Apple OS. As we speak I’m downgrading the Snow Leopard partition on my trusty old Core Duo 2006 MacBook Pro back to Leopard (and while I’m at it, I’m finally getting around to upgrading the FreeBSD partition to 8.0!). I kept waiting for updates to fix the severe stability problems in the Finder, my FireWire 800 ExpressCard and my iMovie HD plugins, but I’ve decided to give up for now. This was putting it mildly. When I tried it again a few months later, I still had so many problems that I downgraded again, then leapfrogged it for Lion when it was released in 2011. Jeff Johnson has a great post discussing all the problems Snow Leopard introduced and had to have patched. It was a mess. Still, whether Snow Leopard really was this bastion of stability and polish, the myth surrounding its development and stated purpose obviously resonates today. People invoke its memory because they’re broadly craving stability and quality of life improvements, something almost everyone has wilfully discarded as they chase the next rung of enshittification. Apple’s marketing team hit on something so popular that it has staying power sixteen years later. By Ruben Schade in Sydney, 2026-08-02.

I worked briefly in process control when I was younger, and saw Things.™ One of those Things™ was a wall of LEDs to indicate statuses of various valves and sensors across the entire plant. It was old school, but it worked. It also made you feel like you were on a 1960s-era sci-fi set. What does this have to do with databases? That’s an extremely excellent, and dare I say handsome, question. While we’re on the topic of things I used to do, I used to work against a large database that had a schema with a specific quirk that used to drive me up the wall. Take this contrived example of a table for an account: username | active | paid ---------------+--------+------ nagato_yuki | true | true takarada_rikka | true | false And another for some basic infrastructure: hostname | running | error ------------------+---------+------- retro.rubenerd.au | true | false www.sasara.moe | true | true Do you spot the subtle difference between the two? Why is the first table well designed, and the second one horrible? The first table has uniform positive attributes. Having an active account is good, and being paid is good. This means one can tell at a glance whether an account is in good standing or not. You can also do trivial boolean algebra to derive a status. The second table has a mix of positive and negative attributes. Having a running state of true is good, but having an error state of true is bad. This means you can’t as easily tell at a glance the status of an instance. You can’t also as easily derive an overall status. The value of consistent booleans was something that was immediately obvious when looking at that status wall. It mostly had white lights. When one of these changed colour, you knew there was something actionable. If that status wall instead was designed with some lights being positive, and some being negative, it would be almost (but perhaps not entirely) useless. ☕︎ ☕︎ ☕︎ Why am I thinking about this today? I’ll admit it’s for an incredibly embarrassing reason: I had a dream about databases last night. I know, some people have fun dreams involving flight, reliving something they enjoyed, or exploring a new side of themselves. I dreamed I was back at uni with my DB professor who insisted that all booleans should have positive assertions. Anyway, I was shy at the time when I went to that class in the real world, and said nothing. But what I wanted to say was that uniformity is more important. Most of the time there’s an unambiguous, convenient term to describe something positive, but I also acknowledge there are some circumstances where forcing this naming can get clumsy, such as having a schema full of not_$foo attributes. It’s not a data science to me, but I’m reminded of the sixth rule from The Economist Style Guide: Break any of these rules sooner than say anything outright barbarous. The same applies for software variables, but that would be a whole other post, can of worms, and kettle of fish. By Ruben Schade in Sydney, 2026-07-01.