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 five things: account for the ending, tell the last month, gather three realisations that only surfaced halfway through the writing, answer the title’s question — if I really started over, what would I change? — and finally, take one look at the AI wave: what travels with the person.

After that day

#19 covered that day: development paused, the contract renegotiated, a month later only three people remained. 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 walk away with 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 boss’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. My colleagues 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: “There’s a difference between knowing I can use it and not being able to.” What my colleagues, 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 DE back then, yet I did a great deal of what DEs 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 EM of a DE team 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.

In the AI wave, what travels with the person

In the final month we studied AI tools together, and at the time it was for an edge in the job hunt; looking back a few months later, what we were really doing was seeing a bigger thing clearly: AI made “writing” cheap and “judgment” expensive. Nothing of value in this series was “written” into existence — the refusal to build a cache, the surrender of letting the hosts rip out the state machine, the granularity of punishing exactly what was done, the discipline of boring tech: all of it is judgment, and judgment comes from being there. AI can hand you five ways to deduct stock; it can’t tell you “which one this team, this floor, this host should pick” — that answer isn’t in the training data, it’s in the sound of the stream.

That final multica delivery looks, from here, like a rehearsal: non-engineers write the tasks, engineers review — give away the output, keep the gate. #18 said a lead’s job is three checkpoints: breakdown, review, technology choice; in the AI era those three stop being a lead’s prerogative and become every engineer’s daily work — your relationship with AI is a player-coach’s relationship with the team. So the direction for improving yourself is concrete: the ability to hold the gate grows out of judgment, and judgment grows out of being there; and for the experience of being there to become a transferable asset, there is exactly one road — write it down. This series is its own demonstration: not one of the three realisations was something I knew back then; all of them were forced out by the writing. Experience unwritten is only memory; written down, it becomes judgment.

Tools turn over every two years, and whoever chases tools resets to zero every two years; the set of problems — invariants, facts and derivations, boundaries, trade-offs — hasn’t changed in ten. Hold the problems, and AI is your lever; hold only the tools, and you’re what AI replaces.

Re:

The series’ name is a nod to an anime, 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 an “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. The technical do-over is settled here.

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.