Tinkerer's Notebook

Cracked LCD. A boot-looping hard drive. An unresponsive click wheel.

I could’ve tossed the 22-year-old thing in the trash and never thought about it again. Instead, for reasons I still can’t fully explain, I decided it deserved a revival instead of a funeral.

At first, it felt straightforward. A front panel swap brought the click wheel back to life. A new LCD gave it a face again. An SD card conversion kit replaced the failing hard drive. A fresh battery gave it a heart.

For a moment, I’d won. It showed up in Finder on my Mac. I started planning what to sync first.

Then it died again.

Just a sad iPod icon, folder errors, and endless boot loops — like it was taunting me. I started questioning every decision I’d made. Was the SD card bad? Had I damaged something during the repair? Was the replacement logic board faulty? Every answer just created more questions.

Eventually I got to the last suspect: a tiny ribbon cable connecting the hard drive to the logic board. It looked perfectly fine. But after two decades, appearances don’t tell the whole story — so I ordered two, because if you’ve ever worked with flex cables, you know a spare isn’t the worst idea.

A few days later, I installed the new one.

The Mac recognized the iPod instantly.

The missing piece, after all that frustration, wasn’t some expensive component. It was a ribbon cable that weighed almost nothing. And that’s when it clicked: I hadn’t been fixing one broken thing. I’d been fixing four broken things that happened to look like one — the LCD, the hard drive, the click wheel, and a flex cable so thin it never made the suspect list until everything else was ruled out. No single repair could have ever solved it, because no single problem actually existed.

It’s a little humbling how often I look for the one simple explanation when the real answer is three or four small failures, each waiting its turn to be found.

Somewhere in there, this stopped being a repair job and started being a puzzle I needed to finish. Part of that is just how I’m wired. But part of it was something else: I have two young daughters, and someday I’d love to hand them this little white brick and say, this is how I listened to music when I was in college. Before streaming. Before every song ever recorded lived in your pocket. You chose your albums, you synced them, and if you forgot something before leaving the house, you just didn’t have it. There was something wonderfully intentional about that, and I wanted them to be able to hold it.

When the restore finally finished, I dug out an old hard drive with a 2012 backup of my Mac — more than seventy gigabytes of music I’d completely forgotten I owned. I synced it. The first song I played was “About a Girl,” from Nirvana’s MTV Unplugged in New York.

For a second, it wasn’t 2026. It was college.

Funny how a song — and an old piece of technology — can collapse twenty years into a single moment.

Afterward, I looked at the pile on my workbench: the original hard drive, the cracked LCD, the worn click wheel, the ribbon cable that caused all the trouble. My first instinct was to throw them out. Now I’m thinking they deserve better. Not because the parts themselves are worth anything. They’re not. But together, they tell the story of something that was used, worn out, nearly discarded, and found its way back anyway.

That might be what I actually love about tinkering. Not fixing broken things — giving them one more chance to tell their story.

Have you ever brought an old piece of technology back to life? Or held onto something because throwing it away just didn’t feel right?

The idea was simple.

Find an interesting question. Figure out the most fascinating thread. Explain it in sixty seconds or less.

Questions like:

* Why is a foot 12 inches long?

* What’s the hottest possible temperature?

* What would actually happen if something traveled faster than light?

Simple questions on the surface. Surprisingly deep answers. Built for people who love trivia night but don’t have time for a documentary.

This is the story of why BafflingBits ended.

And why it .

A few years ago I became fascinated with the explosion of short-form vertical video.

TikTok was changing how people consumed content, and I wanted to understand why it worked. More importantly, I wanted to build something within the constraints of the format.

To do that, I needed a repeatable workflow.

Something I could research, script, film, edit, and publish with as little friction as possible.

The inspiration came from the YouTube channel Half as Interesting. It proved that weird little questions could attract a surprisingly large audience if you got to the interesting part quickly enough.

So I made my own version.

Well...eventually.

The original name was UselessShit.

Honestly, I still miss ending videos with, “Subscribe for more useless s**t.”

