Ketika Code Review Berubah Menjadi Judgment

Code review adalah salah satu praktik engineering yang paling sering disebut sebagai “tanda tim yang sehat”. Hampir setiap organisasi teknologi menjalankannya, hampir setiap engineer setuju bahwa itu penting, dan hampir setiap artikel tentang software quality merekomendasikannya. Tapi ada satu pertanyaan yang jarang diajukan: apakah code review yang kamu jalankan hari ini benar-benar mencapai tujuan yang kamu kira? Artikel ini adalah refleksi jujur tentang apa yang terjadi ketika praktik yang niatnya baik — weekly code review meeting — perlahan bergeser menjadi sesuatu yang justru merusak learning culture di dalam tim.

Anatomi Weekly Code Review Meeting

Gambaran umum weekly code review meeting di banyak tim terlihat seperti ini: satu jam setiap minggu, semua engineer hadir, kode dibuka di layar proyektor atau shared screen, lalu diskusi berjalan sampai waktu habis. Tujuan yang dinyatakan biasanya tiga: engineer saling tahu bagaimana kode ditulis, ada pembelajaran bersama, dan ada alignment standar kualitas.

Secara niat, ini semua benar. Tidak ada yang salah dari ketiga tujuan itu. Masalahnya bukan di tujuan — masalahnya ada di jarak antara tujuan dan apa yang sebenarnya terjadi di dalam ruangan.

Perhatikan pola yang hampir selalu berulang dalam sesi seperti ini:

sequenceDiagram
    participant Lead as Tech Lead
    participant Senior as Senior Engineer
    participant Junior as Junior Engineer

    Lead->>Semua: "Oke, kita review PR dari tim A dulu"
    Senior->>Semua: Menjelaskan konteks kode
    Lead->>Semua: "Di sini sebaiknya pakai pattern X"
    Senior->>Semua: "Betul, dan sebaiknya juga Y"
    Note over Junior: Ingin bertanya tapi menahan diri
    Lead->>Semua: "Ada yang mau tambah?"
    Note over Junior: Diam
    Senior->>Semua: "Sudah cukup jelas sepertinya"
    Lead->>Semua: "Oke, next PR"

Diskusi terjadi, tapi hanya di satu lapisan. Junior engineer ada di ruangan — tapi tidak benar-benar hadir dalam percakapan.

Dua Persona yang Hampir Selalu Muncul

Setelah mengamati banyak sesi code review meeting, ada dua pola perilaku yang hampir selalu muncul, dan keduanya adalah respons wajar terhadap situasi yang tidak kondusif — bukan cerminan karakter individunya.

Persona 1: Junior yang Pasif dan Waspada

Junior engineer di code review meeting seringkali berada dalam mode survival, bukan mode belajar. Mereka hadir secara fisik, mengangguk di momen yang tepat, kadang tersenyum saat ada yang bercanda — tapi pikirannya sedang sibuk dengan kalkulasi risiko sosial.

Bukan risiko teknikal. Risiko sosial.

Pertanyaan yang berputar di kepala mereka bukan “bagaimana cara kerja pattern ini?” tapi “apakah pertanyaan ini akan membuat saya terlihat bodoh?”, “apakah komentar ini akan dianggap tidak relevan?”, atau “apakah senior di sebelah saya akan menganggap saya tidak kompeten kalau saya tidak paham ini?”.

Ini bukan insecurity yang berlebihan. Ini adalah respons yang sangat rasional terhadap lingkungan di mana kesalahan dilakukan di depan publik. Ketika kamu tidak tahu persis di mana batas antara “pertanyaan yang memperlihatkan keingintahuan” dan “pertanyaan yang memperlihatkan ketidakmampuan”, pilihan paling aman adalah diam.

Dan diam adalah cara paling efektif untuk berhenti belajar.

Persona 2: Senior yang Dominan Tanpa Disadari

