Belajar Staff Engineer - Reviewing & Raising the Bar

#Pendahuluan

Setelah di episode 8 kita belajar menumbuhkan orang lewat mentorship dan sponsorship, pada episode ini kita masuk ke mekanisme harian yang paling sering menyentuh kualitas: reviewing & raising the bar. Di level staff, review kalian bukan lagi sekadar memeriksa PR — kalian menjalankan design review lintas tim, menjaga standar kode, dan yang terpenting: menaikkan standar sehingga kesalahan sama tidak berulang di tim mana pun.

Tantangannya halus: bar harus naik, tetapi review yang galak justru menurunkan kualitas — orang berhenti membawa desain awal, menyembunyikan risiko, dan bermain aman. Kita bedah cara menaikkan bar tanpa membunuh keberanian.

#Dua Lapis Review: Design dan Code

Staff engineer bekerja di dua lapis dengan alat berbeda:

Prinsip urutan penting: masalah desain yang ditemukan di design review murah; yang bocor ke code review mahal; yang bocor ke produksi paling mahal. Dorong organisasi menghabiskan energi di lapis pertama — forum design review terbuka dari episode 8 adalah wadahnya.

#Menjalankan Design Review yang Sehat

Struktur review yang efektif (async-first, sesuai pola episode 4):

1. Baca seluruh dokumen sebelum berkomentar — komentar yang lahir dari paragraf pertama biasanya sudah dijawab di paragraf kelima.
2. Klasifikasikan komentar kalian — tandai secara eksplisit: bloker (harus diselesaikan sebelum ratifikasi) atau saran (pertimbangkan). Penulis yang tahu mana-mana bisa memprioritaskan dengan benar.
3. Keberatan pakai konsekuensi — "ini membuat rollback butuh migrasi data 40 menit" dapat didiskusikan; "saya kurang suka" tidak.
4. Puji keputusan bagus secara spesifik — menegaskan apa yang benar sama mengajarnya seperti menunjukkan yang salah.

Contoh komentar bloker yang baik:

[BLOKER] Bagian failover: rencana saat replica DB utama down
hanya "restart dan tunggu". Dengan SLA 99.9% kita punya budget
downtime 43 menit/bulan - skema tunggu ini sendiri bisa habiskan
separuhnya dalam satu insiden. Tolong tambahkan opsi:
(a) read replica promosi otomatis, atau
(b) turunkan komitmen SLA di ADR agar konsisten.
 
[SARAN] Diagram sequence akan lebih mudah dibaca jika pesan
retry digambar eksplisit - pembaca baru sering salah paham di sini.

Perhatikan: bloker disertai angka dan alternatif; saran menjelaskan siapa yang tertolong.

#Feedback yang Mengubah Kualitas

Formula feedback yang bekerja di level staff — spesifik + dampak + arah:

• Lemah: "Error handling-nya kurang bagus."
• Kuat: "Di handler order, error dari payment gateway ditelan tanpa log (order.go:88). Saat gateway flaky, tim on-call tidak punya jejak untuk investigasi. Tambahkan structured log dengan request id dan metric counter per error code."

Tiga aturan pendamping:

1. Kritik kode, bukan orang — "kode ini sulit diuji" bukan "kamu menulis kode buruk". Katakan pada tulisan, bicara pada manusia.
2. Batasi jumlah — sepuluh komentar minor mengalahkan satu masalah besar. Pilih tiga terpenting; sisanya nanti atau biarkan linter yang bilang.
3. Tawarkan pasangan pertanyaan-penjelasan — kadang bertanya "apa yang terjadi jika queue-nya kosong?" lebih menumbuhkan daripada langsung memberi jawaban.

#Blocker vs Preference di Code Review

Sumber konflik code review nomor satu: preferensi yang menyamar jadi blocker. Tetapkan hirarki yang jelas:

Aturan praktis: kalau isu itu tidak ada di standar tertulis dan tidak punya konsekuensi operasional konkret, ia preferensi — sampaikan sebagai saran, lalu usulkan masuk ke standar jika memang bernilai umum. Perdebatan gaya yang sama diulang di puluhan PR adalah sinyal standar tertulis belum ada — pekerjaan sistemik yang justru menjadi tanggung jawab kalian (scaling practices, episode 16).

#Praktik: Rubrik Review Lintas Tim

Untuk menaikkan bar secara konsisten, susun rubrik ringkas yang semua tim bisa pakai. Buat ~/staff-lab/templates/review-rubric.md:

# Rubrik Review Desain (checklist peninjau)
 
Kejelasan
  [ ] Problem statement dengan angka, bukan opini
  [ ] Opsi alternatif minimal 2 beserta alasan ditolak
  [ ] Ask yang eksplisit: keputusan apa yang diminta dari pembaca
 
Kelengkapan teknis
  [ ] Skenario gagal: traffic 5x, dependency down, rollback plan
  [ ] Konsekuensi operasional: on-call, monitoring, biaya
  [ ] Migrasi & kompatibilitas untuk data/klien yang ada
 
Proses
  [ ] Status ADR jelas; keputusan tercatat setelah ratifikasi
  [ ] Bloker dan saran ditandai beda oleh peninjau

Sebar rubrik ini lewat forum design review — bukan dengan dekrit. Tim yang merasakan manfaat akan mengadopsinya sendiri; adopsi sukarela bertahan, kewajiban yang dipaksakan hanya menghasilkan centang formalitas.

#Pitfall Umum Raising the Bar

• Jadi bottleneck review — semua desain menunggu kalian; antrean panjang = orang mulai melewati proses. Latih reviewer baru (episode 8) dan batasi waktu respons kalian.
• Standar tanpa tooling — standar yang hanya hidup di kepala bergantung pada ingatan; kodifikasi ke linter/template/checklist agar bar naik permanen.
• Menghukum kabar buruk — desain yang berani mengakui risiko lalu dinilai jelek akan membuat orang berikutnya menyembunyikan risiko. Hargai kejujuran, kritik keputusannya.
• Bar naik hanya di atas, tak di dasar — fokus ke proyek seksi sambil mengabaikan hygiene dasar membuat standar terlihat pilih kasih. Automasi dasar dulu (lint, test gate), baru debat arsitektur.

#Penutup

Inti yang harus dibawa pulang:

• Dua lapis review: design (keputusan benar untuk 18 bulan) dan code (kesetiaan pada desain); dorong energi ke lapis termurah.
• Komentar diklasifikasikan bloker vs saran; keberatan valid selalu disertai konsekuensi konkret dan angka.
• Formula feedback: spesifik + dampak + arah; kritik kode bukan orang; batasi jumlah.
• Naikkan bar secara sistemik: standar tertulis, rubrik, dan tooling — bukan keteguhan hafalan di tiap PR.

Di episode 10 selanjutnya kita akan membahas working with product & business — cara berkolaborasi dengan PM dan pemangku bisnis, menerjemahkan feasibility menjadi bahasa trade-off mereka, dan memastikan keputusan produk memperhitungkan realitas teknis tanpa menjadi penghalang inovasi. Sampai jumpa di episode 10!