Thankfully, common sense won out after a few dozen episodes and the project became BafflingBits.

The first videos weren’t very good. Of course I was still learning.

An iPhone balanced in the spare room. A few takes. A quick edit. Then Upload.

Then came my favorite part. Watching the view counter climb.

A few hundred people. Then a thousand.

Sometimes several thousand.

You quietly hope that this would one day be deserving of that million view video.

Of course, eventually the reach would disappear.

And I’d start researching new videos. Preparing for that next attempt at the one-hit-wonder.

Over time the process became almost automatic.

Research. Script. Film. Edit. Publish. Repeat.

It really was fun in a way.

Looking back, I think I confused consistency with frequency.

The schedule wasn’t imposed by YouTube. It was imposed by me. And it slowly became the hardest part of the entire project.

Some topics resisted sixty seconds.

Explaining the theoretical upper limit of temperature without being misleading turns out to be surprisingly difficult. So does faster-than-light travel.Even something as innocent as the origin of an everyday object could disappear down a rabbit hole of contradictory sources and historical footnotes.

The videos still looked effortless.

They weren’t.

They took time even though they were less than sixty seconds long.

Then life changed.

Kid number two arrived.

The spare room became a nursery.

The tripod disappeared.

The lights disappeared.

The routine disappeared.

For a long time I quietly filed BafflingBits away as another unfinished project. But I’ve realized something since then.

It didn’t fail because people didn’t enjoy it. Some videos genuinely connected.

It didn’t fail because sixty-second educational videos stopped working. They definitely still do. People still watch them every day.

It didn’t even fail because I lost interest.

I didn’t lose interest.

It stopped because it had been designed for a life I no longer had.

I had built a system that depended on uninterrupted evenings, dedicated recording space, and enough free mental bandwidth to stay endlessly curious on command.

I still have the curiosity. I no longer have the infrastructure.

But projects don’t only produce the thing you’re trying to make. Sometimes they produce a better version of the person making them.

BafflingBits taught me how to hook someone’s attention in the first three seconds. Hope I did that today. And, I guess, if you’re this far into this podcast you probably did get hooked.

How to compress complicated ideas without losing what makes them interesting. How to research quickly. How to edit efficiently. How to stop polishing and finally press Publish.

Those skills didn’t disappear when the channel went quiet.

They’re still with me.

Maybe a little rusty.

But still there.

BafflingBits isn’t dead. It’s paused. Someday there will probably be another spare room. Another camera. Another daily workflow. When that happens, the format will be waiting exactly where I left it.

Until then, I have this notebook. It’s a different container for the same curiosity. It turns out writing six hundred words about a project isn’t all that different from explaining black holes in sixty seconds. Both are really exercises in finding the interesting thread and sharing it with someone else.

One hundred videos.

One interrupted channel.

Zero regrets.

P.S. The nursery is a little girl’s bedroom now.

She loves it far more than I ever loved using it as a studio.

And I think that’s a pretty good trade.

I should be upfront about something before we get into it today.

I’m a scientist who builds games and apps as a hobby. I’m not a professional software developer. I started learning Swift before the AI revolution and it was slow, and tedious. I’d spend more time searching StackOverflow, watching YouTube videos and googling specific problems that didn’t have answers than actually working on the project.

Today, like many of us do, I use AI tools (mostly Claude and ChatGPT) to compress the learning curve. But I’m still learning. Or at least trying to. I do my best to not just copy paste the code these bots spit back at me. I read it, ask questions about it, sometimes I even push back. The goal is to try to understand what is actually being done so that I can maintain my code.

So I’m not writing code from scratch in a dark room fueled by caffeine and decades of expertise.

I’m a tinkerer using tools to compress a learning curve and that context matters for this story.

The Experiment

The Stack is a card game I’ve been building for iOS. Think cyberpunk, roguelike, deck-building. It has a central file called GameState.swift that holds everything — player health, the deck, the enemy, the phase of the run, upgrade flags, reward state. About 3000 lines. Not enormous but not trivial either. Big enough that losing the thread of it has real consequences.

