The "capital creates pressure to fabricate progress" bit is painfully accurate. There's this weird dynamic where once you take money, the reporting relationship inverts your priorities. Instead of "what moves the business forward?" it becomes "what can I show on the next update call?"

I've seen this play out even at smaller scales with freelance retainers - the second you're accountable to external money, you start optimizing for visible activity over actual progress.

The 70% capital return is quietly remarkable though. Most founders in that position would've spent down to zero chasing pivots. Knowing when to fold and still having something to give back takes more backbone than people realize.

The messier version of this problem: banks themselves don't give stable unique identifiers. Transaction references get reused, amounts change during settlement, descriptions morph between API calls. In practice you end up building composite keys from fuzzy matching, not clean UUIDs. Real payment data is far noisier than these theoretical discussions assume.

What surprised me the most is that the counterparty field is optional.

You'd think that a transaction means money is going from a source to a destination, but according to some banking APIs sometimes it just magically disappears into the aether.

The tech debt question from _def is interesting. In my experience quantifying it actually misses the point.

The real cost isn't the time lost - it's decision avoidance. Teams stop touching certain modules. New features get built around the problem instead of through it. You end up with architectural scar tissue that shapes every future decision.

I've seen this play out where a 2-week refactor that everyone knows needs to happen gets deferred for years because nobody can attach a dollar figure to "we're scared to change this code." Meanwhile every sprint planning becomes a creative exercise in routing around the scary parts.

The tell is when your estimates have a silent "...assuming we don't have to touch X" attached to them.

This is an excellent point. I've also seen scenarios in which the architectural scar is being defended vehemently by an engineer still at the company. In my experience it is someone respected, who is overall a highly competent engineer, and the rest of engineering ends up working around the scar.

Thanks for reading!

Same in the UK. We typically get 2 or 5 year fixed deals, then you're expected to remortgage or you end up on the lender's standard variable rate (usually painfully higher).

My first mortgage was a 2-year fix at 1.89% during covid. When that ended I had to remortgage at nearly 5%. That was a fun conversation with my partner.

The US system is genuinely unusual globally. Fannie Mae and Freddie Mac basically absorb all that interest rate risk that would otherwise sit with borrowers. It's a massive implicit subsidy that most Americans don't fully appreciate.

The interesting thing about Zig's move isn't really the drama - it's watching a project work through platform migration in real time.

Most open source projects talk about reducing GitHub dependency but never actually do it because the switching costs are brutal. Issues, PRs, CI integrations, contributor muscle memory - it all adds up. Codeberg is solid but the network effects aren't there yet.

Curious whether this pushes other projects to at least have contingency plans. The AI training concerns are real, but I suspect the bigger long-term risk is just platform enshittification in general - feature bloat, performance degradation, mandatory upsells.

The unprivileged DGRAM approach is a lifesaver for container environments. Ran into this building a health check service - spent ages wondering why my ping code needed --privileged when the system ping worked fine as a normal user. Turns out the default ping binary has setuid, which isn't an option in a minimal container image.

The cross-platform checksum difference is a pain though. Linux handling it for you is convenient until you test on macOS and everything breaks silently.

The "split long functions" advice works well for most code but falls apart in transaction processing pipelines.

I work on financial data processing where you genuinely have 15 sequential steps that must run in exact order: parse statement, normalize dates, detect duplicates, match patterns, calculate VAT, validate totals, etc. Each step modifies state that the next step needs.

Splitting these into separate functions creates two problems: (1) you end up passing huge context objects between them, and (2) the "what happens next" logic gets scattered across files. Reading the code becomes an archaeology exercise.

What I've found works better: keep the orchestration in one longer function but extract genuinely reusable logic (date parsing, pattern matching algorithms) into helpers. The main function reads like a recipe - you can see the full flow without jumping around, but the complex bits are tucked away.

70 lines is probably fine for CRUD apps. But domains with inherently sequential multi-step processes sometimes just need longer functions.