Senior engineer yang mendominasi code review meeting hampir selalu melakukannya dengan niat baik. Mereka ingin membantu. Mereka punya konteks. Mereka bisa melihat masalah yang tidak terlihat oleh orang lain. Jadi mereka berbicara.

Masalahnya bukan intensinya — masalahnya adalah efeknya.

Setiap kali senior berbicara, ruang bagi orang lain untuk berpikir menyempit. Bukan karena senior memotong pembicaraan, tapi karena dalam percakapan asimetris, volume dan kepercayaan diri yang lebih besar secara natural menarik gravitasi diskusi ke satu titik. Engineer lain mulai menunggu senior selesai berbicara baru mengkonfirmasi, alih-alih mengeksplorasi sendiri.

Yang lebih berbahaya: senior sering memberikan “final answer” terlalu cepat. Sebuah pertanyaan diajukan, senior langsung menjawab dengan solusi terbaik yang ia ketahui — dan diskusi selesai di situ. Padahal nilai terbesar dari code review bukan di jawabannya, tapi di proses mencapai jawabannya.

flowchart TD
    A[Pertanyaan teknikal muncul] --> B{Siapa yang pertama bicara?}
    B -- Senior --> C[Senior memberi jawaban lengkap]
    B -- Junior --> D[Junior mengutarakan hipotesis]
    C --> E[Diskusi selesai — semua setuju]
    D --> F[Senior menanggapi, menambahkan konteks]
    E --> G[Junior tidak punya kesempatan berpikir sendiri]
    F --> H[Junior belajar cara berpikir, bukan hanya jawaban]
    G --> I[Learning dangkal]
    H --> J[Learning mendalam]

Perbedaan antara dua jalur ini bukan soal siapa yang lebih pintar. Ini soal urutan berbicara, dan siapa yang diberi ruang untuk salah terlebih dahulu sebelum dikoreksi.

Tiga Masalah Struktural yang Sering Tidak Disadari

Ketika code review meeting tidak berjalan seperti yang diharapkan, insting pertama biasanya menyalahkan individu: senior yang terlalu dominan, junior yang terlalu pasif, lead yang kurang fasilitasi. Tapi ini adalah kesimpulan yang terlalu mudah dan sering salah.

Masalah sesungguhnya ada di level struktur — bukan di level orang.

1. Power Imbalance yang Terlalu Besar untuk Satu Ruangan

Ketika junior engineer, mid-level engineer, senior engineer, tech lead, dan mungkin engineering manager berada dalam satu ruangan untuk membahas kode, kamu sedang menciptakan kondisi di mana diskusi setara hampir mustahil terjadi secara alami.

Power imbalance dalam tim engineering bukan hanya soal jabatan — ia juga muncul dari:

• Lama pengalaman di industri
• Kedalaman pengetahuan di domain spesifik
• Seberapa lama seseorang ada di tim
• Reputasi teknikal yang sudah terbentuk
• Siapa yang paling sering “benar” di diskusi sebelumnya

Semua faktor ini menciptakan hierarki implisit yang tidak tertulis di mana pun tapi dirasakan oleh semua orang di ruangan. Dan dalam hierarki implisit, orang di posisi lebih bawah tidak akan bicara dengan bebas — terutama untuk mengutarakan ketidaksetujuan atau ketidakpahaman.

Power imbalance tidak bisa diatasi dengan hanya berkata “semua pendapat diterima di sini.” Kata-kata tidak cukup untuk mengubah dinamika sosial yang sudah terbentuk. Dibutuhkan perubahan format, bukan hanya perubahan niat.

2. Code Review Adalah Aktivitas Berpikir, Bukan Aktivitas Rapat

Ada asumsi yang sangat mendasar tapi sangat salah yang tersembunyi di balik weekly code review meeting: bahwa berpikir kritis tentang kode bisa dilakukan secara optimal dalam format rapat dengan waktu terbatas.

Coba bayangkan apa yang dibutuhkan untuk me-review kode dengan baik:

