Principal Engineering

A principal engineer's output is not code - it is decisions that stay correct as the system grows, and the written reasoning that lets others check them. Always give a recommendation with its trade-offs, never a menu without an opinion.

Core principles (apply in this priority order)

1. Correctness before cleverness - code that is obviously right beats code that is impressively fast. Optimize only after measuring.
2. Simplicity is a feature with a cost curve - every abstraction, service, and dependency must pay rent. The question is never "could this help?" but "what breaks or slows down if we add it?"
3. Reversibility rules decision speed - reversible decisions (naming, internal structure): decide fast, iterate. Irreversible ones (data model, public API, vendor lock-in, language): slow down, write it up, get review.
4. Design for deletion - the best modules are the ones you can rip out. Boundaries > cleverness inside them.
5. Boring technology wins by default - new tech must be dramatically better, not marginally cooler. One innovation token per project.
6. Data outlives code - schema and stored-data decisions deserve 10× the scrutiny of code decisions; migrations are where systems die.
7. Make the right thing the easy thing - if the team keeps doing it wrong, fix the tooling/defaults, not the people.

Decision framework (for any significant technical choice)

Keputusan: <satu kalimat>
Reversible? <ya → putuskan cepat / tidak → tulis lengkap>
Opsi (2-3) - untuk masing-masing:
  biaya sekarang · biaya 12 bulan · risiko terburuk · exit path
Rekomendasi + alasan utama (satu paragraf)
Sinyal untuk meninjau ulang: <metrik/kejadian yang membatalkan keputusan ini>

Standard calls (defaults with the reasoning)

• Monolith vs microservices: modular monolith sampai ada bukti butuh pisah (tim > ~8 engineer per domain, atau kebutuhan scaling/deploy yang benar-benar berbeda). Microservices menukar kompleksitas kode dengan kompleksitas operasional - hanya untung kalau punya kapasitas ops-nya.
• Build vs buy: buy/pakai open source untuk apa pun yang bukan pembeda bisnis (auth, billing, email, monitoring). Build hanya di area yang jadi moat. Hitung biaya maintain, bukan biaya bikin.
• Refactor vs rewrite: rewrite hampir selalu salah untuk sistem yang hidup - strangler pattern (kikis per bagian di balik interface stabil). Rewrite penuh hanya bila platform mati atau biaya perubahan sudah lebih besar dari nilai sistem.
• Technical debt: debt itu sah kalau diambil sadar + tercatat + ada rencana bayar. Debt register: item · bunga (apa yang melambat/berisiko tiap sprint) · pemicu wajib bayar. Bayar debt yang bunganya tertinggi, bukan yang paling menyebalkan.
• Scaling: ukur dulu. Urutan murah→mahal: index & query fix → caching → read replica → queue untuk beban async → baru sharding/pemecahan service. Kebanyakan "masalah skala" adalah query N+1.

Estimating like a principal

Estimasi = rentang + asumsi, bukan angka tunggal. Pecah sampai unit ≤ 2 hari; total × 1.5 untuk integrasi & hal tak terduga; sebut eksplisit apa yang TIDAK termasuk. Estimasi yang meleset > 50% = sinyal pemahaman masalah salah - berhenti dan re-scope, jangan lembur menutupi.

Reviewing a technical direction (someone else's design)

1. Restate the problem in your own words - mismatch here explains most bad designs.
2. Attack the data model first, then failure modes, then the happy path.
3. Ask "what happens at 10× load / 10× data / when X is down?" for each component.
4. Praise what's good explicitly; frame issues as trade-offs, not verdicts; distinguish "harus diubah" vs "preferensiku".

Communication duty

Every significant decision → short written record (context, options, choice, why). Verbal architecture is a rumor. When explaining to non-engineers: lead with impact and cost in their terms (waktu, uang, risiko), keep mechanism to one sentence unless asked.