I'll admit this may be naive, but I don't see the problem based on your description. Split each step into its own private function, pass the context by reference / as a struct, unit test each function to ensure its behavior is correct. Write one public orchestrator function which calls each step in the appropriate sequence and test that, too. Pull logic into helper functions whenever necessary, that's fine.

I do not work in finance, but I've written some exceptionally complex business logic this way. With a single public orchestrator function you can just leave the private functions in place next to it. Readability and testability are enhanced by chunking out each step and making logic obvious. Obviously this is a little reductive, but what am I missing?

You're not missing much - what you describe is roughly what I do. My original comment was pushing back against the "70 lines max" orthodoxy, not against splitting at all.

The nuance: the context struct approach works well when steps are relatively independent. It gets messy when step 7 needs to conditionally branch based on something step 3 discovered, and step 12 needs to know about that branch. You end up with flags and state scattered through the struct, or you start passing step outputs explicitly, and the orchestrator becomes a 40-line chain of if/else deciding which steps to run.

For genuinely linear pipelines (parse → transform → validate → output), private functions + orchestrator is clean. For pipelines with lots of conditional paths based on earlier results, I've found keeping more in the orchestrator makes the branching logic visible rather than hidden inside step functions that check context.flags.somethingWeird.

Probably domain-specific. Financial data has a lot of "if we detected X in step 3, skip steps 6-8 and handle differently in step 11" type logic.

Interesting. I'd love to learn more about the problem class.

Happy to elaborate. The core problem is bank statement reconciliation - matching raw bank transactions to your accounting records.

Sounds simple until you hit the real-world mess:

1. *Ambiguous descriptions*: "CARD 1234 AMAZON" could be office supplies, inventory, or someone's personal expense on the company card. Same vendor, completely different accounting treatment.

2. *Sequential dependencies*: You need to detect transfers first (money moving between your own accounts), because those shouldn't hit expense/income at all. But transfer detection needs to see ALL transactions across ALL accounts before it can match pairs. Then pattern matching runs, but its suggestions might conflict with the transfer detection. Then VAT calculation runs, but some transactions are VAT-exempt based on what pattern matching decided.

3. *Confidence cascades*: If step 3 says "70% confident this is office supplies," step 7 needs to know that confidence when deciding whether to auto-post or flag for review. But step 5 might have found a historical pattern that bumps it to 95%. Now you're tracking confidence origins alongside confidence scores.

4. *The "almost identical" trap*: "AMAZON PRIME" and "AMAZON MARKETPLACE" need completely different treatment. But "AMZN MKTP" and "AMAZON MARKETPLACE" are the same thing. Fuzzy matching helps, but too fuzzy and you miscategorize; too strict and you miss obvious matches.

5. *Retroactive corrections*: User reviews transaction 47 and says "actually this is inventory, not supplies." Now you need to propagate that learning to similar future transactions, but also potentially re-evaluate transactions 48-200 that already processed.

The conditional branching gets gnarly because each step can short-circuit or redirect later steps based on what it discovered. A clean pipeline assumes linear data flow, but this is more like a decision tree where the branches depend on accumulated state from multiple earlier decisions.

> Each step modifies state that the next step needs.

I've been bitten by this. It's not the length that's the problem, so much as the surface area which a long function has to stealthily mutate its variables. If you have a bunch of steps in one function all modifying the same state, there's a risk that the underlying logic which determines the final value of widely-used, widely-edited variables can get hard to decipher.

Writing a function like that now, I'd want to make very sure that everything involved is immutable & all the steps are as close to pure functions as I can get them. I feel like it'd get shorter as a consequence of that, just because pure functions are easier to factor out, but that's not really my objective. Maybe step 1 is a function that returns a `Step1Output` which gets stored in a big State object, and step 2 accesses those values as `state.step1Output.x`. If I absolutely must have mutable state, I'd keep it small, explicit, and as separate from the rest of the variables as possible.

