It wasn’t long ago that computers were considered “high technology.” The “high” modifier mostly goes unspoken these days. When people say “tech,” they usually mean computing technology: networks, hardware, software, and the companies that build them. Other technological domains need to be distinguished with special monikers: biotech, cleantech, medtech, fintech, and the like. And increasingly, when people talk about tech, they don’t have much positive to say. This growing disenchantment stems from two sources: the business practices of tech companies and tech products themselves.
Google’s recent decision to force Gemini AI tools into all Workspace accounts exemplifies the way tech companies prioritize their business interests over user needs. The saying, “If you’re not the customer, you’re the product” may not be completely true, but it captures how it feels when companies alienate (if not outright exploit) their users. Thanks to this contentious relationship, the term “enshittification” has entered the lexicon to describe the gradual degradation of tech products once they have an established user base.
But bad business practices don’t tell the whole story. Many modern tech products disappoint by design. With a focus on capturing the attention of distracted users, designers pursue simplicity above all else, creating experiences where all meaningful choice has been stripped away. As users, we find ourselves senselessly plodding through predetermined flows or endlessly scrolling across a sea of worthless content. We’re missing out on more than just enjoyment; we’re losing our ability to imagine something better.
We’re Asking Too Little of Our Tools
A particularly apt expression of our diminished technological aspirations can be found in a viral tweet by author Joanna Maciejewska, who wrote:
This tweet resonated with so many people because the sentiment at its core is correct. Technology—not just AI—should free us from drudgery. But if that’s all we aspire to achieve, we’re aiming too low. Truly powerful technologies don’t just mitigate the tedium of daily life. Great technologies help us live in ways we never thought possible.
Some of the best examples of transformative technology aren’t “high tech” at all. Consider the guitar. It might not be the first thing that comes to mind as a form of technology, but that’s exactly what it is: a human-designed tool created to achieve human ends.
What makes a guitar special is that it does more than merely enhance its user’s capabilities—it creates new ones. Put another way, a guitar doesn’t just improve the human body’s natural music-making ability; it creates distinct new modes of musical expression. Generations of musicians have explored those modes without exhausting them. And, importantly, a guitar player and a piano player are not exploring a shared space of musical possibilities with different tools. Instead, each one is engaging with a distinct set of complex interactions between player and instrument. The music is shaped by the instrument, and that relationship expands the musician’s creative potential.
Another example may help illustrate this point. When you use a chainsaw to cut branches, it’s simply a better tool for an existing task. But in the hands of a chainsaw sculptor, it’s far more than a faster chisel. It’s a distinctly different way to sculpt, as reflected in both the creative process and the final work.
Modern Tools, Traditional Principles
Nothing prevents software and other “high tech” products from offering this kind of expressive range, and some do. A graphics editor like Adobe Photoshop isn’t an improved paintbrush; it’s an entirely distinct tool for visual creation. A spreadsheet like Microsoft Excel, far from being merely a better calculator, gives users entirely new ways to model, analyze, and express data. The integrated development environments (IDEs) used by software engineers don’t just make coding faster, they fundamentally change the relationship between code and coder.
The world of digital music, which dates back to the earliest days of computing, offers still more examples. Today’s digital audio workstations let musicians mix and edit tracks in ways that were impossible with the studio tools of yesterday. Audio programming languages allow artists to express music in mathematical terms. Synthesizers create entirely new instruments, free from the limitations of the physical world. It would be a mistake to consider these simply better versions of traditional music tools. They are better thought of as wholly new tools that open new creative possibilities for artists to explore.
Building Tools Worth Mastering
To create more transformative technologies, those of us in the industry must fundamentally reconsider our approach. The push to build simplistic, restrictive products for minimally engaged users is self-defeating. The tech industry serves neither itself nor its users by building every product as if it were a social media app or a shopping website.
This misguided approach was recently highlighted when an AI company’s CEO claimed that people don’t enjoy making music. Satisfying as it would be, I’m not going to spend a lot of time dropping the elbow on these shallow, foolish statements. I bring them up because they so clearly articulate how poorly many industry leaders understand their users’ needs.
Conventional wisdom in our industry would consider guitars “bad” products. They take time to learn, allow for mistakes, and can be frustrating to master. But these are not flaws; they are common characteristics of profoundly empowering tools. To be clear, I am not arguing against user-friendly design. Rather, I’m saying that too often, we build products with a feeble grasp of who the user is and what genuinely serves their interests. After all, I’ve never met a guitarist who complained that their instrument isn’t user friendly enough.
The tech industry, driven by social and commercial forces, puts ever-increasing investment behind products that are easy to pick up but have limited value. That’s the right approach in some cases, but it shouldn’t narrow our broader understanding of what technology can be. We risk forgetting that the most powerful technologies are those that grow with us and challenge us to do and be more.
The people of the future deserve tools that expand human potential. The goal shouldn’t just be to make life easier—it should be to make new ways of living possible.
I like using self-checkout at the store. This comes as no surprise to my mother. As she tells it, when I was a kindergartener, any time I was asked what I wanted to be when I grew up, I’d happily declare that I would be a cashier at the supermarket. Years later, a summer behind the register at the Almacs in town cured me of whatever remained of that ambition, but even today, most of my grocery and pharmacy shopping trips end with me ringing myself up.
That’s not to say that I enjoy all self-checkout experiences. I particularly dislike those that slow down the process with clumsy and frankly insulting anti-theft measures. Despite retailers’ claims, I just don’t believe that self-checkout increases shoplifting risk. In fact, it’s well established that retailers lie about the amount and causes of theft they experience. It seems to me that the traditional approaches to shoplifting, like concealing items in your clothes, remain far more practical than trying to perform self-checkout sleight of hand.
Even accounting for that caveat, I accept I’m in the minority. I suspect media coverage overstates the case when they claim that self-checkout is a “failed experiment” (Tasting Table) that “nobody likes” (CNN) and “hasn’t delivered” (BBC). But I do accept that, on the balance, people prefer human cashiers. Incidentally, my own experience as a human cashier does not suggest that this preference manifests as kindness.
So be it—I don’t mind being out of step with the mainstream. As an introvert, I don’t see paying for groceries or toilet paper as an experience that demands the human touch. I feel perfectly comfortable interacting with a tool to scan my items, calculate the total, and pay. My father falls into the opposite camp. I don’t know if he’s ever used a self-checkout lane, and he avoids ATMs so he can chat up the bank tellers.
A Waiter is More Than a Talking Order Form
Both of us, I submit, have reasonable preferences. It should be no problem for some of us to prefer interacting with people and others to prefer interacting with tools. I also don’t think these preferences are fixed. I might prefer the self-checkout lane, but I still value recommendations from a knowledgeable butcher or cheesemonger.
But my father and I both prefer to know when we’re dealing with a person and when we’re interacting with a tool. Until recently, this distinction was obvious, but we now live in the post-Turing-test age. Large language models (LLMs) give product designers the power to build conversational interfaces that mimic human interaction, and I think we are only beginning to grapple with the most effective and responsible ways to use these technologies.
This problem isn’t completely novel. Even before computers, people developed ways to address some of the shortcomings of natural language as an interface. Consider humble technologies such as invoices or order forms, perhaps like those used at sushi restaurants. These tools work in contexts where structured data is superior to narrative, even without computers involved, and their nature as tools is transparent.
Beyond Preference: A Question of Trust
Maintaining that transparency is going to be the real challenge. Judging by the current crop of LLM-powered products hitting the market, it seems many designers assume that people who prefer human interaction will also prefer tools with human-like interfaces. I believe they are gravely mistaken. Even worse, I think this misunderstanding suggests that some designers would deliberately deceive their users into believing they are interacting with a human being when they are not.
Not only does this deeply misread users’ preferences, I contend as a rule that it’s unethical for product designers to mislead their users.
True, not every user cares whether they are interacting with a person or a tool. In fact, I must admit that I’m somewhat surprised by how many people don’t. But many care profoundly about that distinction, seeing it at the heart of ethical reasoning.
This isn’t just a philosophical question. It’s an emerging challenge that should prompt us to rethink the way we design and use technology. The traditional divide between preferring human or automated service may soon be less relevant than a new question: Do you want to know whether you’re talking to a human or a machine?
Tabletop gaming, mostly in the form of board and card games, is my biggest hobby. I’m also the kind of game nerd who keeps notes. This may sound unusual to outsiders, but it’s common enough within the community that several game logging tools have sprung up, including the one I use, Board Game Stats.
Armed with a year’s worth of data now that the last games of 2024 have been recorded—yes, I did get two plays in on New Year’s Eve—I’m looking back and reflecting on another year in the hobby.
By my standards, I did a lot of gaming this year, logging 278 total plays. My busiest month for gaming was January, when I played 49 games, but I didn’t break 30 in any subsequent month. I was surprised to learn that I logged more games than a few of my convention-going friends just playing online, attending weekly game nights, and playing occasionally on the weekends.
I also played a wide variety of games: 129 different titles hit the table this year. I did most of my gaming in person, with the split around 60-40 between live and online. I did most of my online gaming on Board Game Arena (BGA) and Yucata, in roughly equal proportion.
Fives and Dimes
Gamers who log their plays often share lists of games they’ve played at least five times (nickels), ten times (dimes), or more. This year, I racked up one quarter, three dimes, and nine nickels. A few games stand out when I look at the list:
I’m unsurprised to see Mottainai atop this list for the second year in a row. I’ve been encouraging people to try it for years, but it can be a tough game to teach, and that limits its appeal. I’ll write about it more some other time, because I think it’s underappreciated and deserves the attention. For now, I’ll just say that I think it shines as a fast two-player duel, and I’ve found a wonderful community of players on Yucata who share my enthusiasm for it. I played it less often than I did in 2023, but I fully expect it to be my top game again in 2025.
Ticket to Ride: Legends of the West is a legacy game based on Ticket to Ride. It took my group about six months to play the full campaign. I’ve only played one other legacy game (Betrayal Legacy), so my basis for comparison is limited, but I enjoyed the campaign overall. The game introduces different mechanics from session to session, some persistent and others transient, so there’s quite a bit of variety in the gameplay. I also appreciated the balance between hidden scoring and public scoring in the campaign. My group had a good sense for who was in the lead, but we really did not know how close we were, and everyone felt “in it” throughout.
After playing it 10 times last year, I feel like I finally “get” Ark Nova. I still don’t love it, but I believe I better understand its appeal. All 10 of my plays were online, hosted on Board Game Arena, against friends from my IRL game group. We played all of them asynchronously, meaning we took our turns slowly over the course of several days, and that’s definitely how I prefer to play it. I feel much better connected to what my opponents are doing when I can click over to their tableaus and see what they have going on, something you seldom get to do when you’re at the table together.
Taken together, these 13 games account for 118 plays, or about 42% of my total for the year. My group tends to play a lot of new games, which is wonderful, so it doesn’t surprise me to see that I have a very long tail of 83 games I only played once.
New (To Me) Games
Several games I played for the first time in 2024 left strong impressions. Aside from the already-mentioned Ticket to Ride legacy game, three others stand out: Heat: Pedal to the Metal, Arcs, and HUANG.
Heat was unquestionably the biggest hit of the bunch. It took me a while to get my hands on it, since it seemed to become completely unobtainable after Shut Up & Sit Down’s glowing 2022 review. In my experience, racing games tend to fall to extremes, either very uninteresting or very interesting. It took a couple of years, but I’m delighted to report that Heat is, in fact, very interesting. The design captures the feeling of pushing your car to the limit—requiring you to build up the eponymous heat—but it really makes you pick your spots. Perfectly safe driving is just as unlikely to result in a win as driving like a maniac. And you experience that tension in a streamlined package that’s easy to learn and fast to play.
Arcs is a mid-weight, card-based space combat game that was one of the most talked-about 2024 releases in the hobby board game world. I only played it twice, and I have not been able to play a campaign yet, so I know I haven’t seen everything it has to offer. Sadly, it didn’t catch on with my regular game group. It seems to benefit from multiple plays, as both action selection and scoring can be a bit tricky (pun intended), depending on both cardplay and resource tokens. I want to give it more chances, but it may be hard to get back on the table.
HUANG, on the other hand, was very well received by my game group. Most of us are big fans of Tigris & Euphrates, which HUANG’s design is based on (by way of Yellow & Yangtze, which I’ve never played). It took us a couple of plays to adapt to the differences between the two games, but both are quite accessible to new players without sacrificing the depth that makes them so fun to play again and again. Both games are highly abstracted, somewhat unorthodox civilization builders where players control a set of leaders spread across different dynasties. As they rise, go to war, experience internal conflict, and fall, players try to position their leaders to benefit themselves, even if that means having different leaders on both sides of a conflict. I don’t think HUANG will ever displace T&E from my collection, but it’s different enough that I am happy to have both.
Predictions for 2025
Looking ahead to the new year, I’m optimistic that 2025 will be another good year for games. It’s my great fortune to have a wonderful game group, not to mention non-hobbyist family and friends who are more than obliging when it comes to trying weird games. My plan is to play more of the games in my collection and continue drawing down how many new titles I acquire, something I did pretty well last year.
As I already mentioned, I expect Mottainai to top my list of plays again this year. Just before the new year, I started a campaign of the new Clank! legacy game, so I expect that to make an appearance in this year’s dime list. I’d also be delighted to play the Arcs campaign at least once, and I have a few other games, old and new, that I’d like to get to table at some point. (I’m eager to try Votes for Women and to see if we can’t make Dune happen some weekend.) Beyond that, I’m always hoping to be pleasantly surprised by something unexpected, whether it’s a new release or an overlooked gem. In the end, I’ll be happy as long as I get to spend quality time having fun with good friends around the (real or virtual) table.
If you’re not familiar with it, Advent of Code is a programming challenge that runs every year over the first 25 days of December. Each day, the organizer, Eric Wastl, posts a prompt. Each participant gets a unique bit of input and has to provide a solution generated using their unique input. Then, once you have provided the correct solution, a second phase of the problem is revealed. There’s never any new input, but a complication is introduced that requires more solving and generates a new solution. Each part of the problem earns you a “star,” for a total of 50 possible stars each year.
The two-phase design of each puzzle is the thing I find most interesting about AoC. Coding up solutions to little toy problems is fun (and the tougher coding challenges remind me of the undergrad problem sets I cut my teeth on, thanks Stan), but, as any working programmer can tell you, having to go back over working code and make it do something else is a much more realistic slice of coding life.
I’m no expert on AoC. 2024 was my first year, and there are people who have solved every problem for ten straight years at this point. But I did solve both parts of all 25 problems, so I wrote up these notes on my takeaways in general and my favorite 2024 problem in particular.
General Thoughts
Especially because of AoC’s surprise reveal structure, you’re generally better off taking a direct approach. Getting fancy, and especially trying to optimize prematurely, can land you in a world of regret. I fell prey to this a couple of times early this year.
However, once you get the second part of the problem, it is important to reconsider your approach. The closest I came to missing a second star was Day 13. My initial solution was a simple greedy algorithm, but it was unworkable for the second phase. I spent longer than I would like to admit trying to break the problem down into something that would still allow me to use my original solution. I had to step away and give myself a brain break before I realized that I was actually looking at a (quite simple) bit of linear algebra. Two equations, two unknowns, one embarrassed programmer.
I know a lot of people use AoC and other coding challenges as opportunities to learn new programming languages or to challenge themselves by using unconventional or even counterproductive tools and technologies. For example, bsky user Corvus completed AoC using GameMaker to generate some cool visualizations. I used Python, which is kind of easy mode, even if you restrict yourself to standard libraries, as I did. Maybe next year will be a good opportunity to venture into Go or Rust.
Honorable Mention - Swapped Ripple Carry Adder
Before I write about my favorite problem this past year, I want to give an honorable mention to Day 24. The first part of the problem involved computing the state of a network of binary logic gates (AND, OR, and XOR) based on a set of inputs. That’s a pretty straightforward setup.
Then came the twist. Part two revealed that the inputs were supposed to be interpreted as the binary digits (that is, the 1s and 0s) of two large numbers. The network itself was supposed to operate as an adder producing their sum (also in binary). However, somewhere in the network, five wires had been swapped, and the problem was to identify the five pairs which, when switched back, would make the adder work properly.
At this point, I noticed something interesting: there were only 222 gates in the network. That seemed small for a 45-bit adder, so I started working out how many gates you’d actually need. I found a five-gate module for handling each bit position with carries, and for the least significant bits, which don’t have a carry, two gates suffice. Adding it all up, 222 was exactly the right number. That couldn’t be a coincidence. Instead of searching blindly, I built a static analyzer that looked for that five-gate pattern for each cluster of input and carry bits and complained about the ones that didn’t match. I used that to swap the gates manually in the input file and ran it through my original solution to validate the results. Definitely not the fastest way to solve, but I’d like to think my old computer architecture professors would be proud.
My Favorite Problem - Imaginary Disassembly
The problem I enjoyed most this year was undoubtedly Day 17. The setup presented a simple machine language for a hypothetical 3-bit computer featuring eight instructions, three registers, and no addressable memory. The instruction set included:
A conditional jump
A modulo-8 operation
An operation to XOR two registers
A set of operations that divide registers by a power of 2
An output operation
The input consisted of the initial state for the machine and a sequence of numbers to be used as a program. Unsurprisingly, the first part of the problem involved writing a little emulator to generate the output stream for the program. As I was working on the first part, I couldn’t help thinking ahead to the second part. With no way to change the program or initial state, I honestly did not know what to expect until I submitted my solution (which, incidentally, would have made those computer architecture professors proud, because it worked on the first go).
Then came the reveal: the program was supposed to be a quine—a program that generates its own source code as output. However, one of the initial register values needed to be changed to get the desired behavior (which, if you’re being a stickler, is bending the rules a bit for a quine), and the task was to find the smallest working value. Of course, you could try to approach this by brute forcing the register value, but that’s going to break down pretty rapidly. So, I started by “disassembling” the program into assembly by hand. The resulting pseudocode looked like this:
B := A mod 8
B := B XOR 6
C := A / (2^B)
B := B XOR C
B := B XOR 4
OUTPUT B
A := A / 8
IF A != 0 THEN JUMP 0
The code processes the value in register A three bits at a time. Each iteration, it’s doing some bit munging between A’s three least significant bits and some of its other bits. Then it outputs the result of that munging, shifts A right by three bits, and repeats the loop until there’s nothing left.
So, the solution turns out to be pretty simple. The basic plan is to work backwards, building up a solution three bits at a time. The first iteration looks at which values of A from zero to seven will yield the final number in the program. Then, those values get shifted three bits to the left and the process is repeated for the next-to-last number, and so on.
Of all the AoC problems this year, this was the one that put the biggest smile on my face. It was clever, challenging, and ultimately not all that complicated. Thanks and congratulations to the organizers for ten years of challenges!
I’ve provided my actual code below. As proud as I am of it, I want to note that my priority was speed and efficacy. Under other circumstances, I would structure this code differently. I stored the emulator state in global variables for Part One, and it would have been a pain for me to do the right thing for Part Two and move that state into a structure that could be passed into the emulator for each run. So, no points for beauty here, but it did get the job done.
importsyssrc_reg_A=int(sys.stdin.readline()[12:])src_reg_B=int(sys.stdin.readline()[12:])src_reg_C=int(sys.stdin.readline()[12:])sys.stdin.readline()# Skip blank line
txt_program=sys.stdin.readline()[9:].rstrip().split(',')program=[int(x)forxintxt_program]reg_IP=0output=[]reg_A=Nonereg_B=Nonereg_C=NonedefresetState():globalreg_Aglobalreg_Bglobalreg_Cglobalreg_IPglobaloutputreg_A=src_reg_Areg_B=src_reg_Breg_C=src_reg_Creg_IP=0output=[]defdecode_combo(operand):val=Noneifoperand<4:val=operandelifoperand==4:val=reg_Aelifoperand==5:val=reg_Belifoperand==6:val=reg_Creturnvaldefdiv_A(operand):divisor=2**decode_combo(operand)returnreg_A//divisordefexecute(opcode,operand):globalreg_Aglobalreg_Bglobalreg_Cglobaloutputmatchopcode:case0:# adv
reg_A=div_A(operand)case1:# bxl
reg_B=reg_B^operandcase2:# bst
reg_B=decode_combo(operand)%8case3:#jnz
ifreg_A:returnoperandcase4:# bxc
reg_B=reg_B^reg_Ccase5:# out
output.append(str(decode_combo(operand)%8))case6:# bdv
reg_B=div_A(operand)case7:# cdv
reg_C=div_A(operand)defrunSim():globalreg_IPwhilereg_IP<len(program)-1:new_IP=execute(program[reg_IP],program[reg_IP+1])ifnew_IP!=None:reg_IP=new_IPelse:reg_IP+=2base_vals=[0]whilebase_vals:base=base_vals.pop()solutions=[]foriinrange(8):checkA=(base<<3)+iresetState()reg_A=checkArunSim()ifoutput==txt_program[-len(output):]:iflen(output)==len(txt_program):print(f'SOLUTION FOUND {checkA}')else:solutions.append(checkA)ifsolutions:base_vals.extend(reversed(solutions))
It’s only a few days into 2025, and I’m starting to blog again. I’ve been preparing for a little while now to launch this blog, getting hosting set up, trying out different site generators, and assembling some initial version of a design. But today is going to be Stray Thought’s official birthday.
I’m starting with a handful of goals and guidelines for this blog. I may revisit them, but I’ll be deliberate about making changes.
Goals
Seasons of Intentional Activity
I have tremendous respect for people who blog continuously for years on end. But I know from experience that writing regularly can become a grind, and I know that I experience seasons in my life. Certain times lend themselves to activity and creation, and others lend themselves to rest and renewal.
To get this blog started, I plan to write at least one substantial piece each week through the end of May, then take a break. The break may take the form of a complete hiatus, or I may just post less frequently or regularly for a while. When I’m ready to pick up another season, I’ll share my plans.
Broad Subject Matter
One piece of advice I see for people starting to post content online is to pick a lane and stick with it. This makes sense: you can build an audience more reliably if that audience knows ahead of time what kind of material they’re going to see. However, I don’t have a singular topic I want to focus on. So, I’m choosing a different path.
You can expect me to cover topics I think about a lot, like technology, how groups of people work together, and how games work from the perspectives of both the player and the designer. I will almost certainly also write about things I know less about as a way to work through my thoughts. All I ask is that if I stray from subject matter you’re interested in, don’t give up. I won’t stay away for long.
Value for the Reader
Beyond just covering a breadth of topics, I aim to bring something worthwhile to each one. There may never have been more media options than there are right now, for better or worse. I respect the fact that anyone who bothers to read what I write is forgoing a plethora of alternatives. In return, I will do my best to bring something meaningful—new information, a source you may not have seen, or at least my own perspective—to everything I discuss here.
Guidelines
Thoughtfulness Over Timeliness
It’s going to be impossible for this blog not to touch on contemporary issues and events. But I don’t intend to write rapidly or responsively enough to be a source for news. The online information environment has evolved an expectation that everyone comment on everything. I want to be clear from the start that I will not participate in this, and this blog’s lack of commentary on any topic does not mean that I lack an opinion.
Communication Over Comments
There are no comments on this blog. That is not an oversight. Online communication has been shaped historically by what’s easy to build, not by what encourages healthy communities, genuine relationships, or a constructive exchange of ideas. Communities that have grown up around message boards and comment threads require extensive moderation to be even somewhat functional, and even then, I find them poor substitutes for real human interaction. If I write something that really touches you, feel free to reach out. Better yet, write about it in your own damn blog and let me know.
Creativity Over Slop
Any project like this kicking off in the year 2025 is going to have to reckon with “generative AI.” Here’s where I stand: I am the author of all content here that’s not attributed to someone else. I don’t use LLMs to write for me or do my research. I don’t use text-to-image or text-to-video systems to create graphics. I am experimenting with using LLMs as writing aids, in particular for proofreading and editing. I may also use image editing tools that include AI functionality.
I think the best way to sum up my approach is that I am open to using tools that allow me to express myself authentically, and I am opposed to putting more autogenerated slop into the world.
What Comes Next
I’m starting this blog with clear intentions, and I’m laying them out here to prepare both myself and my readers. But worthwhile projects tend to evolve over time. These goals and guidelines should be foundations, not constraints. If I find myself moving in a new direction—and I probably will—I’ll take the time to explain what’s changing and why. Consider this a commitment to transparency rather than a guarantee that I’ll never change course.
