Curtis Foster

About

I want to understand how things work, and programming is how I explore it. I build practical tools for real data.

How it started

The first time I watched a Falcon 9 first stage come back and land, I needed to know how it worked. Not the headline: the engineering behind it.

That one question turned into a habit.

Now I ask the same questions about almost everything:

  • How does it work?
  • Why was it designed this way?
  • What happens if something changes?
  • How could it be better?
  • What are the tradeoffs?
  • Is there a better technology for this?

It didn’t stay with rockets. I started experimenting with technology myself. I installed Ubuntu Server on my home desktop and set up the basics: updates, a firewall, automatic security updates and drive health checks. This site runs as static files on Cloudflare, on my own domain.

I wanted to understand how systems talk to each other and how to choose the right technology for a problem. Then I started building software.

I approach AI the same way. How does it work? Why does it give the answer it gives? Where are its limits, and what’s under the interface?

That’s why I built Multi-Agent Logger, an alpha tool that records what AI coding agents do: the problems they find and the fixes they make.

I build with an AI coding agent, Claude Code. I plan the work, direct it, review it and test it, and I make sure I understand what it wrote.

Programming is where all of it comes together. I can build the thing, test it, change it, break it and figure out why it behaved that way.

Falcon 9 was the catalyst. Curiosity became the habit. Programming became the way I explore it.

How I think

Understand the problem first. Understand the system. Then choose the simplest effective solution.

  1. Curiosity

    Notice what I don’t understand, and ask how it works.

  2. Understanding

    Learn the problem and the system before choosing a solution.

  3. Experimentation

    Try it, measure it, break it on purpose and find out why.

  4. Building

    Build the simplest thing that solves the problem, then improve it with evidence.

Nothing extra

  • Understand the problem before adding a solution.
  • Use the simple solution when it’s enough.
  • Don’t add a technology just because it exists.
  • Every dependency and every abstraction needs a reason.
  • Leave out complexity the problem doesn’t need.

This site follows the same rule: static HTML, one stylesheet and about 2 KB of script, with no runtime dependencies. I built it with Claude Code.

In practice

The C++ cleaner for ASA DataFest 2026 is the clearest example. The original was mine and single-threaded. I did the rewrite and its review with Claude Code: correct first, then measured, then fast.

  1. Make it correct

    A written review of the original cleaner lists 11 mistakes and one open design question. The mistakes were fixed, and every later version writes byte-identical output (same SHA-256).

  2. Measure

    A benchmark script records every run. The original took 447.5 s as a Debug build and 58.4 s as a Release build. Fixing the bugs brought it to 38.2 s.

  3. Cut what’s slow

    Faster file I/O took it to 4.2 s. Splitting the work across threads took it to 2.2 s, 203 times faster than where it started, in 18–32 MB of memory.

The full Console File Cleaner write-up

Now

I’m studying computer programming at Sinclair Community College in Dayton. At ASA DataFest 2026 I was Lead Architect for Team 404, a team of five, and I wrote the original C++ cleaner for our 1.47 GB file.

Since 2017 I’ve worked as a Direct Support Professional, supporting adults with developmental disabilities. The job means working on my own on solo shifts, handing off clearly to the next person and staying calm when things get tense.