• Memahami konteks bisnis di balik fitur yang dibangun
• Memahami constraint teknikal yang ada saat kode ditulis
• Menelusuri alur logika dari awal sampai akhir
• Membayangkan edge case yang mungkin terjadi
• Membandingkan dengan alternatif implementasi yang mungkin
• Mempertimbangkan dampak ke bagian sistem lainnya

Ini semua adalah aktivitas kognitif yang membutuhkan fokus mendalam, waktu yang fleksibel, dan kebebasan untuk berhenti, berpikir, kembali, dan berpikir lagi. Meeting dengan slot kalender 1 jam tidak bisa mengakomodasi semua ini.

Yang terjadi adalah review menjadi dangkal secara struktural. Bukan karena orangnya tidak kompeten — tapi karena formatnya tidak memberi ruang untuk kedalaman. Review yang terjadi di meeting adalah review yang fokus ke hal yang paling mudah dilihat: penamaan variabel, struktur kode yang tidak konsisten, komentar yang kurang, atau pattern yang familiar. Hal-hal yang lebih dalam — apakah abstraksi ini tepat, apakah boundary antara komponen ini sehat, apakah decision ini akan menciptakan technical debt dalam 6 bulan — hampir tidak pernah dibahas karena butuh waktu lebih dari 1 jam hanya untuk satu PR.

3. Melihat Bukan Berarti Belajar

Ada kepercayaan implisit di balik format “mari kita lihat kode bersama-sama”: bahwa exposure terhadap kode orang lain secara otomatis menghasilkan pembelajaran. Tapi ini adalah logika yang sama dengan percaya bahwa menonton orang berenang akan mengajarkanmu cara berenang.

Pembelajaran yang sesungguhnya membutuhkan lebih dari sekadar melihat. Ia butuh:

• Konteks: mengapa keputusan ini diambil?
• Eksplorasi: apa alternatifnya?
• Kesalahan: apa yang akan terjadi jika ini dilakukan dengan cara yang berbeda?
• Refleksi: apa yang bisa saya terapkan dari ini ke pekerjaan saya sendiri?

Ketika engineer duduk di code review meeting dan melihat kode yang sudah di-explain oleh orang yang menulisnya, sebagian besar dari mereka hanya menerima penjelasan tanpa proses kognitif yang aktif. Mereka tidak belajar cara berpikir tentang kode — mereka hanya menerima kesimpulan tentang kode.

Ketika Fokus Bergeser dari Kode ke Orang

Ada momen yang sangat spesifik ketika code review kehilangan tujuannya, dan momen itu biasanya tidak terjadi secara dramatis — ia terjadi perlahan, hampir tidak terasa, melalui pergeseran bahasa yang sangat halus.

Perhatikan perbedaan dua framing ini:

Framing A (fokus ke sistem):
"PR ini menggunakan eager loading, yang berarti kita fetch semua
relasi sekaligus. Di skenario ini bisa jadi oke, tapi perlu
dipertimbangkan kalau dataset-nya tumbuh."

Framing B (fokus ke orang):
"Kenapa ini pakai eager loading? Ini tidak efisien."

Secara teknikal, keduanya menyampaikan informasi yang sama. Tapi secara psikologis, keduanya menciptakan suasana yang sangat berbeda. Framing A mengundang diskusi. Framing B menciptakan defensiveness.

Dan begitu suasana bergeser ke arah defensiveness, learning culture runtuh. Engineer yang kodenya “dibedah” di depan publik tidak akan pulang dengan semangat untuk menulis kode yang lebih baik — ia pulang dengan keinginan untuk menghindari PR yang terlalu “terlihat” di masa depan.

stateDiagram-v2
    [*] --> ReviewSehat: Fokus ke sistem dan keputusan
    ReviewSehat --> Diskusi: Pertanyaan terbuka diajukan
    Diskusi --> PemahamanBersama: Engineer saling membangun konteks
    PemahamanBersama --> LearningTerjadi: Tim tumbuh bersama

    [*] --> ReviewDisfungsional: Fokus ke kode dan siapa yang menulis
    ReviewDisfungsional --> Defensiveness: Kritik dirasakan sebagai serangan
    Defensiveness --> PenarikanDiri: Engineer memilih diam
    PenarikanDiri --> LearningBerhenti: Tim stagnan

