Re: If I Really Started Over

This series started with the journey of one comment and ran for twenty chapters. The finale adds no architecture; it does four things: account for the ending, tell the last month, gather three realisations that only surfaced halfway through the writing, and answer the title’s question — if I really started over, what would I change?

After that day

#19 covered that day: development paused, the contract renegotiated, three people left a month later. After that, the project moved towards shutdown and redundancies for political reasons.

The political details aren’t written here. Not because they can’t be, but because they aren’t worth it — we’re engineers, and we focus where focus belongs. Commercial and political forces can switch a project off, and an engineer can’t control that; what an engineer controls is doing the work right every day the project lives, and what they carry out on the day it dies. This chapter is only about the second.

The final month

The first thing I did once the ending was certain was book a one-on-one with everyone immediately. Nobody needed consoling — they all understood the owner’s decision; engineers accept a causal chain like “the contract collapsed, the money ran out” faster than you’d expect. What actually needed discussing was the next step.

I told them: for this last month, go and look for work — and if it helps, I’ll run mock interviews with you. Then we turned the remaining time into an acceleration period: studying the AI tools that were exploding at the time together — OpenClaw, opencode, Claude Code, multica — building the competitiveness that doesn’t fit on a résumé.

The last thing was that I stood up multica so people in other departments could write tasks themselves, with engineers reviewing them. The team was disbanding, but the requirements weren’t going to disappear; better to leave behind a way of working — non-engineers write tasks, engineers hold the gate — than a pile of wishes with nobody to catch them. #15 said what we lacked was “a language for incidents”; the final delivery before leaving happened to give the people staying a language for requirements.

Still shipping on the eve of disbanding isn’t a performance of diligence. An engineer’s dignity doesn’t live in a project’s success or failure — half of that is in other people’s hands; dignity lives in “right up to the last day, the work was good”.

A meteor’s appeal

There’s a story owed since #15: the post-selection variant feature.

Tuesday, midnight, a call to the CTO: the host wanted a “post-selection variant” feature — customers call orders during the stream and pick the exact variant after it ends — needed for Saturday’s stream. A colleague and I rushed it out, tested it thoroughly, felt entirely confident, and shipped on time.

And then it was never used once in three months.

The CTO asked, and got this answer: “Knowing I can use it and not being able to use it are different things.” What my colleague, the CTO and I felt at the time was tragicomic — a midnight meteor, a week of crunch, in exchange for a button nobody touched.

But having written these twenty chapters, I’d like to appeal that meteor’s verdict. #17 had an insurance policy never claimed on — image_metadata’s reverse reference, taken out for entirely genuine reasons, with the day of the claim never coming; #15 said monitoring’s ultimate product isn’t information, it’s peace of mind. The post-selection variant is the same thing: the host was never buying that button, she was buying “if I need it on Saturday, I have it”. An unclaimed policy doesn’t mean the premiums were wasted — having it and not using it is itself an effect. We recorded it in an engineer’s ledger (zero usage = zero value) and the host was keeping a different one; only now, writing this series, do I see that hers was the right ledger.

Three realisations

Three things surfaced by themselves halfway through this series — not things I knew back then, but things the writing forced out. Collected here in the order they appeared.

One: we actually did rather well back then. When I started this series I expected to write a confession; halfway through I found the “wouldn’t change” list unusually long: the FSM and lookup-as-validation, fact tables and derive-on-read, batches that silt but don’t fall, 3NF discipline, five boring components, order the queue, don’t schedule it… Why the gap between memory and fact? Because good decisions are silent — they don’t cause incidents, and what causes no incident leaves no memory; a painful memory is always more vivid than a correct decision. An engineer looking back at themselves carries the inverse of survivorship bias: remembering only the scars and forgetting the armour.

Two: I wasn’t a data engineer back then, and I did a great deal of what data engineers do. Fetching comments is an EL pipeline, the FSM batch is stream consumption, the sold quantity is a materialised view, the hourly recomputation is scheduled repair, the allocation log is event sourcing, the export is data delivery — everything the reconciliation chapter gathered up is present in what my job title today calls Data Engineering. DE isn’t a job title, it’s a set of problems; back then that set grew on an e-commerce backend, and when I changed jobs later I only moved to a place where the same set is the main event. From backend to DE manager looks like a career change from outside; I know better: the problems didn’t change, they finally got a name.

Three: the whole system is an unbundled database. #16 unpacked this; the finale only adds a last layer: the first two realisations are corollaries of it. “We did rather well” is because we unknowingly followed a database’s internal discipline (write the log first, derive rather than materialise, repair from the facts); “I did DE work” is because every component of an unbundled database is a data engineer’s daily life. Three realisations are three faces of one thing — we spent eighteen months building a database by hand, and I only found out while writing this series.

If I really started over, the one thing I’d most want to change

The title’s question — surely the answer is some piece of architecture? The FSM? The state machine? The timing of the microservices?

None of them. The core architecture, as the last section said, I wouldn’t change. What I’d most want to change is the monitoring.

Pour out every “starting over” voice from twenty chapters and the right-hand list has one thing in common: not one item is a feature, all of them are protection — a gauge you can see, an incident you can describe, a poison pill you can catch, an attack you can block. And where the left-hand list explains why the system survived, the right-hand one explains why the people had such a hard time: the fear during every stream, the vaguely-watched Sentry, the midnight calls — the system silted without falling, and the people blew on contact.

So if I really started over, what I’d most want to change isn’t a line of architecture, it’s doing the monitoring properly — so no engineer ever gets the chance to suffer the way I did. The greatest do-over isn’t for the system, it’s for the people. The system’s books balanced back then; the people’s books are what I only learned to keep later.

Re:

The series’ name plays on a joke, but writing to the end I found the word “Re:” has three meanings, and they happen to be three layers of an ending.

Re: is retry. Every chapter carries a “if I started over” voice — not a list of regrets, but fighting each of those battles again with what I know now. The conclusion of refighting them is in the two lists above: keep the core, add the protection. Technically, the do-over is settled.

Re: is reply. Halfway through the writing I realised these twenty-one chapters are a letter of reply — to the version of me watching streams with his stomach in knots and fixing bugs at midnight. Summarised in one line: you did better than you thought; and what you owed, you paid off later.

Re: is resume. The project died. Everything technical was right and the project died anyway — the most honest lesson in this industry: half of success is in other people’s hands, and all of your capability is in yours. The day the platform shut down, the code went to the company, but the feel of the FSM, the instinct for facts and derivations, the nerve for batches, the discipline of reconciliation, the way to lead people — those left with me. After leaving I became an EM, first doubling as interim SRE; today I lead a data engineering team, and the monitoring I once owed myself I’m filling in, one pane at a time, for the engineers I work with now.

The ship never sailed; the sailors are still at sea.

Onward.