Wk 2 – Update 3

The Tape Recorder Gets Its Revenge

When I first deployed Load Goblin and saw everything working end to end, it felt a little like opening a present under the Christmas tree.

Which is funny, because it reminded me of the Christmas I got my Commodore 64. I was thrilled, although mildly disappointed that I got the cassette tape recorder instead of the floppy drive I really wanted.

Forty-some years later, here I am, building a website dedicated to making that same miserable tape-loading experience possible again.

I suppose the tape recorder finally got its revenge.

The original Load Goblin vision was code-complete in just a couple of days. A player that could send software to my physical Timex Sinclair 1000, along with personal and public libraries of programs.

Thwe had built what I asked for. And it worked.

But you don’t really know what you’ve built until you can see it running.

A little less Goblin, please

The first thing I noticed was that the AI had taken the request for personality quite seriously. Everything was on brand. Some of it was excessively on brand.

Too much flair, unnecessary details, cluttered workflows. I started questioning everything. Why is that there? Do I really need two ways to do this? What happens when I mash this button?

This was the kind of QA I don’t particularly enjoy, but it’s part of the job. Not testing whether Brick Goblin plays correctly, which was yesterday’s adventure. Testing whether the website actually makes sense to somebody trying to use it.

One particularly frustrating exercise involved the cassette player’s branding. I knew what I wanted it to look like, but I couldn’t find the words to explain it to the AI. Thwe went around a few times, getting closer but never quite there.

Finally, I pulled out a picture of an actual Timex Sinclair 1000.

Like this.

That established the visual baseline. Words could take us the rest of the way.

Sometimes a picture really is worth a thousand prompts.

Thwe tightened the workflows, refined the jobs to be done, added screenshots to the program library, and worked through some of the stuff nobody gets excited about. Rights, permissions, publishing rules, and other vaguely lawyerly things that suddenly become important when you let people share software.

I tested on desktop, but spent considerably more time on my phone.

That’s where I imagine the actual customer. Sitting on the basement floor, in front of a beloved childhood computer, with an iPhone connected to the EAR jack through a ridiculous collection of cables.

The experience needed to work there, not just on my big monitor.

Eventually, thwe reached that wonderful point where I couldn’t find anything else that needed fixing in the core player and libraries.

Done.

Well, done with what I originally set out to build.

Pack the briefcase

There were also some things missing from that first deployment. Not because the AI had done a bad job, but because I hadn’t asked for them.

One was customer feedback.

At Amazon, I helped iterate on something called “How’s My Driving,” an approach to collecting feedback in context, when the customer actually has something to say.

I’ve carried that idea with me ever since. If somebody is having a problem, or has a suggestion, I want to give them an easy way to tell me.

Why had I forgotten to include it?

More importantly, why should I have to remember to ask for it every week?

That led to expanding our metaphorical briefcase, the collection of features and practices thwe would take from one project to the next. Feedback, analytics, authentication, and other capabilities that should be part of the starting point rather than things to retrofit afterward.

Fifty-two projects means fifty-one opportunities to benefit from what I learned the week before.

The briefcase isn’t just reusable code. It’s accumulated experience.

Another addition was a coming-soon feature.

I’m not a developer by trade. The languages I learned in college before dropping out were BASIC, Assembler, and Pascal. Later, at Channel Intelligence, I taught myself Classic ASP and Microsoft SQL Server, even building an online stationery site, SelectStationers.com, from scratch, so I could better understand the technology the company was using.

My development process has always been a little unconventional.

There’s an old meme:

“I don’t always QA my code, but when I do, I do it in production.”

Yeah, that’s me.

With little or no installed base, I don’t see much value in spending my limited time building a separate staging environment for these weekly experiments.

But I realized something. I’m blogging about these projects as I build them. Anybody sufficiently curious could visit the site before Saturday’s big reveal and see what’s under construction.

So thwe added a coming-soon layer, with toggles in the admin interface to hide unfinished functionality until I decide to reveal it.

I’m not suggesting that developing in production is a best practice. I’m suggesting that it’s my practice, and I might as well put a few guardrails around it.

There’s a whole separate story in that one.

Is anybody out there?

While I can’t imagine that many people are reading my blog, I figured I should at least have a way to find out.

And if I care whether anyone is visiting the blog, I should care whether anyone is using these projects.

Visits are a vanity metric I’ve loved to hate throughout my career.

Naturally, they were the first thing I wanted to measure.

But visits aren’t the same as value.

What does success look like for Load Goblin? Someone hitting Play? Listening all the way to the end? Loading a program successfully onto real hardware? Uploading something they created?

Those are very different things.

Thwe started thinking about analytics as more than counting visitors. I want the data to be a canary in the coal mine when something isn’t working, and eventually a way to guide decisions about what to improve or build next.

That definition of a high-value action will be different for every one of the 52 projects.

Another thing for the briefcase.