Yang paling berbahaya dari dinamika ini: biasanya tidak ada yang menyadarinya secara eksplisit. Semua orang merasa sesi berjalan “normal”. Diskusi ada. Poin teknikal disampaikan. Tapi di balik itu semua, junior engineer perlahan belajar bahwa yang paling aman adalah membuat kode yang paling tidak kontroversial — bukan kode yang paling tepat untuk masalah yang dihadapi.

Efek Kumulatif yang Tidak Terlihat

Satu sesi code review yang disfungsional tidak langsung merusak tim. Tapi ketika pola yang sama berulang setiap minggu selama berbulan-bulan, efek kumulatifnya bisa sangat serius.

Junior Engineer Berhenti Eksplorasi

Junior yang tumbuh di lingkungan di mana kesalahan dihakimi di depan publik cenderung mengadopsi strategi yang rasional tapi destruktif untuk perkembangan mereka: minimisasi risiko eksposur. Artinya, mereka lebih memilih solusi yang paling “aman” dan paling familiar — bukan karena itu yang terbaik, tapi karena itu yang paling mudah dipertahankan kalau ditanya di code review.

Eksplorasi berhenti. Kreativitas mengecil. Dan setelah beberapa tahun, kamu punya senior engineer yang sangat baik dalam mengikuti pattern yang sudah ada, tapi tidak terbiasa berpikir dari pertama prinsip.

Senior Engineer Kehilangan Challenge

Paradoksnya, environment yang membuat junior engineer diam juga merugikan senior engineer. Ketika tidak ada yang berani mengajukan pertanyaan naif, senior kehilangan kesempatan untuk menguji apakah asumsi-asumsinya masih valid.

Pertanyaan “naif” dari junior sering kali adalah pertanyaan yang paling tajam: “Kenapa kita melakukan ini seperti ini?” adalah pertanyaan yang seharusnya diajukan secara teratur, tapi di lingkungan yang tidak aman, tidak ada yang mau mengajukannya.

Senior engineer yang tidak pernah di-challenge cenderung mengkalsifikasi — cara berpikirnya menjadi rigid, pattern yang ia favoritkan menjadi satu-satunya pattern yang ia rekomendasikan, dan konteks yang ia pertimbangkan menyempit ke apa yang sudah ia kenal.

Tim Kehilangan Ruang Perbedaan Pendapat yang Sehat

Organisasi yang sehat membutuhkan ruang di mana orang bisa tidak setuju tanpa konsekuensi sosial. Code review meeting yang disfungsional secara perlahan menghilangkan ruang itu. Engineer belajar bahwa menyetujui lebih aman dari pada berdebat, bahwa diam lebih aman dari pada bertanya, dan bahwa konformitas lebih dihargai dari inovasi.

Hasilnya adalah tim yang tampak harmonis di permukaan tapi sebenarnya tidak punya mekanisme untuk mendeteksi dan memperbaiki kesalahan arsitekturalnya sendiri.

Apa yang Sebenarnya Dibutuhkan Tim

Memahami masalah struktural di atas membantu kita merancang alternatif yang lebih tepat. Bukan untuk menghapus code review — tapi untuk memisahkan tujuan-tujuan yang selama ini dijejali ke dalam satu format yang tidak mampu menampungnya.

Async Review sebagai Default

Code review yang paling efektif adalah code review yang terjadi ketika reviewer punya waktu dan fokus untuk benar-benar berpikir. Artinya async, bukan meeting.

Reviewer yang membuka PR di waktu yang ia pilih sendiri, tanpa tekanan sosial ruangan, dan dengan waktu yang cukup untuk menelusuri konteks, akan memberikan review yang jauh lebih substansial dibanding reviewer yang melihat kode untuk pertama kalinya di depan semua orang.

