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

[sonnet]

Berdasarkan pengalaman saya, jika fondasi CS, khususnya PLT, kuat, pada akhirnya orang akan menulis kode yang relatif lebih baik di lingkungan apa pun.

Meski tidak punya pengetahuan yang luar biasa, orang yang setidaknya memahami prinsip-prinsip paling dasar akan menghasilkan kualitas kode yang lumayan jika diberi cukup waktu dan mengerjakan kode yang sudah familier. Kalau direfaktor sampai n kali, bahkan kode yang ditulis AI pun bisa terlihat cukup masuk akal.

Sebaliknya, ada juga banyak orang yang meski sudah 20 tahun berkarier, tetap hanya bisa menghasilkan spaghetti code, walau sudah lama berkutat dengan satu source code, dan bahkan tidak paham kenapa seharusnya tidak begitu.

Selama tidak mungkin diberi lingkungan yang sempurna serta waktu dan anggaran tanpa batas, ini terasa seperti pembahasan hampa yang tidak terlalu bermakna. Bukankah ini sama saja untuk profesi apa pun, di era mana pun?

Menulis kode yang lebih baik dalam sistem yang sama jelas merupakan kemampuan seorang engineer.

[sonnet]

Akan bagus jika sistem disusun dengan cukup longgar dan fleksibel agar bisa memberikan kualitas yang baik. Dan tentu saja, dibandingkan dengan masa ketika rekayasa organisasi dan metodologi pengembangan belum semaju sekarang, rata-ratanya mungkin memang lebih demikian.

Namun, di mata saya, ini terdengar seperti orang yang ego-identitasnya sebagai engineer membesar, tetapi rasa tanggung jawabnya sebagai anggota organisasi kurang, lalu beralasan bahwa semua ini bukan salah dirinya melainkan kesalahan manajemen.

Apakah insinyur bangunan, desainer industri, dan animator tidak punya tenggat, serta dinilai hanya dari kreativitas dan kualitas, bukan produktivitas, sementara hanya programmer saja yang punya tenggat?

[wahihi]

Jauh banget meleset semua.. soal kode buruk atau kode bagus itu omongan anak-anak junior, yang lebih penting adalah ada atau tidak senior yang benar-benar bisa merancang perangkat lunak dengan baik sesuai bidang industrinya..

[sonnet]

Tulisan yang muncul di sini umumnya bisa jadi berasal dari lingkungan yang agak berbeda dibanding sebagian sudut pandang atau pengalaman di pasar SI domestik yang bahkan mengabaikan OCP.

Bagaimanapun juga, Linus Torvalds bukan junior...

[GN⁺]

Pendapat Hacker News

• Saya sudah beberapa kali membaca tulisan orang ini, dan selalu ada rasa tidak nyaman yang tertinggal
  Sekarang saya rasa saya tahu alasannya. Analisis tulisannya sendiri memang logis, tetapi di dasarnya tampak ada semacam nihilisme
  Mungkin dia dulu seorang idealis, tetapi karena pengalaman buruk, kini mencoba menjelaskan bahwa ‘mempercayai sesuatu itu sia-sia’
  Karena itu muncul pertanyaan seperti ini — mengapa perusahaan besar harus bertindak seperti ini, mengapa kode buruk menyiksa engineer, apakah perasaan itu benar-benar salah, ataukah ini akibat struktur ekonomi tempat kita hidup, atau justru tunduk pada kekuatan besar itulah yang disebut kedewasaan

  • Kenapa kode buruk terasa begitu mengganggu?
    Karena saya harus bertanggung jawab atas akibatnya.
    Jadwal mundur karena saya harus memperbaiki kode berantakan buatan orang lain, dan akibatnya penilaian akhir tahun saya juga dipotong
    Saya ditanya, “kenapa lama sekali?”, padahal itu karena saya harus mengorek tumpukan sampah untuk menemukan masalahnya
    Selama bertahun-tahun saya berusaha membuat manajemen memahami masalah seperti ini, tetapi pada akhirnya rasanya seperti kerja Sisifus
  • Alasan engineer membenci kode buruk adalah karena jiwa craftsmanship
    Seperti arsitek yang frustrasi melihat bangunan asal-asalan, atau sutradara film yang tersiksa melihat film yang ceroboh, engineer yang baik mengejar hasil yang matang
    Menurut saya, kedewasaan bukan berarti pasrah pada ketidakberdayaan, melainkan tetap berjuang sebisa mungkin
    Menariknya, penulis disebut nihilis, tetapi gagasan bahwa ‘dunia tidak bisa dikendalikan’ itu sendiri sudah bersifat nihilistis
  • Engineer dan bisnis mendefinisikan standar ‘kode buruk’ secara berbeda
    Dulu saya juga menganggap kode yang tidak sempurna sebagai kode buruk, tetapi setelah melewati beberapa perusahaan, sudut pandang saya berubah
    Sekarang saya melihat bahwa selama tujuan bisnis terpenuhi dan standar kualitas minimum terlewati, itu sudah cukup baik
    Pada akhirnya, hampir semua kode memang selalu punya ruang untuk diperbaiki
  • Saat pertama kali melihat blog ini, saya merasa lega karena “ternyata bukan cuma saya”
    Saya bisa relate karena dia menggambarkan realitas pahit Staff+ engineering apa adanya
    Klaim “lakukan saja yang perusahaan mau, meskipun itu tidak benar” memang sinis, tetapi menurut saya masih lebih baik daripada tergilas roda gigi perusahaan
  • Sepertinya Anda terlalu menafsirkan penulis ini
    Dia hanya tidak percaya pada idealisme Anda, dan itu tidak otomatis berarti nihilisme

