Ketika Code Review Berubah Menjadi Judgment
4 min read Software Engineering

Ketika Code Review Berubah Menjadi Judgment

Beberapa waktu lalu, saya masuk ke sebuah tim engineering dengan satu praktik yang sudah berjalan sebelum saya bergabung: weekly code review meeting selama 1 jam.

Tujuannya terdengar sangat baik.

Praktik ini dibuat dengan maksud:

  • Supaya engineer lain tahu bagaimana kode ditulis
  • Supaya bisa menjadi pembelajaran bersama
  • Supaya ada alignment dan standar kualitas yang sama

Secara niat, saya sepakat. Namun setelah beberapa kali menjalankan sesi tersebut, saya mulai melihat sesuatu yang mengganggu — bukan secara teknis, tapi secara manusia dan sistem.

Artikel ini adalah refleksi jujur dari pengalaman tersebut, sekaligus lanjutan dari artikel sebelumnya: “Perlukah Code Review Dilakukan Lewat Meeting?” (yang membahas prinsip dan best practice code review secara umum).

Artikel ini fokus pada apa yang terjadi di dunia nyata, ketika praktik yang niatnya baik justru menghasilkan efek sebaliknya.

Apa yang Saya Lihat di Lapangan

Secara kasat mata, sesi weekly code review berjalan “normal”:

  • Semua engineer hadir
  • Kode dibuka di layar
  • Diskusi terjadi
  • Waktu habis satu jam

Namun jika diperhatikan lebih dalam, polanya selalu sama.

Engineer Junior: Pasif dan Takut

Junior engineer:

  • Jarang berbicara
  • Hampir tidak pernah bertanya
  • Lebih sering diam atau hanya mengangguk

Bukan karena mereka tidak peduli, tapi karena:

  • Takut terlihat bodoh
  • Takut kodenya “dibedah” di depan banyak orang
  • Takut salah bicara di hadapan engineer yang lebih senior

Begitu psychological safety hilang, proses belajar berhenti.

Engineer Senior: Dominan (Sering Tanpa Disadari)

Senior engineer sering:

  • Mendominasi diskusi
  • Memberi opini sebagai “final answer”
  • Mengoreksi langsung di forum publik

Walaupun niatnya membantu, secara tidak sadar:

  • Diskusi berubah menjadi satu arah
  • Junior belajar untuk diam, bukan berpikir
  • Code review terasa seperti penghakiman, bukan kolaborasi

Meeting Menjadi Panggung, Bukan Ruang Belajar

Yang seharusnya terjadi:

“Mari kita pahami sistem ini bersama”

Yang terjadi:

“Kode ini ditulis begini, dan ini kurang tepat”

Fokus perlahan bergeser:

  • Dari kode → ke orang
  • Dari sistem → ke siapa yang salah

Dan begitu itu terjadi, value code review runtuh.

Kenapa Ini Terjadi? (Bukan Salah Individu)

Ini penting: ini bukan salah individu tertentu, bukan salah junior, bukan salah senior.

Masalahnya ada pada format, bukan orang.

Berdasarkan prinsip yang saya bahas di artikel sebelumnya:

Code review adalah aktivitas berpikir mendalam, bukan aktivitas rapat.

Weekly meeting 1 jam menciptakan beberapa masalah struktural:

Power Imbalance Terlalu Besar

Saat:

  • Junior
  • Senior
  • Lead
  • Engineer berpengalaman

berada di satu ruangan, diskusi teknis hampir mustahil setara.

Ada tekanan implisit yang membuat sebagian orang:

  • Diam
  • Mengalah
  • Tidak berani mengutarakan pandangan berbeda

Code Review Butuh Waktu Fokus, Bukan Slot Kalender

Review kode yang baik:

  • Butuh konteks
  • Butuh eksplorasi
  • Butuh ketenangan

Meeting dengan waktu terbatas memaksa review menjadi:

  • Dangkal
  • Reaktif
  • Fokus ke hal yang “kelihatan”, bukan yang penting

Learning Tidak Terjadi Lewat Exposure Massal

Melihat kode orang lain bukan berarti belajar.

Tanpa konteks:

  • Masalah apa yang sedang diselesaikan
  • Constraint apa yang ada
  • Kenapa decision tertentu diambil

Sebagian besar engineer hanya “menonton”, bukan memahami.

Saat Code Review Kehilangan Tujuannya

Di titik ini, saya menyadari sesuatu yang cukup mengganggu:

Code review ini tidak lagi tentang meningkatkan kualitas sistem, tapi perlahan berubah menjadi mekanisme judgment.

Bukan karena ada niat buruk, tapi karena formatnya mendorong ke arah itu.

Dan yang paling berbahaya:

  • Junior tidak berkembang
  • Senior tidak mendapatkan challenge
  • Tim kehilangan ruang diskusi sehat

Pelajaran yang Saya Ambil

Dari pengalaman ini, ada beberapa pelajaran penting yang ingin saya bagikan ke engineer lain.

Niat Baik Tidak Menjamin Praktik yang Sehat

“Knowledge sharing” adalah tujuan mulia, tapi alat yang salah bisa merusak tujuan itu sendiri.

Psychological Safety Adalah Fondasi Learning

Tanpa rasa aman:

  • Tidak ada pertanyaan
  • Tidak ada diskusi
  • Tidak ada pembelajaran

Dan forum publik adalah tempat paling rapuh untuk itu.

Code Review Bukan Media Utama untuk Learning Massal

Code review cocok untuk:

  • Quality control
  • Knowledge transfer terbatas
  • Diskusi spesifik

Bukan untuk:

  • Kelas bersama
  • Evaluasi publik
  • Unjuk standar

Alternatif yang Lebih Sehat (Tetap Menjaga Tujuan Awal)

Tanpa mengulang detail teknis (dibahas di artikel sebelumnya), saya percaya pendekatan ini lebih efektif:

  1. Async code review sebagai default
  2. Meeting hanya untuk:
    • Design decision
    • Lesson learned
    • Pattern sharing
  3. Fokus ke “apa yang kita pelajari”, bukan “kode siapa”

Dengan begitu:

  1. Junior berani bicara
  2. Senior menjadi mentor, bukan hakim
  3. Meeting benar-benar bernilai

Penutup

Saya menulis ini bukan untuk mengkritik individu atau organisasi tertentu, tapi karena saya yakin banyak engineer mengalami hal yang sama — dan memilih diam.

Jika kamu pernah merasa:

  • Code review terasa menegangkan
  • Meeting terasa tidak produktif
  • Learning tidak benar-benar terjadi

Mungkin masalahnya bukan pada orang-orangnya, tapi pada format yang kita anggap “sudah seharusnya begitu”.

Kadang, memperbaiki budaya engineering tidak dimulai dari kode, tapi dari cara kita berbicara tentang kode.