Before we begin, I have three service announcements:
Did you know that Wednesday Wisdom is also a podcast! Find it on Apple Podcasts or on Spotify.
I revamped josvisser.nl which is as useless as ever, but better looking. However, when doing so I did find a whole ton of writing that I thought had been lost to history. Not all of it awful.
For our Dutch readers: We have a new sister publication: “Rare jongens, die Amerikanen” with observations about living and working in the United States of America.
With that out of the way, here is this week’s article…
In my first job, I was part of a group of systems programmers who took care of the IBM mainframes of a large Dutch bank. It was a “golden age” (of sorts) of information technology, because computers were new, expensive, and unnecessarily complicated. This made the people who knew anything about them rare, and consequently they could do more or less whatever they wanted as long as they kept the big calculators in the basement humming along. I would come in every morning and if there was no urgent problem to work on, I was pretty much free to spend my time however I saw fit.
The original IBM mainframes (S360 and S370 families) were based on a 24-bit architecture, limiting addressable memory to 16 MB. When this turned out not to be enough, IBM introduced the “extended architecture” (a.k.a. XA), increasing addressable memory to a whopping 2GB.
Q: Why 2GB?
A: Because XA had a 31-bit architecture.
Q: Uhhh, weird! Why 31 bits?
A: That is really best left unexplained, but suffice it to say that it was because of backward compatibility with the 24-bit architecture and an incredibly bad design decision in that architecture to use the highest bit in a (32-bit) pointer for something else.
Eventually, even 2GB memory was not enough and IBM introduced the Enterprise System Architecture (a.k.a. ESA), which supported an inconceivable 16TB of addressable memory through something called data spaces. Lots of fascinating technical details here, for which we unfortunately do not have time…
With the new architecture came new releases of the prevalent operating systems and one of these was MVS/ESA, which contained many fascinating new features. As the bank’s system programmers we saw it as our job to understand and use as many of these new features as possible, egged on by IBM, who clearly understood that our love for their machines and operating system was one of their strongest assets.
For the interested reader: During my website revamp I unearthed a 1992 article, potentially my first ever article to get published, that contains an assembler listing showcasing some of the “new” features in ESA, including data space access and an instruction to call a subroutine while putting the return address on some new thing called the “stack”. Totes wild.
In a nutshell: We all suffered from a serious bout of shiny object syndrome: A tendency to get distracted by new, exciting ideas, tools, or opportunities, and to abandon the current plan before it has had time to pay off (thank you ChatGPT for this concise definition).
All my life I have suffered from shiny object syndrome, which in my case comes with a tendency to spend a lot of time on exciting new ideas and products without really figuring out beforehand if it makes economic sense or not to invest that much time or if the new thing meets any pressing need I have. Sometimes this paid off, but mostly it didn’t. It seriously paid off with Linux, the Internet, Java, Go, and Rust, which, and it is maybe hard to imagine this, were once just shiny new things that didn’t work particularly well but which many thought harbored great promise. It did not at all pay off for all the time I spent on OS/2 Warp, BeOS, Hyper-G, CORBA, and other things that often bore equally great promise but went nowhere. Often these technologies were so technically interesting that I wanted them to become successful, but of course my support was completely meaningless.
Our entire economic model promotes shiny object syndrome, especially in a world where winner takes most and being early to the game is a strong predictor for who is going to win. A good recent example of that is the blockchain, which is of great technical interest but serves only very narrow practical use cases, mostly in the realm of cryptocurrencies which is a massive scam to begin with. But, that said, an entire industry sprang up around blockchains with massive investments in mostly vaporware startups and people eviscerating value faster than I can say “bored ape”. I once thought to write a satirical post about “dating on the blockchain”, but no, someone had already proposed it for realz. And for some unfathomable reason, it became a minor news item again earlier this year.
For good measure: I want to separate this from laudable efforts to build a dating app for blockchain enthusiasts, which is just target audience selection in a “traditional” app. There are dating apps for Jews, Christians, Goths, and for the disabled and chronically ill. It makes total sense that there would be a dating app to connect blockchain enthusiasts.
Compulsory dad joke: Where do dating apps store their data?
Answer: In a relational database! (get it?!)
The problem with foolish shiny object syndrome is that it leads to loss of focus.
At one Big Tech company I worked for, I once had a colleague who suffered from shiny object syndrome in a big way. There was a lot going on in said company and new internal and external products were launched every other week. This colleague was always in the know and usually among the first to use a new product or API. Keeping up with all of that sucked up a lot of their time, since they read all the mailing lists, all the announcements, went to all the tech talks, and downloaded and experimented with all the products.
This is of course a great colleague to have around, because we could always ask them what was up with something. But here is the problem: It is really difficult to get your actual job done if you are constantly chasing all the shiny new things around you, especially if there is an abundance of them and it is a total crap shoot whether some or all of them are actually going to become important for delivering on your OKRs.
That said, when Bitcoin came, this colleague went big into that as well and eventually made off with a fortune, so I guess the joke is on me…
As you probably know, I work at OpenAI these days and we are also in the business of regularly releasing exciting new things. As a matter of fact, yesterday (at the time of writing) I read on one of our main internal Slack channels that we built some amazing new features in one of our core applications and could the product team please get feedback from our internal user base on how well these work? Super fun thing to do. Important too for the company. But here is the thing, at this time I really have no time for this unless I want to jeopardize some of my other deliverables. I would love to drop everything and try out <super secret cool feature> but, all things considered, what is best for me and for the company?
Obviously, trying out new things and giving feedback is an important contribution to the product team and thereby to the company, but you need to make smart decisions about what to work on. I do not advocate for never giving in to your shiny object syndrome, but I would also warn about giving in too much and to the detriment of your overall productivity.
Shiny objects are the perfect filler for your low productivity hours. We all suffer from these moments when our energy store has depleted and we cannot get anything done that requires even a modicum of willpower. When that happens, you can either go and surf LinkedIn or pick up a shiny object and play with it. Perhaps also not the most productive thing you could theoretically be doing, but maybe the most productive thing you could do, given the state you’re in. Like most drugs, shiny object syndrome does not have to be destructive when given into infrequently and managed well.
So what happened to my shiny object syndrome team in my first job?
Our manager was an incredible killjoy who tried to keep our shiny object syndrome under control. Instead of letting us go rampant in enabling new operating system features left and right for no other reason than that they were cool and we wanted to play with them, he made us write “Implementation plans” for each product in the OS that we were responsible for. For these plans we had to research which (new) features the organization needed, how they should be configured, and what service levels we should offer.
Boring! (but productive).