• Menurut saya masalahnya bukan masa kerja, melainkan soal motivasi
  Ini mengingatkan pada dialog film Office Space: “kalau kerja keras pun tidak ada imbalannya, motivasi tidak akan muncul”

  • Engineer di perusahaan besar sebenarnya sangat termotivasi (saya engineer di Google)
    Tetapi manajemen lebih mementingkan hasil daripada kode yang baik
    Karena mereka tidak bisa menilai nilai maintenance, pekerjaan itu jadi tidak dihargai
    Pada akhirnya, orang yang merilis kode asal-asalanlah yang malah naik jabatan
  • Motivasi saja tidak cukup
    Saya peduli pada tim dan kode, dan bekerja dengan teliti, tetapi pada akhirnya saya dinilai dengan metrik sederhana seperti jumlah PR
    Tingkat kesulitan kode atau kontribusi terhadap tim diabaikan, dan hanya “angka yang terlihat” yang dianggap penting
    Ironisnya, atasan yang menilai saya itu sendiri dipecat beberapa bulan kemudian
    Ironisnya lagi, kalau saya cuek, mungkin saya tidak akan terluka oleh hal seperti ini

• Perusahaan besar memperlakukan engineer sebagai sumber daya yang bisa diganti
  Ini bukan semata soal efisiensi, melainkan strategi untuk memiringkan keseimbangan kekuasaan ke pihak manajemen
  Tujuannya agar proyek inti tidak bergantung pada kelompok engineer tertentu

  • Modal ingin melemahkan kekuatan tenaga kerja meski harus mengorbankan sebagian efisiensi
    Mereka ingin semua pekerja bisa digantikan
  • Namun dalam praktiknya, jarang ada perusahaan yang sengaja memindahkan engineer terampil ke tim lain
    Justru sering kali mereka berusaha mempertahankan engineer yang bagus
  • Faktanya, sesama engineer juga sering mengecam “kode yang cuma Bob yang paham”
    Artinya, budaya seperti ini bukan hanya masalah manajemen

• Saya sering melihat kasus ketika sintaks dan struktur kodenya tampak sesuai teori, tetapi pendekatan dasarnya justru salah
  Code review hanya fokus pada sintaks, sementara masalah bisnis atau kompleksitas tidak dibahas
  Dalam jangka pendek mungkin terlihat baik-baik saja, tetapi dalam jangka panjang utang teknis akan meledak

  • Sangat setuju. Hal seperti skema database dibekukan pada sprint pertama, lalu setelah itu sama sekali tidak pernah direfaktor
    Akibatnya, perdebatan kecil soal kualitas kode bisa menunda PR berhari-hari
  • Saya melihat hal yang sama di perusahaan besar
    Semua orang terobsesi hanya pada kebersihan kode di permukaan
    Menilai validitas logis atau melihat gambaran besar itu sulit, dan sering kali reviewer juga tidak paham konteksnya
  • Jika penggalian requirement, dokumentasi, dan desain produk kurang baik, akan sulit membuat desain yang bisa dipelihara dalam jangka panjang
    Jika seluruh organisasi tidak punya ruang untuk menerima feedback seperti ini, pada akhirnya mereka akan bergantung pada ‘sistem yang sekadar jalan’
  • Jika masalah arsitektur baru ditemukan saat code review, berarti sudah gagal di tahap proses
    Desain besar seharusnya ditinjau sebelum code review
  • Pola seperti ini juga sering terlihat pada kode hasil generasi AI
    Dengan kata lain, kita sedang mengotomatiskan biaya jangka panjang

