Hai, Software Engineers!

Menjalani sidang skripsi atau code review pertama di kantor sering kali terasa seperti sedang duduk di kursi pesakitan. Kamu sudah begadang berminggu-minggu, aplikasi sudah jalan tanpa error, tapi tiba-tiba penguji atau senior bertanya: “Kenapa kamu pakai arsitektur ini? Kenapa nggak pakai yang itu saja?”

Seketika, keringat dingin mengucur. Padahal, rahasia sukses menghadapi momen ini bukan terletak pada seberapa canggih aplikasimu, melainkan pada kemampuanmu menjelaskan isi kepala di balik setiap baris kode tersebut.

Berikut adalah panduan sederhana untuk membantumu mempersiapkan mental dan teknik saat harus mempertahankan argumen teknismu.

  1. Pahami Bahwa “Kamu Bukan Kodemu”

Hal pertama yang harus diperbaiki adalah mentalitas. Banyak pengembang pemula merasa dikritik secara pribadi saat kodenya dibedah. Padahal, dalam dunia profesional, ulasan kode adalah jaring pengaman bersama, bukan ajang penghakiman.

Ada istilah medis bernama amygdala hijack, kondisi di mana otak merasa terancam sehingga kita bereaksi defensif atau malah mendadak blank. Untuk mengatasinya, tanamkan prinsip: You are not your code. Kritik pada struktur datamu bukan berarti kamu orang yang bodoh. Pisahkan harga dirimu dari sintaks yang kamu tulis agar kamu bisa menjawab dengan logika, bukan emosi.

  1. Hukum Utama: “Semuanya Adalah Kompromi”

Dalam rekayasa perangkat lunak, tidak ada solusi yang 100% sempurna untuk segala situasi. Segala sesuatu adalah kompromi atau trade-off.

Misalnya, kalau kamu memilih arsitektur yang sangat cepat, mungkin biaya infrastrukturnya lebih mahal. Kalau kamu memilih sistem yang sangat aman, mungkin akses penggunanya jadi sedikit lebih lambat. Penguji atau senior tidak mencari jawaban “mana yang terbaik secara absolut,” mereka ingin tahu apakah kamu sadar apa yang kamu korbankan saat memilih solusi tersebut. Jangan pernah bilang “ini yang terbaik,” tapi katakanlah “ini yang paling pas untuk konteks masalah ini karena…”.

  1. Siapkan “Buku Sakti” Bernama ADR

Pernahkah kamu lupa alasan memilih sebuah teknologi setelah lewat satu bulan? Untuk menghindari momen “lupa ingatan” saat sidang, gunakan Architecture Decision Record (ADR).

ADR sesederhana catatan ringkas yang berisi:

  • Masalah yang dihadapi.
  • Pilihan solusi yang sempat dipikirkan.
  • Alasan kenapa satu solusi akhirnya dipilih.
  • Risiko atau efek samping dari pilihan tersebut.

Memiliki catatan sejarah keputusan ini akan membuatmu terlihat sangat profesional karena argumenmu berbasis data historis, bukan sekadar perasaan.

  1. Belajar Bahasa “Bilingual”

Seorang insinyur perangkat lunak yang hebat harus bisa bicara dalam dua bahasa: bahasa teknis dan bahasa dampak (bisnis/manfaat).

Jangan cuma bilang, “Saya pakai sistem asinkron agar tidak terjadi blocking.” Coba ubah menjadi, “Saya pakai sistem asinkron agar pengguna tidak perlu menunggu lama saat proses checkout, sehingga mereka tidak membatalkan pesanannya”. Menghubungkan pilihan teknis dengan manfaat nyata akan membuat argumenmu jauh lebih sulit dipatahkan.

  1. Gunakan Strategi Piramida saat Menjawab

Saat ditekan dengan pertanyaan sulit, jangan bertele-tele menceritakan prosesmu dari awal. Gunakan prinsip piramida: berikan kesimpulan di detik pertama, baru jelaskan alasannya.

  • Puncak Piramida: Jawab langsung intinya. “Saya memilih Basis Data NoSQL.”
  • Tengah: Berikan argumen pendukung. “Karena data katalog produk kita sangat dinamis dan skemanya sering berubah tiap minggu.”
  • Dasar: Berikan fakta/data. “Berdasarkan pengujian saya, penggunaan SQL di kasus ini malah memperlambat proses update data hingga 40%”.

Sidang kode atau review dari senior sebenarnya adalah sebuah diskusi untuk mencari kebenaran, bukan mencari siapa yang menang. Dengan persiapan mental yang tenang, pemahaman mendalam tentang kompromi teknis, dan gaya komunikasi yang lugas, kamu bukan lagi sekadar pengetik kode, tapi seorang engineer sejati yang bertanggung jawab penuh atas setiap keputusan yang diambil.

 

References

https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/

https://adr.github.io/

https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method

https://dev.to/devcorner/the-first-law-of-software-architecture-understanding-trade-offs-2bef