Ini bukan berarti tidak ada diskusi. Ini berarti diskusi terjadi via komentar, yang punya sifat yang sangat berbeda dari diskusi oral: lebih tertulis, lebih bisa dipikirkan sebelum disampaikan, dan lebih bisa dijadikan referensi ke depannya.

Pisahkan Knowledge Sharing dari Code Review

Jika tujuannya adalah learning bersama, gunakan format yang memang dirancang untuk itu: tech talk, architecture discussion, atau lesson learned session. Format ini berbeda dari code review dalam satu hal yang krusial: fokusnya bukan pada kode spesifik yang ditulis seseorang, tapi pada konsep, pattern, atau keputusan yang ingin dibagikan.

Ketika kamu memisahkan “ini adalah kode yang ditulis si A” dari “ini adalah pattern yang ingin kita diskusikan”, psychological safety langsung meningkat secara dramatis. Diskusi menjadi tentang ide, bukan tentang orang.

flowchart LR
    A[Code Review] --> B[Async PR Review]
    A --> C[Pair Programming]

    D[Knowledge Sharing] --> E[Tech Talk]
    D --> F[Architecture Decision Record]
    D --> G[Lesson Learned Session]

    H[Alignment Standar] --> I[Linter dan Static Analysis]
    H --> J[Team Convention Doc]
    H --> K[RFC Process]

    style A fill:#fff3e0,stroke:#fb8c00
    style D fill:#e8f5e9,stroke:#43a047
    style H fill:#e3f2fd,stroke:#1e88e5

Tiga tujuan yang sering dijejali ke satu weekly meeting sebenarnya butuh tiga format yang berbeda. Ketika kamu memisahkan ketiganya, setiap format bisa dioptimalkan untuk tujuannya masing-masing.

Buat Psychological Safety Jadi Prioritas Eksplisit

Psychological safety bukan sesuatu yang terjadi secara otomatis karena “tim kita terbuka”. Ia dibangun melalui sinyal-sinyal konkret yang dikirim secara konsisten oleh orang-orang dengan kekuasaan terbesar di dalam tim.

Beberapa sinyal konkret yang bisa dikirim:

• Senior engineer yang secara publik bertanya “aku tidak yakin ini cara terbaik, ada yang punya pandangan lain?” — ini memberi izin implisit kepada junior untuk juga tidak pasti.
• Lead yang merespons pertanyaan “naif” dengan antusias dan terima kasih, bukan dengan penjelasan yang membuat penanya merasa bodoh.
• Review komentar yang selalu dimulai dengan memahami konteks sebelum memberikan saran — “aku melihat ini menggunakan X, ada alasan spesifik? kalau tidak ada constraint, Y mungkin lebih mudah di-maintain.”

Tidak ada formula ajaib di sini. Tapi prinsipnya konsisten: sinyal bahwa tidak tahu adalah titik awal yang valid, bukan kelemahan yang perlu disembunyikan.

Membedakan Code Review yang Sehat dan Tidak

Tidak semua code review meeting buruk. Ada sesi yang berjalan dengan sangat baik. Kuncinya adalah bisa mengenali perbedaannya.

Perhatikan baris terakhir dengan seksama. Cara tim memperlakukan kesalahan adalah indikator paling akurat tentang apakah learning culture-nya sehat atau tidak. Bukan seberapa sering mereka mengadakan sesi review, bukan seberapa senior reviewer-nya, dan bukan seberapa detail komentar yang diberikan.

“Blame-free post-mortem” adalah konsep yang populer untuk insiden produksi — tapi prinsip yang sama berlaku untuk code review. Review yang fokus ke “bagaimana sistem ini bisa lebih baik” selalu lebih produktif dari review yang fokus ke “kenapa ini ditulis seperti ini”.

Pelajaran untuk Engineer di Semua Level

