Event sourcing is often dismissed as an overkill, but in reality, it mirrors how facts unfold in almost every business domain.

It’s an approach that I’ve learned to love over time.

Event sourcing captures the full history of what actually happened, rather than idolising just the current state. Many systems overlook the importance of preserving past events, focusing only on present data. In doing so, they miss out on a gold mine of valuable information.

“He’s dictatorial! He comes from a military background.”

I hear this often when people discuss certain management styles.

Yes, it’s true that command and control (C2) plays a role in the military. But here’s what’s often missed: many of the most progressive leadership philosophies (decentralised decision-making, intent-based leadership, shared ownership) come from military leaders.

Books like:

• Turn the Ship Around! – L. David Marquet, a submarine commander, handed control to his crew and built leaders at every level.

There’s a common idea floating around (especially in FP-heavy circles and anti-TDDers) that if your language has a strong type system (Hindley–Milner, dependent types, etc.), you don’t need TDD anymore. That once we can encode business rules in types, the compiler “proves” our program is correct.

That’s a misunderstanding that I come across so many times.

Let’s clear this up: type systems, compilers, and TDD are not alternatives. They’re complementary tools. Each addresses a different aspect of correctness and confidence in our code.

Oh dear, my eyes hurt. I’ve just seen yet another bullshit post about TDD:

Let’s talk about TDD. Yeah. That one. Now before someone tries to Uncle Bob or Kent Beck me in the comments, let me clarify — I absolutely support writing unit tests. Lots of them. High coverage. Solid safety nets. No argument there. But TDD — the “tests-first, logic-later” doctrine — is something else. I've heard a lot of lofty, near-religious praise from its evangelists. “Write the test first, and the design will follow.” Sounds nice on a slide. In practice? Not so much. In my entire career, I’ve met exactly one person who actually practiced TDD consistently. And guess what? Even he admitted he had to force himself into it like it’s a gym routine he secretly hates. Here’s my beef: TDD shifts your focus to the wrong thing. It idolizes the test — not the system, not the domain, not the architecture. You're supposed to build a well-structured, modular system… but instead you're writing a failing test for a method you just imagined into existence, praying that this micro-step will magically evolve into a beautiful system. Spoiler: it doesn’t. TDD doesn’t encourage thinking in terms of cohesion, coupling, design boundaries, or long-term maintainability. Instead, it traps you in a rabbit hole of tiny, myopic tasks. “One failing test at a time.” Great. Now you have a bunch of tests for methods that shouldn't even exist in a sane design. What would actually help? Taking a step back. Thinking in modules. Understanding business flows. Designing clear, purposeful abstractions. Not handcuffing your brain to a red-green-refactor treadmill and hoping architectural clarity falls from the sky. Sorry (not sorry), but making TDD a mandatory ritual is like solving architecture with duct tape — just with more IDE shortcuts. Curious to hear from folks who’ve actually built systems, not just pet projects and conference demos.

One of the most honest and revealing questions any leader can ask themselves is: how much do I truly trust the people I lead? Trust isn’t just about delegation or believing in someone’s abilities. It’s about empowering others to make meaningful decisions.

Imagine you’re responsible for a budget. Would you feel comfortable allocating a portion of it directly to your team, giving them the autonomy to pursue initiatives they believe in? Would you trust that, within the strategic goals and constraints of the organisation, they would use those resources wisely and in alignment with the broader mission?

I’m always baffled by those who argue that TDD shouldn’t be applied “religiously,” “completely,” or who imagine some kind of “pure TDD” in contrast to a more pragmatic version.

It’s as if they’re trying to make up for a lack of understanding by practicing a watered-down version of TDD, dismissing anything more rigorous as impractical purism.

They go on complaining about the lack of resources for applying TDD to large projects, as if some special recipe exists for that.