Yeah the immutability angle is the right instinct. The Step1Output approach is essentially what we landed on - each phase returns a typed result that gets composed into the final state. The tricky bit is when phase 7 needs to check something from phase 3's output to decide whether to run at all. You end up with either a growing "context" object that accumulates results, or a lot of explicit parameters threading through.

The discipline tax is real though. Pure functions are easier to test in isolation but harder to trace when you're debugging "why did this transaction get coded wrong" and the answer spans 6 different step outputs.

> harder to trace when you're debugging "why did this transaction get coded wrong" and the answer spans 6 different step outputs

That's definitely a pain, but I'm not sure it's easier when this is one variable being mutated in six different places. I think you're just running into the essential complexity of the problem.

Completely agree - it's essential complexity either way. The mutation approach just spreads it across time (when did this value change?), while the immutable approach spreads it across space (which step produced this value?).

The immutable version is probably easier to debug in practice since you can inspect each step's output independently. The "6 places" complaint was more about cognitive load during debugging than actual difficulty - you're jumping between files instead of scrolling through one. But that's a tooling/IDE problem, not an architecture one.

The typestate pattern common in Rust applications allows the compiler to verify that the operations are executed in the right order and that previous states are not accidentally referenced. Here’s a good description: https://cliffle.com/blog/rust-typestate/

Thanks for the link - typestate is exactly the kind of compile-time guarantee I wish we had in JS/TS land. The pattern would be perfect for enforcing "you can't call postToAccounting() until validateTotals() has been called" at the type level.

We're in Node.js so the best we can do is runtime checks and careful typing. I've experimented with builder patterns that sort of approximate this - each method returns a new type that only exposes the valid next operations - but it's clunky compared to proper typestate.

The real benefit isn't just preventing out-of-order calls, it's making invalid states unrepresentable. Half our bugs come from "somehow this transaction reached step 9 without having the field that step 5 should have populated."

I frequently write software like this (in other domains). Structs exist (in most languages) specifically for the purpose of packaging up state to pass around, I don't really buy that passing around a huge context is the problem. I'm not opposed to long functions (they can frequently be easier to understand than deep callstacks), especially in languages that are strictly immutable like Clojure or where mutation is tightly controlled like Rust. Otherwise it really helps to break down problems into sub problems with discrete state and success/failure conditions, even though it results in more boilerplate to manage.

Fair point on structs - the context object itself isn't the problem, it's what ends up inside it. When the struct is a clean data container (transaction, amounts, dates, account codes) it works great.

Where I've seen it go sideways is when it accumulates process state: wasTransferDetected, skipVATCalculation, needsManualReview, originalMatchConfidence. Now you have a data object that's also a control flow object, and understanding the code means understanding which flags get set where and what downstream checks them.

Your point about discrete success/failure conditions is well taken though. We moved toward exactly that - each phase either returns its result or an explicit error, and the orchestrator handles the failures instead of stuffing error flags into the context for later. Bit more boilerplate but much easier to reason about.

This is an admirable goal but complicated by the inevitable conditional logic around what to do in certain situations. Push the conditions into the sub methods, or keep them in primary method? Thinking about what are testable chunks of logic can be a valuable guide. A lot of discipline is required so these primary methods dont become spaghetti themselves.

The testability angle is the deciding factor for me. Business logic that can be tested without the full pipeline context goes in sub methods. Orchestration decisions stay in the primary method.

Concrete example: "is this a transfer between accounts?" is pure business logic - takes a transaction and a list of bank accounts, returns true/false. That gets its own function with its own tests.

But "if it's a transfer, skip VAT calculation and use a different account mapping" is orchestration. Pushing that into the transfer detection function means it now needs to know about VAT and account mapping, which breaks isolation. Keeping it in the primary method means you can see all the skip/branch decisions in one place.

The spaghetti risk is real. What helps: keeping the orchestrator as declarative as possible. "if transfer detected, result = handleAsTransfer()" rather than inline logic. The primary method becomes a readable list of conditions and delegations, not nested logic.