How I work

Boring and observable beats clever and opaque.

In a system that can't lose data, predictability is the feature. I'd rather ship the boring solution with a benchmark than the clever one without.

Production is the only proof.

A design is a hypothesis until it survives real load. A benchmark settles an argument that opinions will run in circles for a week.

Writing is the work, not the overhead.

Design docs before code, reviews with the reasoning spelled out, release notes someone can act on. If a decision isn’t written down, it didn’t really happen.

Open source by default.

I maintain in the open. Decisions made in public age better, teach more, and keep me honest.

Fast, cheap, and honest: in that order.

Honest is the one I won't trade away. A system, or an engineer, that hides its real state is the expensive kind.

Async-first, by geography.

I'm in Surabaya (GMT+7), usually about twelve hours ahead of the team I work with. I optimize for handoffs that don't need me awake. Meetings are the fallback, not the medium.

I review the design before the diff.

Code review is the highest-leverage mentoring there is, and most of the leverage is gone once code exists. I’ll push on the doc while every option is still open.

I spell out the why, not just the verdict.

“Change this” is a command; “change this, because here’s the input that breaks it” is a lesson. Across a 12-hour gap, the lesson is the only version that scales.

Escalate with a runbook link, not a vague ping.

Bring me the symptom, the timeline, and what you’ve already tried. I’ll do the same for you. A failing benchmark is the best bug report I can get.

Disagree in the thread, commit after.

Say the hard thing in writing, where it’s on the record and not softened by tone. Once we decide, we row in the same direction.