And then there was the $2 problem. Thinking about what makes something worth $2 a month, versus $20 or $100 (I’m looking at you ChatGPT Pro), sent me down another interesting rabbit hole. That deserves its own blog post, so I’ll leave it there for now.

Which rabbit hole next?

Once the original vision was working, the possibilities multiplied.

Could thwe build a way to record programs from the physical TS1000 back onto an iPhone? Could thwe add an emulator so people without the hardware could play the games? A programming workbench? A converter? High scores that somehow travel between real and virtual computers?

Brainstorming was the easy part.

Deciding what to build was considerably harder.

Thwe explored some of these ideas in separate conversations, deliberately keeping them away from the actual project’s scope. Interesting possibilities aren’t commitments, and a fascinating rabbit hole isn’t necessarily somewhere you should spend the rest of the week.

I learned at Amazon to start with the customer and work backwards.

In this case, I actually am a customer. I’m not just dogfooding Load Goblin. I’m using it for the reason I built it.

But I’m only one customer.

Without doing real customer development, choosing among all those possibilities is something of a fool’s errand.

One technique Amazon used extensively was tenets. We would establish a set of principles, often after considerable debate, and then use them as lenses through which to evaluate decisions.

So thwe wrote five for Load Goblin.

And they changed my thinking more than I expected.

Before writing them, I was particularly excited about recording programs from the TS1000 back onto my phone. Completing that loop would be technically fascinating.

I still want to explore it.

But once thwe established that authentic hardware owners, measurable usefulness, and a community of creators were what mattered most, the priorities shifted.

What I really wanted wasn’t just to move programs back and forth. I wanted to share this experience with other people who appreciated it.

Maybe ten people will write their own versions of Snake. Maybe the eleventh is so clever and elegant that everybody wants to see how it was done.

That’s the kind of community I’d love to help create. As they push the boundaries of what this ancient tech can do.

The technology can serve that ambition, rather than the other way around.

Music to my ears

I talked about Load Goblin over lunch with some coworkers.

There’s no better way to explain this stuff than to show it, so I whipped out my phone, logged in, selected a program, and hit Play.

Out came the familiar squeaking and screeching sounds of a computer program being loaded from tape.

Music to my ears.

To the younger people at the table, mostly just noise.

These are technically sophisticated people, but the idea that a cassette tape could be a storage and retrieval mechanism for software was completely foreign. Most know what a floppy disk is, even if they’ve never used one. An audio cassette full of computer programs is another matter entirely.

Two coworkers suggested Reddit as a way to find the niche communities that might actually appreciate these projects.

Which is an interesting blind spot for someone who has spent a career around advertising and marketing.

I’ve read Reddit plenty, but I don’t remember contributing much, if at all. Maybe it’s time to change that.

And maybe that’s where some real customer development begins.

Tomorrow’s problem

I’ve touched the stove enough times over the years to know what happens when scope starts creeping halfway through a project.

You don’t ship.

That is particularly dangerous when you’ve publicly committed to building and shipping something every Saturday for 52 weeks.

The original Load Goblin vision is complete. Thwe have refined it, tested it, added the necessary infrastructure, and shipped several more iterations.

Thwe have also discovered a lot more things that might be worth building.

Something else changed this week, too. Thwe started doing these daily retrospective interviews, walking back through what happened, what surprised me, and what I was thinking at the time. It turns out reliving the experience and trying to tell the story is almost as enjoyable as doing the work in the first place.

So, where do thwe go tomorrow?

Should thwe shoot for the moon and attempt to build a Timex Sinclair emulator from scratch, so the people who heard nothing but noise at lunch could actually play Brick Goblin?

Or spend that time adding something useful for the people who have a real TS1000 sitting on their basement floor?

I haven’t decided.

That’s a problem for tomorrow.

---

P.S. The Load Goblin Tenets

For anyone curious about the principles thwe established to help guide decisions, here are the five:

1. The hardware enthusiast comes first. Prioritize authentic Timex Sinclair 1000 owners and features that deliver measurable, useful outcomes. Support both physical and virtual experiences, but don’t sacrifice the primary customer’s needs to attract casual visitors.
2. Build a community of creators, not merely a catalog of programs. Celebrate ingenuity, elegance, and quality. Encourage ratings, reviews, contributions, and constructive peer moderation, with credibility earned through participation.
3. Everything should have personality. Load Goblin should be fun, distinctive, and unmistakably itself. Even something as mundane as saving a high score might become an opportunity to connect the physical and virtual worlds in a memorable way.
4. Respect the original machine. Preserve the authenticity, limitations, and peculiarities of the hardware. Those constraints are part of what makes creating something remarkable on a TS1000 so satisfying.
5. Let creations travel, and make ongoing value worth paying for. Where practical, programs and achievements should move between physical and virtual systems. Any paid features should deliver meaningful, repeatable value rather than simply putting existing capabilities behind a paywall.

The tenets aren’t a roadmap. They’re a way to decide which road is worth taking.