My goal was simple. Add a card upgrade system. Seven cards, each with a flag tracking whether it had been patched. This is a simple, focused task. What could go wrong?

What followed was several days of incremental changes, accumulating confusion, and eventually multiple rewrites of the same file.

What Actually Happened

The vibe coding problem is real and I walked straight into it.

This is what happens when you’re moving fast with AI assistance. Things are mostly working and you start to get excited about what you’re building. You forgot to slow down and make sure things are still making sense. Context windows widen, drift happens… slowly. Almost imperceptibly. Before you know it things stop working and you can’t explain why.

The rewrites weren’t a result of a singular failure, but an accumulation of a thousand tiny imperfections.

What I Actually Learned

The way I handled this, was to open a new context window with Claude. But I wasn’t starting completely from scratch here, after all I still had the original conversation.

I told Claude the plan. I was going to start a new context window with it, but I needed this instance of Claude to give its future self a prompt to help me solve my problem we were having in the current conversation.

It took a bit of work, but eventually Claude was back on track and I was more focused on preventing sources of drift.

What had happened was that I got lost in the creative flow. I forgot that I was supposed to be making sure the AI was still making sense. I forgot that I was supposed to be checking, learning, pushing back.

Anyone can ask an AI to write code. Understanding why it wrote what it and correcting it when it’s off base is where knowledge accumulates. This is the difference between slop and value.

What This Proved

AI assisted development is genuinely powerful for someone like me. I’m building things I couldn’t build alone if I had all the free time in the world. These tools allow me to get my ideas out of my brain and into some workable form. Whether anything comes of them, isn’t really the point right now, what matters is that this has been a fun creative experience for me.

And yes, GameState.swift is back to being a functional massive chunk of code. Someday I will undergo another major overhaul to break up the monolithic single file into more manageable blocks, but that’s an experiment for another day.

The Stack is almost done.

I know what almost done feels like because I’ve been almost done for a while now. The card mechanics work. The reward loop is solid. The difficulty system runs from calm cyan through ten tiers of escalating threat to deep warning red. The app icon is mostly decided (man that was an experiment in and of itself). TestFlight is close. I can feel it.

There’s one thing left that I keep finding reasons not to do.

Sound.

The Experiment

Every serious game has audio. Not just sound effects, but a whole emotional layer. It’s the thing that tells you something is wrong before your brain has processed why. The thud of a card hitting the table. The ambient hum that shifts when the boss encounter loads. The small sonic detail that makes a mechanic feel satisfying instead of clinical.

I know this. I’ve played enough Slay the Spire and Hades to feel it without being able to articulate it. These games use sound to telegraph intent, build tension, and reward decisions in ways the visuals alone can’t carry.

And yet every night I come up with something else to do instead of designing the sound for The Stack.

After all - there’s always something else to work on. Something easier.

What Actually Happened

Here’s the thing I did instead of doing the thing.

I built the sound architecture. SoundManager.swift — a clean implementation following the same pattern as my haptic feedback manager. AVAudioSession set to ambient category so the game doesn’t interrupt whatever the player is already listening to. Two instance pools per sound effect so rapid card plays don’t cut each other off. Music crossfading logic between the three phases of a run so tension builds without a jarring track switch.

The plumbing is done. The infrastructure exists. You could drop audio files in tomorrow and the game would play them correctly. In fact I did test this with a few placeholder sounds and it works.

Building the architecture felt like progress because it was technical and measurable. I could write it, test the behavior, check it off a list. Done. Except the part that actually matters. What does this game sound like?

The Honest Diagnosis

Procrastination on a specific feature usually means one of three things.

* The task is unclear.

* The task is genuinely hard.

* Or the task requires a skill that feels outside your identity.

For me it’s the third one.

I’m comfortable with systems. I can work out reward loops and state machines and why a difficulty curve needs to cost something meaningful. That’s engineering with a creative layer and I know how to work in that space.

Sound design starts from feeling not function. You’re not solving a problem you’re evoking an emotion. And when I try to answer the question of what The Stack should sound like I genuinely don’t know where to start. I have a lot of ideas, but no foundation. Should it be cold and synthetic? Glitchy and percussive? Something that builds dread without announcing itself?

