Quiet Iterations

The quiet case for a boring stack

Sat, 17 Oct 2026 00:00:00 GMT

There is a particular kind of procrastination that looks remarkably like good engineering. You start with a small problem. A few hours later, you have a deployment diagram, three queues, and a surprisingly strong opinion about service discovery.

The original problem is still there.

Start with the thing that must work

Imagine a small application that lets a team collect customer requests. It needs accounts, a database, a couple of forms, and an email when something changes. That is a useful description of the system. “Event-driven platform” is not.

For a first version, I would rather understand one application and one database thoroughly than understand six services approximately.

from django.db import transaction

def create_request(*, customer, message):
    with transaction.atomic():
        request = Request.objects.create(
            customer=customer,
            message=message,
        )
        transaction.on_commit(
            lambda: notify_team(request.pk)
        )
    return request

This sketch deliberately leaves an important question open: what happens if the notification fails? For a real application, I would choose retries, an outbox, or a queue based on the consequence of losing that message. A compact example is a place to begin asking questions, not a reliability guarantee.

Boring is a relationship

A tool is boring when you know how it behaves at the edges. You know how to back it up. You know where the logs live. You have an idea of what will happen when you restart it.

That makes “boring” personal. The right choice for an experienced Go developer might be a terrible first choice for someone who has shipped several Django applications.

Choose a stack you can explain on a tired Tuesday afternoon.

Earn the next moving part

When a limitation becomes concrete, write it down. A job takes too long. A deployment interrupts readers. A query misses its budget. Then make the smallest change that addresses that limitation.

There is nothing virtuous about keeping a system small after it has stopped serving its users. There is also no prize for making it complicated before it needs to be.

What is the simplest stack you have happily kept in production? I would love to hear what made it work — especially the unglamorous bits.

What SQLite taught me about adding a queue

Mon, 12 Oct 2026 00:00:00 GMT

This is a sample field report about a deliberately small experiment: taking a task that sounds like it needs a queue and trying the simplest persistent version first.

The question

Could a single process collect a handful of jobs, remember them across restarts, and process them one at a time? That is a narrower question than “Can SQLite replace a message broker?” Narrow questions are easier to learn from.

CREATE TABLE jobs (
    id INTEGER PRIMARY KEY,
    payload TEXT NOT NULL,
    status TEXT NOT NULL DEFAULT 'pending',
    created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);

The useful failure

The interesting part starts when you add another worker. Selecting a pending row and claiming it are separate operations unless you make them atomic. A design that was pleasant with one process can be wrong with two.

Rather than hide this behind a neat demo, I would test interruption, contention, and repeated execution explicitly. Those are the moments when the persistence model starts to matter.

A smaller conclusion

The lesson is not that every application should use a database as a queue. It is that trying a small version can expose the requirements you were about to outsource to a tool you did not yet understand.

What would you test first: duplicate execution, retries, or recovery after a crash?

Make room for unfinished ideas

Thu, 08 Oct 2026 00:00:00 GMT

Some ideas arrive as an essay. Most arrive as a sentence in a scratch file, a question after a frustrating afternoon, or a small correction to something you thought you knew.

I want a place for those ideas, too.

A note is allowed to be small

A short note can preserve a useful detail without pretending to explain an entire subject. It can say: here is what I tried, here is the result, here is the part I still do not understand.

That last sentence is often the beginning of the conversation.

Publish a question worth answering

An unfinished thought still needs care. Give the reader enough context to follow you. Separate observation from assumption. If the result depends on a particular version or environment, say so.

The goal is not to publish every passing thought. It is to leave a useful trail through the work.

A notebook can be honest about its margins.

Keep a little space

This publication has articles for developed arguments, experiments for things worth trying, and notes for everything that deserves a small place between them.

What do you keep in your own notebook that never seems to make it into a finished article?