Seven months

2026. I wanted three applications to talk to each other so that incoming mail stopped landing entirely on me. I could describe the system I wanted in detail. I could not build a single piece of it, and I knew enough to know I couldn't — so I asked for a learning path and said, in as many words, that I was a beginner.

I'm keeping that sentence on this site because it's the honest starting line, and because the distance from it is the only thing here that can't be faked.

Nothing about the seven months was a course. Every single thing was learned because the operation needed it that week and nobody else was going to do it.

Not the tools. The tools are the least interesting part and I'd learn different ones tomorrow if the work asked. What changed is the questions I ask before starting.

Every row on the right came from something going wrong. The left column isn't naive — it's just the set of questions you have before you've been bitten.

The single biggest shift is in the second row. Early on I checked whether things worked. Now I assume anything that can fail quietly already has, and I build the check that would catch it — because an empty result and a broken fetcher look identical, and so do an empty library and a broken matcher.

Writing these case studies put something in front of me that I hadn't seen while doing the work. The same failure appears in three of them, in three different disguises.

Three times I identified a real hazard, described it accurately, and then filed the description as the fix.

Every one of those should have been a check, a lock, or a deleted file. A rule I only follow when I remember it isn't a rule — it's a note about a bug. I know the shape of this now, which is not the same as being cured of it, so it goes on the list of things to watch for in myself rather than being quietly corrected out of the record.

And two more that rhyme

I optimise for this delivery and pay on the next one. Ten numbered renderers and a pipeline copied per run; one-off tooling for a media request that will obviously be made again. Both times copying was thirty seconds and parameterising was an hour, and both times the deadline was that morning. That trade is sometimes correct. I just never made it consciously.

I build snapshots when the problem wants a monitor. I reconciled two systems into one clean file and handed it over — weeks after building continuous change detection for a different dataset. The machinery was written. It did not occur to me to point it at the new problem. Having a pattern and recognising where it applies are two separate skills, and the second one lagged.

Seven rules that started as a fix for one specific disaster and turned out to apply everywhere. These are the actual output of the seven months — more than any particular system.

1. Write the specification before the workSources named, rules fixed, output shape decided. A vague brief produces plausible output nobody can check.
2. Know what question your source is actually answeringAn authoritative list is authoritative about its own question. One told me who had entered an event while I read it as who ran a programme.
3. Verify with something that hasn't seen your answerA second pass that can only agree isn't verification. Removals get confirmed twice, from independent sources.
4. Report the change, not the stateEmit what moved, into a queue a person reviews. Never silently overwrite — an extraction failure and a genuine change look identical until someone looks.
5. Capture provenance at collectionWhere it came from and the evidence it's the right thing, recorded at the moment. Provenance assembled later is a guess wearing a timestamp.
6. State which direction is more expensive to be wrong inThen design around it. An honest gap beats a confident wrong answer, every single time.
7. Say what the deliverable is notThe limitations section is the one nobody asks for and the reason everything else can be trusted.

Not one of those is technical. They'd apply to a finance reconciliation, a clinical registry or a supply chain audit without changing a word — which is the strongest argument I can make that the seven months produced something more portable than a list of tools I happen to have used.

If I were reading this site rather than writing it, I'd want to know what these seven months haven't tested. So here it is, before anyone has to ask.

• I have never worked in a team on this No code review, no pull requests, no colleague disagreeing with my design. Everything here survived contact with reality but never with a second engineer, and those are different pressures. Some of what I call judgement may just be habits nobody has pushed back on.
• Nothing here runs at large scale Thousands of records, not millions. Batch jobs measured in hours, not systems measured in requests per second. The correctness thinking transfers; I have no evidence yet that my performance thinking does.
• Nothing here has woken me at 3am These are scheduled and on-demand jobs where a failure means a delayed delivery, not an outage. I've designed for safe re-runs, but I've never carried a pager and I wouldn't claim to know what that teaches.
• My testing is real but informal Positive controls, independent recounts and byte-level comparisons — not a test suite that runs on every change. I've built the checks that catch the failures I've met. A proper testing discipline is the most obvious gap on this list.

I'd rather say all of that plainly than have someone find it out in an interview. It's also, fairly precisely, the list of what I want to learn next.

Build against real work, not exercises. Every rule on this site exists because something broke in front of someone who was depending on it. A tutorial cannot teach you that a governing body's own list can be confidently wrong, because a tutorial has no stakes.

Write the specification even when you're the only reader. I started doing it in June, and it's the clean line in these seven months: everything before it was improvise-then-repair, everything after was decide-then-build. It felt like bureaucracy for about a week.

Write down what went wrong, in a form the next project will actually read. One hour spent listing the traps from the last build meant six expensive failures cost nothing the second time. It's the highest-return work I have ever done and it looks exactly like procrastination.

And be suspicious of anything that succeeded quietly. Nearly every serious error in these seven months looked, at the moment it happened, like things working normally. The empty page that wasn't empty. The duplicate whose every row was individually valid. The photograph that was correctly captioned — of the wrong child. None of them announced themselves.

Learning to distrust a clean result is most of what I actually learned.