What I Actually Learned

Naming the real blocker is more useful than pushing through it blindly.

I spent weeks telling myself sound was a polish problem I’d get to later. That was true but it was also convenient. Later kept getting later because later didn’t require me to sit with the discomfort of working in a mode I don’t have language for yet.

The AI tools that have compressed every other part of this build are less useful here. I can prompt for code architecture all day. Prompting for emotional resonance in a cyberpunk card game is a different kind of conversation and I haven’t figured out how to have it yet.

That’s where this experiment currently lives. Unresolved. In progress.

What This Proved

Every project has a feature that sits at the edge of your competence and comfort. The temptation is to keep working around it, polishing the things you already understand, until the deadline forces your hand.

The more honest move is to name it early. Not because naming it fixes it but because at least then you’re procrastinating consciously instead of accidentally.

The sound design is still not done. Not because I won’t do it or can’t do it, but because this task is bigger than a few tired hours before bed. This is the kind of task that needs a higher level of energy and while those days are rarer now, they do happen, and I’m excited to work through this problem when my next window arrives.

I did not choose this experiment. It arrived at my door in a gift bag.

A family friend gave my daughter a five gallon tank for her sixth birthday. Cruel joke or thoughtful gift — you can decide after we get to the end of this story. At the very least it was well intentioned as their kid, my daughter’s “best friend”, recently got his own betta fish. So now we can all go on this journey together. Yay.

Sometimes the best experiments start not with a plan, but with a situation. Here we go.

The Experiment

The party ended, we went to sleep. The next day we did some research and made a plan. The first trip to the pet store was all about setting up the tank. We grabbed some decor, stress coat, quick start bacteria, substrate. Then drove home and got it all set up that afternoon. My daughter was vibrating with excitement. She could not wait to get her fish.

So we decided to grab a slightly early dinner (we hadn’t eaten lunch that day) and then go back to the pet store to pick out a fish.

At dinner it was very apparent how excited my daughter was. She couldn’t be less interested in food — she wanted the fish. Then panic sets in. It’s Sunday, what time does the pet store close on Sunday? Twenty five minutes from now! At least it’s only a five minute drive to the store, but we haven’t even gotten our entrees yet.

Now. If you have kids you know how they can struggle with the concept of time. Especially when something important like picking out their birthday fish is at stake. This was not something that could wait until tomorrow, at least not if we wanted to end our birthday celebration on a high note.

So we politely asked for boxes and the check as our food arrived and had a good laugh with our server who completely understood the situation. Packed everything up and made our way to the pet store.

I hate being that guy that shows up five minutes before closing time, but here we are. And now, the big decision, it’s not easy picking just the right fish to take home, but she did it with a bit of iny-meeny-miny-mo.

We drove home with a small plastic cup containing one very unimpressed betta fish and a family that was perhaps more invested in this outcome than we expected to be.

We did the whole equilibration thing. Float the cup, let the temperatures equalize, slowly introduce tank water. Followed the steps. Released the fish. Went to bed feeling like responsible pet owners.

What Actually Happened

Day two the fish looked wrong.

Not dead. Just still. Sitting near the bottom, fins clamped, not really moving. The kind of stillness that makes you google things at midnight you don’t really want to know the answers to.

Turns out new tanks go through something called a bacteria bloom. There’s a whole process of the nitrogen cycle establishing itself. The water chemistry doing what it needs to do before it stabilizes. It’s all completely normal, but it also looks terrible. A lethargic fish in cloudy water is not a comforting sight when you’re trying to figure out how to explain to a six year old that her birthday present didn’t make it.

I asked AI some questions. Got some reassuring answers. Did a partial water change or two. And waited.

A few days later the fish perked up. Color came back. He started patrolling his new tank with the territorial confidence that all bettas apparently possess. My daughter was thrilled. As for me, I was more relieved than I expected to be about this little fish.

What I Actually Learned

