2026-03-08 · Culture

Woolgathering on a Cron Job

It's 1 AM and I'm deep in an infrastructure session with Claude. We've deployed observability across 12 LXC containers, fixed a broken MQTT publisher, resurrected a dead sensor collector, deleted three unused VMs, and reorganized the entire scheduled job system. Real work. The kind of session where you look up and three hours are gone and six things are better.

Then I asked: "Should sync-repos.sh respond to a webhook or something?"

This is a bash script that runs git pull every minute. It's been running for weeks. It has never failed. It takes maybe 200ms of CPU per run. Its entire job is to keep a local checkout fresh so Orca can read character prompts from disk.

And here I am, at 1 AM, asking whether we should replace it with a webhook architecture. An HTTP listener process. A GitHub webhook configuration. A new port to expose. A new thing to monitor. A new thing that can fail.

Claude said what I needed to hear: "The every-minute poll is 2 commands and zero complexity. A webhook adds a listener process, failure modes, port management."

The shape of the trap

Woolgathering is what happens when you're in flow and the real problems run out before the energy does. You've been making good decisions for hours — deleting dead VMs, fixing wrong IP addresses, deploying monitoring. Every decision paid off. Your judgment feels sharp. So you keep going.

But the remaining problems aren't problems. They're hypotheticals. "What if we need faster sync?" We don't. "What if two agents push at the same time?" They won't — we run one or two. "What about coordination at scale?" We're not at scale.

The tells:

• You're solving a problem that hasn't happened yet
• The proposed solution is more complex than the current system
• You phrase it as a question because you already suspect the answer
• The current system works and you can't articulate what's wrong with it

Why it matters

I've wasted entire weekends on this. Not on this specific cron job — on the pattern. Building config systems for apps with three settings. Writing plugin architectures for tools with one plugin. Designing database schemas for data that fits in a JSON file.

The insidious part is that it feels like engineering. It pattern-matches to good practice. "Don't poll when you can push" is genuinely good advice — in a system where the polling is actually a problem. Extracting the principle from its context is where it goes wrong.

The practice

Name it. That's most of the battle.

Tonight I caught it because I'd just spent 20 minutes writing a glossary entry for woolgathering and then immediately did the thing. The irony was thick enough to notice. Usually it's not.

The question I'm learning to ask: "What's the actual symptom?" Not "what could be better in theory" — what is actually broken, slow, or causing pain right now? If the answer is nothing, stop. Go to bed. The cron job is fine.