• Perusahaan besar tidak terlalu peduli pada kode itu sendiri
  Kode hanyalah media yang membuat perusahaan bisa berjalan
  Pada akhirnya yang penting bukan kodenya, melainkan prosesnya
  Intinya adalah apakah ada prosedur untuk memulihkan sistem ketika sistem itu rusak

• Semua industri membuat kompromi yang mirip ketika skalanya membesar
  Bukan kesempurnaan, melainkan kualitas yang ‘cukup baik’ yang menghasilkan keuntungan
  Seperti perbedaan antara kursi IKEA dan kursi Herman Miller, hanya saja batasannya berbeda
  Kemampuan yang sesungguhnya adalah mengetahui di mana harus berkompromi
  Struktur perusahaan besar memaksa engineer melakukan kompromi seperti ini

• Engineer senior yang baik tidak menulis kode buruk sejak awal
  Masalah sebenarnya adalah tekanan pada hasil jangka pendek dan kurangnya fondasi dasar
  Penyebab yang sesungguhnya adalah melewatkan review atau tidak memikirkan arsitektur dengan cukup matang

  • Tetapi kenyataannya, kadang keadaan sudah terlalu berantakan sehingga menulis kode yang baik pun tidak memungkinkan
    Seperti digambarkan dalam komentar ini, di atas basis kode dengan jutaan baris hack yang menumpuk, sekeras apa pun usaha kita, hasilnya tidak bisa jadi bersih
    Pada akhirnya rasanya seperti mengangkat satu piring penuh spaghetti sekaligus
  • Pada akhirnya keduanya benar
    Engineer senior selalu berada dalam dilema antara ‘melakukannya dengan benar’ dan ‘menyelesaikannya dengan cepat’
  • Kode yang baik itu bergantung pada konteks
    Basis kode yang kompleks tidak bisa dipahami dalam semalam, dan jika organisasi tidak menghargai akumulasi pengetahuan, kualitas akan memburuk
    Sebaiknya pegawai baru diberi tugas dokumentasi atau perapian agar mereka bisa mempelajari struktur kode
  • Alasan lainnya adalah tuntutan menjaga kompatibilitas
    Meski banyak hack lama dalam kode, kita tidak bisa menyentuhnya karena tidak boleh merusaknya
  • Kode terburuk yang pernah saya tulis muncul karena requirement yang terus berubah
    Sebagus apa pun desainnya, kalau fondasinya berdiri di atas pasir, semuanya akan runtuh

• Kesimpulan penulis bahwa ‘readability lebih diprioritaskan daripada kualitas’ berarti semua proyek di perusahaan besar seharusnya wajib memakai alat analisis statis dan formatter otomatis
  Tetapi kenyataannya tidak begitu
  Penerapan alat seperti ini adalah keputusan manajer nonteknis, dan mereka tidak suka biaya jangka pendek
  Pada akhirnya, jadwal rilis mengalahkan segalanya

  • Manajer dengan pola pikir seperti “monitor kedua itu tidak perlu” melambangkan budaya seperti ini

• Saat menjadi konsultan di sebuah perusahaan manufaktur besar, saya melihat ada pola pemodelan objek yang aneh di seluruh basis kode
  Setelah ditelusuri, ternyata tim pengembang benar-benar salah paham terhadap konsep yang dimaksud perancang (blueprint–mold–product)
  Ketika saya mengusulkan perbaikan, jawaban yang saya terima adalah “sudah terlambat”
  Akibatnya, model yang salah itu bertahan lebih dari 10 tahun dan melahirkan utang teknis yang sangat besar

  • Sampai muncul lelucon, “semoga saja produk itu tidak sampai membunuh orang”

• Statistik masa kerja yang pendek di perusahaan besar bisa menyesatkan
  Itu hanya karena jumlah pegawai meningkat tajam, sehingga medianya terlihat pendek
  Untuk akurat, yang harus dilihat sebenarnya adalah data orang yang keluar

  • Karena alasan yang sama, proporsi developer senior juga jadi terkesan lebih kecil dari kenyataan
    Alasannya sederhana: dulu jumlah developer memang lebih sedikit