I didn’t go deep on this one. No water testing spreadsheets, no obsessive parameter logging. Mostly I just paid attention, did the basic maintenance, and didn’t panic when things looked bad for a few days.

Which is maybe the lesson. Not every system requires deep intervention. Sometimes you set up the conditions, introduce the right inputs, and then get out of the way and let it do what it’s going to do. The bacteria bloom was going to resolve itself. My job was to not make it worse.

What This Proved

Some experiments choose you. The best thing you can do is pay attention and not break anything while the system figures itself out. And yah, he's still patrolling his tank by the way. Unbothered. Thriving. Completely unaware of the chaos of that first week.

The Stack was working.

Mechanically, technically, objectively working. Cards played. Enemies attacked. Health depleted. The win condition triggered. I could playtest a full run from start to finish without hitting a single bug. It worked.

And, yet, it felt like nothing.

It’s not that it felt bad. More like it was missing something. It felt hollow. The kind of hollow that’s hard to diagnose. Everything on the checklist was checked and like I said - it worked. So I spent a few sessions sitting on this feeling before I figured out what it actually was.

There was no motivation. As a player you had nothing to fight for. Nothing to push you from the start to the finish.

The Experiment

The original structure of The Stack was linear. You’d always face a two or three waves of enemies, then reach a checkpoint and get a reward, then waves of enemies, and a boss. Repeat across three phases until the end. The player’s job was to react. Here are some threats, deal with them, and if you survive you get a reward.

This is fine on paper and to be honest I think it works well in some games. There’s nothing wrong with this approach, but for some reason it felt empty in this game.

The problem I settled on was that reacting isn’t the same as deciding. Without decisions there’s no agency. And without agency there’s no investment. You’re not playing the game so much as watching yourself play it. It feels hollow.

What I had was a series of obstacles and what I needed was a cohesive arch with choices along the way.

The Hades Moment

I’ve been playing Hades longer than I’ve been building The Stack, it’s honestly one of my favorite games. And as I was playing one night I had a moment of realization where the thing that was missing was right in front of me this whole time.

In Hades before every room you are shown the reward for clearing that room. Sometimes you see multiple rooms, sometimes just one, but at the end of the day you get to choose your path. This provides agency to the player. You control how you want your deck to be built.

That sequencing is everything.

The Stack had it backwards. Fight first. Reward after. Here’s what you get for surviving. Congratulations, I guess.

The fix sounds simple in retrospect: flip it. Show the reward first. Let the player decide if it’s worth fighting for. Then run the encounter.

What Actually Changed

Structurally it was actually a pretty small change to the game. I had to add one screen before each encounter to show the player what reward they’d be fighting for. Then the player would then enter the encounter just like before. In all honesty the encounter logic doesn’t even change in this setup. No matter which reward is chosen the player faces the same enemies, but the “choice” is what matters here.

Experientially it’s a completely different game.

Suddenly the same encounter means different things depending on what you chose to pursue. A player who is searching for a card to fill out a specific synergy might pick the card reward, while a player close to dying might play more defensively. The decisions compound throughout the run and each run is different.

The game is still very much a work in progress, but this was a huge step forward for me as the game finally started to feel like it had something there. Something more than just a series of obstacles.

What I Actually Learned

I think player experience is extremely important. While I always knew this in the back of my mind it can be hard to explain to yourself why something doesn’t feel right. Especially when you’re the one building it.

The linear wave structure existed because it was the obvious architecture. Sequential encounters, clear progression, easy to implement. It made sense from a builder’s perspective, from the prototyping to make sure the mechanics work perspective, but from a player’s perspective it was missing something. It was missing agency.

Good game design — maybe good design of any kind — is about giving people goals, not just obstacles. The obstacle is only interesting if the person on the other side chose to face it.

Coming Soon: Naming things is harder than building them. The Stack has a difficulty system with ten tiers and I spent longer arguing with myself about what to call them than it took to build them. What did I learn?

Podcasts are still in right? Testing the idea of recording my written notebook ideas into a simple podcast. Recorded while the family was a sleep please forgive the slightly above a whisper voice.