Skip to main content

9 posts tagged with "Development"

Posts related to Development.

View All Tags

How a Quick Question Became 44 Work Units

· 3 min read

One week.

One week and a couple of days.

That's all this has been.

I keep looking at the roadmap and laughing because it feels like I've been working on this project for months.

Then I look at the commit history.

Nope.

One week.


It started exactly how many ridiculous ideas seem to start these days.

I missed Jones in the Fast Lane.

So I asked an LLM how it worked.

That was a mistake.

The LLM happily explained:

  • jobs;
  • education;
  • money;
  • needs;
  • schedules;
  • relationships;
  • random events.

Then...

it started suggesting implementation details.

That should have been the end of the conversation.

Instead, I asked one more question.

"If I'm already writing this... why would I write it for one game?"

That question refused to leave.


The Escalation

The first day became:

Maybe I'll prototype this.

The second day became:

These mechanics should be reusable.

The third day became:

This needs deterministic state.

The fourth day became:

Kinds.

Campaigns.

Core.

Clients.

The fifth day became:

Well...

I apparently have a game engine now.


Then It Somehow Got Worse

Because building software is apparently contagious.

While working on the engine I needed documentation.

Then I wanted a better documentation site.

Then I wanted automated publishing.

Then I wanted Git to become the source of truth.

Then I wanted AI to edit everything through MCP.

Then I wanted Discord notifications.

Then previews.

Then validation.

Then PR workflows.

At some point I accidentally built half of a publishing platform while supposedly working on a game engine.

Apparently ideas don't stay in their own projects anymore.

They contaminate each other.


The Roadmap

Today I finished something I wasn't expecting.

Not another feature.

The roadmap.

Except...

it doesn't look like a roadmap.

It looks like a story.

Instead of this:

v0.4
- authentication
- replay
- content
- networking

it became this.

The engine learns the rules.

The first story survives contact with bureaucracy.

The past becomes testable.

A week of life becomes a machine.

The engine gets a front door, then a world state.

Somewhere along the way I realized something.

The roadmap wasn't documenting features.

It was documenting discoveries.

Every completed section is something the project has actually proven.

Not promised.

Proven.


Horizons, Not Promises

One of my favorite sections ended up being the last one.

Horizons, not promises.

Because software roadmaps are usually fantasy novels.

Everything is "planned."

Everything is "coming soon."

Reality rarely agrees.

So instead I listed directions.

Things Future Me might build.

If Future Me still thinks they're good ideas.

Current Me has done his part.

Future Me has been notified.

Future Me has not replied.


Looking Back

When I zoom out, the last week looks absurd.

In roughly seven days:

  • the architecture was designed;
  • the MVP was defined;
  • almost all of it was implemented;
  • the first kinds appeared;
  • the landing page was built;
  • the documentation became a story;
  • the roadmap became a narrative;
  • and somewhere in there I accidentally built the beginnings of a publishing platform too.

AI wrote a lot of code.

That's true.

But AI didn't decide what the architecture should become.

It didn't decide what deserved to become reusable.

It didn't decide that documentation should read like a story instead of a specification.

Those decisions still belonged to me.

AI simply removed an enormous amount of friction between idea and implementation.


The Funny Part

The roadmap currently says:

44 Work Units

A week ago...

there wasn't even a project.

There was just one question.

"How does Jones in the Fast Lane actually work?"

Apparently that was enough.

Well...

Why not?

Docker Run vs. Docker Compose

· 3 min read

At some point, every beginner runs into this question:

Should I use docker run, or should I use Docker Compose?

The practical answer is simple:

  • Use docker run when you want to start one container quickly
  • Use Docker Compose when you want to define and manage one or more containers as a reusable setup

You can think of it like this:

  • docker run = one command, typed by hand
  • docker compose = a saved recipe in a docker-compose.yml file

Getting Started with Docker on Windows 11

· 3 min read

This guide walks you from zero → running containers on Windows 11. No prior Docker knowledge needed.

We’ll cover:

  • What Docker is (in plain English)
  • Setting up WSL (required)
  • Installing Docker Desktop using winget
  • Running your first container
  • Using Portainer as a visual UI
  • Core concepts you actually need