Mengapa Insinyur Hebat di Perusahaan Besar Menulis Kode Buruk

• Karena masa kerja yang singkat dan restrukturisasi organisasi yang sering di perusahaan teknologi besar, banyak insinyur bekerja pada codebase yang tidak mereka kenal
• Kenyataan bahwa sebagian besar perubahan kode dilakukan oleh insinyur tingkat ‘pemula’ yang baru bergabung kurang dari 6 bulan
• Sejumlah insinyur berpengalaman ‘old hand’ membantu menjaga kualitas, tetapi mereka memiliki keterbatasan karena beban kerja berlebih dan tanggung jawab informal
• Perusahaan lebih mengutamakan mobilitas tenaga kerja dan keterbacaan internal (legibility) daripada keahlian, dan ini adalah harga dari penurunan kualitas yang disengaja
• Pada akhirnya, terlepas dari kemampuan masing-masing insinyur, masalah struktural berupa bekerja cepat demi tenggat di sistem yang asing adalah akar penyebab kode buruk

---

Struktur yang Membuat Kode Buruk Muncul di Perusahaan Besar

• Perusahaan teknologi besar merekrut insinyur hebat dengan gaji tinggi, tetapi masa kerja mereka sering hanya 1–2 tahun
  • Struktur kompensasi saham (share grant) yang baru sepenuhnya vested setelah 4 tahun membuat gaji efektif turun setengahnya setelah itu
  • Ada refresh tahunan dalam beberapa kasus, tetapi tidak dijamin, sehingga insinyur memilih pindah kerja
• Bahkan jika menghitung perpindahan internal, jarang ada yang bertahan lebih dari 3 tahun di satu codebase
  • Re-org terjadi setiap tahun, atau bahkan lebih sering
• Sementara itu, codebase sering dipertahankan lebih dari 10 tahun, sehingga kebanyakan insinyur selalu berada dalam proses ‘mempelajari’ sistem baru
  • Akibatnya, sebagian besar perubahan kode dilakukan oleh pemula yang baru masuk kurang dari 6 bulan

Peran dan Batasan ‘Old Hand’

• Beberapa insinyur bertahan lama di sistem tertentu dan membangun keahlian yang mendalam
  • Mereka dapat menemukan masalah lebih awal melalui code review
• Namun struktur ini bersifat informal dan tidak diinstitusikan
  • Perusahaan kurang berminat mempertahankan keahlian jangka panjang, dan insinyur berpengalaman sering dipindahkan ke tim lain
• Insinyur berpengalaman selalu dibebani pekerjaan berlebih
  • Tidak punya cukup waktu untuk meninjau semua perubahan secara langsung
  • Jika output kerja mereka sendiri menurun, mereka justru berisiko dirugikan

Realitas Insinyur Produktif Rata-Rata

• Insinyur produktif rata-rata di perusahaan besar memiliki ciri-ciri berikut
  • Cukup mampu untuk lolos standar rekrutmen, tetapi tidak akrab dengan codebase atau bahasa yang baru
  • Bekerja sambil memenuhi tenggat yang saling tumpang tindih dari beberapa proyek sekaligus
• Akibatnya, mereka bekerja sebaik mungkin dalam lingkungan yang berorientasi jadwal, bukan kualitas
  • Contoh: insinyur pemula memperbaiki bug di kode yang asing dengan solusi sementara, lalu insinyur berpengalaman meninjaunya secara singkat sebelum dirilis
  • Beberapa tahun kemudian, kode itu ditemukan kembali dan orang bertanya, “mengapa kode seperti ini ditulis?”

Mengapa Perusahaan Mempertahankan Struktur Ini

• Perusahaan besar lebih mementingkan keterbacaan internal (legibility) daripada produktivitas
  • Mereka lebih menyukai struktur yang membuat siapa mengerjakan apa terlihat jelas, dan memungkinkan pemindahan orang kapan saja
• Ini adalah pilihan sadar yang mengorbankan keahlian dan kualitas kode
  • Mereka menerima hilangnya kemahiran demi mendapatkan fleksibilitas untuk merelokasi tenaga kerja dengan cepat saat masalah muncul
• Terutama ketika pivot cepat ke bidang baru seperti AI menjadi penting, strategi ini bekerja menguntungkan perusahaan
• Namun dalam lingkungan seperti ini, semakin banyak insinyur yang harus bekerja tergesa-gesa di sistem yang asing

Batasan Individu Insinyur dan Rekayasa ‘Murni/Tidak Murni’

• Insinyur individu tidak punya kekuatan untuk mengubah struktur ini
  • Pada 2025, pusat kekuasaan telah bergeser dari insinyur ke manajemen
  • Hal terbaik yang bisa dilakukan individu adalah menjadi ‘old hand’ di area tertentu dan menjaga kualitas seminimal mungkin
• Namun keterlibatan yang terlalu besar justru bisa membuat mereka dinilai berkinerja kurang (PIP)
• Tulisan ini mengajukan perbedaan antara rekayasa ‘murni (pure)’ dan ‘tidak murni (impure)’
  • Rekayasa murni: berfokus pada proyek teknis yang independen (misalnya pengembangan bahasa pemrograman)
  • Rekayasa tidak murni: lingkungan nyata yang berorientasi tenggat saat bekerja di sistem yang asing
• Sebagian besar insinyur di perusahaan besar berada dalam rekayasa tidak murni, dan dalam konteks ini kode buruk adalah produk sampingan yang tak terelakkan
  • Jika sistem berjalan cukup baik, proyek dianggap berhasil

Kesimpulan: ‘Codebase Asing’ sebagai Penyebab Struktural

• Perusahaan besar memiliki kewenangan untuk memindahkan insinyur secara bebas, dan itu adalah pilihan perusahaan yang menerima hilangnya keahlian
• Tanggung jawab atas kode buruk bukan ada pada individu, melainkan pada struktur organisasi dan cara tenaga kerja dikelola
• Bahkan jika kemampuan semua insinyur dilipatgandakan, kesalahan di codebase yang asing akan tetap terjadi
• Akar masalahnya adalah “struktur di mana kebanyakan insinyur harus melakukan sebagian besar pekerjaannya pada kode yang tidak mereka kenal”
• Menunjukkan contoh kode buruk bisa membantu perbaikan, tetapi yang patut disalahkan bukan insinyurnya, melainkan sistemnya