From "your system is not open source" to "how can I change your system's properties"

I have spent twelve years arguing with people who build closed systems.

I did not notice, until recently, that the longest, most exhausting argument was never with them. It was with myself.

1. I Am Still the Rebel

Let me say this plainly, without softening it into something corporate or comfortable: I am rebellious. I have always been rebellious.

Not rebellious against one specific company, one framework, or one short-sighted manager—rebellious against the rigid, unusable attitude that appears everywhere, across every era, wearing a different costume each time. That has not changed since 2014, and I don't expect it to change by 2038.

In 2014, my rebellion had a clean, external target: closed source. If I couldn't inspect a system's internals, I didn't trust it. If I couldn't modify it, I didn't respect it. The fight felt clear because the enemy was outside myself: "your system," never mine. Back then, I believed that "programming is the philosophy to protest against everything." To me, code was an instrument of defiance, and freedom was a moral imperative.

By 2026, the target had shifted. It is no longer just "your system is closed." It has evolved into something harder to confront: "how can I change how your system is actually used?"

I learned the hard, expensive way that a system can be technically open, modern, and open-source, yet still be quietly weaponized against the people operating inside it.

text
2014: "Why should we accept this system as it is?"
      └── Focus: Philosophical Protest & Openness

2026: "Why is the system this way, what constraints built it, and what happens if I change it?"
      └── Focus: Causal Modeling & Architectural Autonomy

2. The Argument That Doesn't End at the Office Door

Here is the part rarely written in technical engineering postmortems: I don't just disagree with legacy systems, fragile architectures, or teams that accept broken workflows because "that's how it's always been done."

I disagree with myself.

Am I actually right? Is everything fine because the CI pipeline is green, the features shipped, and the standup was quiet—or is that calm an illusion I've simply gotten proficient at manufacturing?

In 2014, I assumed that if I was fighting for something, righteousness was on my side; the friction itself felt like proof. Today, I know friction proves nothing. It's just a feeling. Feelings are not data.

This has become my most hardened conviction: I trust data over what people say.

  • I don't trust what companies declare about their culture.
  • I don't trust what individuals claim about their motives.
  • I don't even trust my own subjective certainty.

I trust what actually happened, measured under load.

Too often, pleasant compliance and people-pleasing are branded as "collaboration." In practice, smiling through a fundamentally flawed architectural decision isn't teamwork—it's a defense mechanism to avoid the friction of saying no. It doesn't build resilient systems or sustainable organizations; it merely defers the production outage.

Left unconstrained, self-serving behavior behaves exactly like an unbounded process: it consumes trust, goodwill, and engineering capacity until the entire runtime crashes. Systems do not get safer because we hope people will act in good faith. They get safer because we design boundaries that hold even when they don't.

3. The Twelve-Year Evolution

My transition over the last twelve years is not a story of abandoning early principles for conservative corporate complacency. My core values—autonomy, curiosity, questioning convention, persistence, and continuous building—survived intact.

What changed fundamentally was the machinery around those values and my unit of reasoning.

Article content

4. Architect Thinking: Moving the Complexity

In my early career, when a database query took five minutes, the immediate instinct was local: Which index do I add? Should we rip out PostgreSQL for something shinier?

As an architect, the question shifts entirely: Why is this query scanning so much data in the first place?

Local optimization often masks systemic architecture flaws. If you are executing expensive aggregations across an OLTP schema on every request, the problem isn't index tuning—it's that you placed the computational burden in the wrong layer of the pipeline.

text
Traditional / Reactive Pattern:
[High Ingestion Load] ──> [OLTP Database] ──> [Complex Query on Read (Slow & Fragile)]

Architectural Systems Pattern:
[High Ingestion Load] ──> [Kafka Buffering] ──> [Pre-calculation & Flattening] ──> [Columnar Store (Sub-second Analytics)]

When building high-throughput pipelines—like handling ten billion monthly records or streaming millions of telecommunication metrics per hour—you realize that real engineering isn't about writing clever, dense code. It is about deciding where computational complexity ought to live:

  • Shifting computation from query-time to ingestion-time via pre-calculated KPIs.
  • Decoupling ingestion throughput from storage write locks with Kafka buffering.
  • Designing schemas for columnar layouts where compression and scan vectors do the heavy lifting.
  • Ensuring idempotency so failures can replay cleanly without corrupting state.

You do not achieve performance by endlessly tuning a broken design. You achieve it by redefining the data path.

5. The Paradox of Freedom and Constraints

Across twelve years, the central tension in my work has settled into an apparent paradox:

The Tension: How do you reconcile a drive for freedom, experimentation, and open systems with an obsession over boundaries, reliability, rate limits, and structural constraints?

They are not opposites. They govern two different phases of engineering:

Discovery Phase -> Optimistic & Unconstrained

Production Phase -> Pessimistic & Rigidly Bounded

  • During discovery, you need unrestricted curiosity, rapid prototyping, and the willingness to discard established dogma.
  • In production, you assume components will fail, networks will partition, third-party dependencies will degrade, and unconstrained processes will run out of memory.

Early in my career, I viewed constraints as the antithesis of freedom. Today, I recognize that deliberate, robust constraints are what protect freedom. They keep systems from collapsing into unmaintainable chaos and protect engineers from being held hostage by fragile infrastructure.

6. The Unresolved Fight

I still don't have a neat, frictionless conclusion.

I still ask myself whether the stability of a system is real or just quiet debt waiting to surface. But asking that question—challenging my own certainty with the same rigorous scrutiny I apply to production telemetry—is the only honest engineering stance I have left.

In 2014, I rebelled against everything outside myself. In 2026, I recognize that the true discipline of engineering is turning that rebellion inward: challenging assumptions, measuring second-order consequences, and demanding evidence over dogma.

The desire to dismantle broken systems hasn't left me. But I have learned that understanding a system deeply is the only way you earn the right to change it.