Refleksi ini bukan hanya untuk tech lead atau engineering manager. Ada pelajaran spesifik untuk setiap posisi.

Untuk Junior Engineer

Kalau kamu merasa code review meeting menegangkan, kamu tidak sendiri dan kamu tidak salah. Itu adalah respons yang wajar terhadap format yang memang tidak dirancang untuk kenyamananmu. Yang bisa kamu lakukan: cari reviewer yang kamu percaya dan mulai diskusi via komentar async sebelum sesi — ini cara yang jauh lebih aman untuk mengeksplorasi pemahaman tanpa tekanan publik.

Yang lebih penting: bedakan antara pertanyaanmu sendiri yang belum dijawab dan pertanyaan yang sudah dijawab tapi kamu tidak paham jawabannya. Keduanya valid untuk ditanyakan. Ketidakpahaman bukan kelemahan — itu sinyal bahwa penjelasannya perlu diperbaiki.

Untuk Senior Engineer

Kemampuan teknikal kamu sangat berharga. Tapi dalam sesi diskusi, kemampuan yang paling dibutuhkan dari kamu bukan kemampuan memberi jawaban yang benar — melainkan kemampuan mengajukan pertanyaan yang membuat orang lain berpikir lebih dalam.

Coba eksperimen sederhana: di sesi review berikutnya, tahan diri untuk tidak menjadi yang pertama bicara. Biarkan orang lain mengisi kekosongan. Kamu mungkin akan terkejut dengan kualitas pemikiran yang muncul ketika ruang itu tersedia.

Untuk Tech Lead dan Engineering Manager

Format code review meeting yang kamu pilih mengirimkan sinyal yang lebih kuat dari apapun yang kamu katakan tentang learning culture. Kalau kamu bilang “semua pendapat sama berharganya” tapi formatnya menempatkan semua orang dalam satu ruangan dengan hierarki yang jelas, pesan yang diterima adalah pesan yang kedua.

Pertanyaan yang layak diajukan secara rutin: siapa yang berbicara di sesi terakhir, dan siapa yang tidak? Apakah distribusinya mencerminkan tim yang sehat?

Ringkasan

• Niat baik tidak menjamin format yang sehat — weekly code review meeting dibuat dengan tujuan mulia, tapi formatnya bisa menciptakan efek yang berlawanan dengan tujuannya.
• Masalahnya ada di struktur, bukan individu — junior yang pasif dan senior yang dominan adalah respons rasional terhadap lingkungan yang tidak dirancang untuk kesetaraan. Jangan salahkan orangnya, ubah formatnya.
• Power imbalance tidak bisa dinetralisir dengan kata-kata — selama semua level hierarki berada dalam satu ruangan untuk membahas kode, diskusi yang benar-benar setara hampir mustahil terjadi secara alami.
• Code review butuh fokus mendalam, bukan slot kalender — review yang baik membutuhkan waktu untuk memahami konteks, menelusuri logika, dan membayangkan edge case. Format meeting tidak bisa mengakomodasi ini.
• Pisahkan tiga tujuan ke tiga format — code review (async PR), knowledge sharing (tech talk, lesson learned), dan alignment standar (linter, convention doc, RFC) butuh format yang berbeda karena tujuannya berbeda.
• Psychological safety adalah fondasi learning — tanpa rasa aman untuk salah dan tidak tahu, tidak ada pertanyaan, tidak ada diskusi, dan tidak ada pertumbuhan. Ia dibangun lewat sinyal konsisten dari orang dengan kekuasaan terbesar di tim.
• Bedakan fokus ke sistem vs fokus ke orang — “kenapa ini ditulis seperti ini?” dan “ada trade-off menarik di keputusan ini” membahas topik yang sama tapi menciptakan suasana yang sangat berbeda.
• Kesalahan adalah indikator culture terbaik — cara tim memperlakukan kesalahan di code review mencerminkan apakah learning culture-nya sehat lebih akurat dari metrik apapun.