- Kemampuan pengembangan tidak ditentukan oleh pengetahuan saja; meski tahu apa yang harus dilakukan, jika pengujian, refactoring, atau penulisan kasus reproduksi ditunda karena kurang motivasi, utang teknis akan menumpuk
- Pengembang yang hebat akan menyelidiki dan memperbaiki flaky test, mengubah bug yang ditemukan menjadi tiket atau langsung memperbaikinya, dan jika fitur baru tidak cocok dengan kode yang ada maka mereka akan melakukan refactoring terlebih dahulu
- Pepatah seperti “premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” berguna saat menghadapi kendala nyata, tetapi juga bisa dipakai untuk menyembunyikan alasan sederhana: tidak ingin mengerjakannya
- Di Lazygit, sistem pengujian end-to-end dibangun selama beberapa bulan dan manfaatnya benar-benar terasa, tetapi pengujian yang sama tidak ditambahkan ke Lazydocker, dan permintaan repositori reproduksi minimal serta refactoring God Struct juga terus ditunda
- Bahkan saat tidak punya energi untuk menulis kode yang sempurna, jika kekurangannya diungkapkan dengan jujur maka lebih mudah menilai standar pemeliharaan dan prioritas pekerjaan berikutnya
Kurangnya motivasi yang menciptakan utang teknis
- “Can’t Be Fucked” adalah slang Australia yang berarti tidak ingin melakukan sesuatu, atau tidak punya energi dan motivasi untuk melakukannya
- Dulu ada anggapan bahwa mempelajari lebih banyak pengetahuan pengembangan akan membuat seseorang menjadi programmer yang lebih baik, tetapi dalam praktiknya, para pengembang yang benar-benar layak dihormati bukan hanya berpengetahuan luas, melainkan juga memiliki ketekunan yang konsisten
- Pengembang yang baik tahu bahwa menangani masalah dengan benar saat masih kecil akan menghemat waktu dalam jangka panjang, lalu mereka benar-benar bertindak sesuai itu
- jika ada flaky test, mereka menyelidiki dan memperbaikinya
- jika menemukan bug di production, mereka membuat tiket atau langsung memperbaikinya
- jika fitur baru tidak cocok dengan kode yang ada, mereka melakukan refactoring terlebih dahulu alih-alih memaksakannya masuk
- bila perlu, mereka turun sampai ke lapisan stack paling bawah untuk mencari akar penyebabnya
- Pengembang seperti ini juga bisa membedakan kapan “good enough” memang sudah tepat, kapan scope perlu dipersempit, dan kapan lebih baik mempelajari domain lebih dulu sebelum mengubah arsitektur
- Masalahnya, terlepas dari penilaian semacam itu, ada saat-saat ketika kurangnya motivasi menjadi kendala yang lebih besar daripada batasan eksternal proyek
Jujur tanpa bersembunyi di balik pepatah
- Sistem pengujian end-to-end untuk Lazygit dibuat paruh waktu selama beberapa bulan, lalu berhasil mencegah banyak regression, dan ada keyakinan kuat bahwa menambahkannya sekarang justru akan jauh lebih sulit
- meski begitu, alasan pengujian end-to-end belum ditambahkan ke Lazydocker hanyalah karena CBF
- Setelah membuat issue di repositori open source lain, ada permintaan untuk repositori Git reproduksi minimal, tetapi itu masih belum dibuat; refactoring besar yang dimulai lebih dari setahun lalu juga belum selesai, sehingga banyak kode masih tertinggal dalam God Struct
- Tidak dipastikan apakah ini karena burnout, kurangnya growth mindset, atau memang masalah kepribadian
- Mengetahui rasa sakit jangka panjang dari utang teknis bisa menjadi motivasi untuk menghindarinya, tetapi mengetahui dan benar-benar bertindak dengan benar adalah dua hal yang berbeda
- Ucapan seperti “terlalu banyak test akan menambah beban pemeliharaan”, “saya akan melakukan refactoring setelah melihat dampak fitur lain”, “premature optimisation”, “cut scope aggressively” bisa dipakai untuk penilaian yang baik, tetapi juga bisa menjadi alasan
- Jika mengakui bahwa sebagian kode atau pull request kurang baik karena kemalasan, reviewer bisa langsung menilai apakah kekurangan itu masih di atas ambang standar atau apakah lebih baik waktu dipakai untuk pekerjaan berikutnya
- Saat berada dalam kondisi CBF, lebih baik jujur daripada putus asa, dan jika sudah terlalu lama berlari di 100%, mungkin yang dibutuhkan adalah liburan
1 komentar
Komentar Hacker News
Sebagian besar CBF bisa dijelaskan hanya dengan kompensasi dan insentif
Saat pertama masuk perusahaan ini, saya penuh energi: memperbaiki build yang rusak, membuat test yang terbengkalai kembali lolos, me-refactor pipeline deployment, serta mencari dan memperbaiki akar penyebab bug
Namun seiring waktu, orang-orang bukannya meniru saya, malah berpikir “toh orang itu nanti yang akan memperbaikinya”, dan saya sadar bahwa mengerjakan pekerjaan remeh hanya membuat lebih banyak pekerjaan remeh kembali ke saya
Sebaliknya, orang yang membuat sesuatu secara asal-asalan seperti hack bisa mengemas hasilnya dengan baik lalu lebih dulu dipromosikan, dan saat masalah muncul di operasi, ia sudah pindah ke proyek lain
Junior yang saya bantu beberapa jam setiap minggu berpenghasilan lebih besar daripada saya karena direkrut buru-buru pada 2022, sementara saya mendapat penilaian “melampaui ekspektasi” pada 2023, tetapi tidak mendapat kenaikan gaji dengan alasan masa sedang sulit
Pada akhirnya, dari sudut pandang orang yang bekerja untuk digaji, tidak aneh jika motivasi hilang ketika usaha tidak diberi imbalan atau malah menjadi hukuman
Pergilah, lalu temukan tempat yang cocok untuk Anda dan orang-orang Anda sendiri
Jika mendapat pengakuan, biaya motivasi turun drastis, dan manusia menyukai imbalan
Orang menghabiskan ribuan jam bermain game juga karena biaya motivasinya sangat rendah
Bukan berarti tempat kerja harus dibuat seperti game, tetapi karena membela diri sendiri terlihat picik, rekan kerja harus saling memberi pengakuan
Technical debt juga memiliki suku bunga yang berbeda-beda, dan keahlian terletak pada membiarkan debt 0% dan melunasi debt berbunga tinggi terlebih dahulu
Saat memasang lantai di lemari basement, bahan kurang sehingga bagian belakang tidak terpasang sepenuhnya. Kelihatannya agak jelek, tetapi selalu tertutup kotak dan tidak berpengaruh meski tinggal di sana puluhan tahun. Ini adalah technical debt 0%
Sebaliknya, jika saluran drainase tersumbat, biayanya akan meningkat seiring waktu karena kebocoran basement atau lepasnya saluran, sehingga itu adalah debt yang berbunga. Tangga depan yang rusak dan terus membuat orang tersandung juga merupakan debt berbunga tinggi yang harus segera diperbaiki
Dalam engineering, masalah arsitektur yang memperlambat semua pengembangan fitur bisa menjadi debt berbunga tinggi, sementara kode berantakan atau TODO di file yang hampir tidak pernah disentuh bisa jadi sebenarnya debt berbunga rendah
Di satu sisi, engineer sering melewatkan pekerjaan yang lebih penting karena sibuk memperbaiki debt 0%; di sisi lain, mereka mengatakan “produk/leadership tidak mendukung penyelesaian technical debt”, tetapi sering tidak mampu menjelaskan biaya nyata dan suku bunganya dengan baik
Dari atas sampai bawah, yang mendapat perhatian hanya hal baru dan berkilau; pekerjaan mempertahankan yang sudah ada tidak menarik minat
Bahkan jika berhasil meyakinkan orang tentang pentingnya, manajemen hanya akan setuju bahwa pekerjaan itu perlu, tetapi tidak ada dampak positif apa pun pada evaluasi kinerja. Kalau ada yang salah, saya saja yang akan menanggung pekerjaan yang hanya berujung teguran
Jika codebase berantakan dan tidak konsisten, meski itu file tersembunyi, developer akan berkurang niatnya untuk mengimplementasikan fitur baru secara konsisten dan berkualitas
Akhirnya menjadi “toh seluruh modul ini harus ditulis ulang, jadi tempel saja seadanya di sini dulu, nanti dirapikan”
https://en.wikipedia.org/wiki/Broken_windows_theory
Ini perluasan yang alami dari istilah technical debt, dan menyampaikan intinya secara ringkas sehingga ingin saya gunakan juga di perusahaan
Jadi menyalahkan “developer tidak bisa menjelaskan biaya nyatanya” terasa seperti alasan yang agak mudah
Jika masalahnya terlihat oleh pelanggan, kemungkinan besar akan diselesaikan, tetapi jika hanya masalah internal, kemungkinannya jauh lebih kecil
Saat memakai istilah seperti “technical debt 0%” secara serius, mungkin perlu dipikirkan lagi apakah konsepnya sudah tepat
Debt harus dilunasi atau dibayar bunganya; jika tidak ada hal semacam itu, maka itu bukan debt
Berikutnya, apakah fitur yang belum diimplementasikan juga akan disebut technical debt 0%?
Saya bukan penggemar Steve Jobs, tetapi saya selalu menyukai kutipannya tentang craftsmanship dan sikap memperhatikan detail
“Jika Anda seorang tukang kayu yang membuat lemari laci yang indah, Anda tidak akan memakai plywood untuk bagian belakang hanya karena menghadap ke dinding dan tidak akan dilihat siapa pun. Anda tahu bagian itu ada, jadi Anda akan memakai kayu yang indah juga di bagian belakang. Agar bisa tidur nyenyak pada malam hari, rasa estetika dan kualitas harus dijaga sampai akhir”
Menurut saya, software secara umum sangat menderita karena sikap “persyaratan teknisnya sudah sekadar terpenuhi, jadi pekerjaan saya selesai”
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Ada banyak cerita bahwa ia menolak merilis hardware dan software yang tidak memenuhi standar, dan memecat orang yang tidak bisa membuatnya sesuai spesifikasi yang benar
Sebaliknya, kebanyakan orang bekerja di bawah kepemimpinan yang sepenuhnya berlawanan: “selesaikan secepat mungkin supaya bisa menjual lebih banyak, dan asal cukup untuk lolos quality test”
Tukang kayu sungguhan harus praktis dan efisien biaya agar bisa bersaing di pasar
Jika memakai kayu mahal atau menghabiskan waktu untuk bagian yang tidak dilihat siapa pun, throughput turun dan biaya bagi pelanggan naik tanpa perlu
Bagi pengrajin pun, waktu dan uang itu terbatas, dan waktu yang dipakai untuk pekerjaan yang tidak terlihat adalah waktu yang tidak bisa dipakai untuk pekerjaan yang lebih terlihat
Di pasar tempat tukang kayu dengan kemampuan sama memproduksi lebih banyak dengan biaya lebih rendah, tukang kayu seperti itu akan tersisih
Menurut saya, masalah software lebih dekat ke masalah insentif daripada sikap. Saya suka melakukan pekerjaan yang baik dan memakai software yang baik, tetapi waktu dalam sehari terbatas, dan saya tidak sampai rela mengorbankan waktu pribadi demi keuntungan bisnis yang tidak akan saya nikmati
Selain itu, begitu mulai refactoring, kita bisa secara masuk akal memperkirakan bahwa suatu hari tiba-tiba akan muncul fitur wajib yang harus selesai hari itu juga
Bahkan jika manajemen setuju untuk menangani technical debt, pada akhirnya itu tidak akan terselesaikan kecuali estimasi jadwal digelembungkan dan kita melakukan refactoring alih-alih pekerjaan yang ditugaskan
Dalam sebuah buku, ada tokoh pandai besi yang memperbaiki komponen kereta dan berkata, “Selalu lakukan yang terbaik yang bisa kamu lakukan”
Ketika dijawab, “Itu komponen yang ada di bawah, tidak ada yang akan melihatnya,” ia menjawab, “Tapi aku tahu itu ada di sana. Jika aku tidak membuatnya sebaik yang bisa kulakukan, aku akan malu setiap kali kereta itu lewat. Dan aku akan melihat kereta itu setiap hari”
https://news.ycombinator.com/item?id=28086786
Jika Anda menulis unit/integration/end-to-end test yang benar, dan saat melihat kode berantakan Anda melakukan refactoring alih-alih menumpuk lagi di atasnya, produktivitas Anda di atas kertas lebih rendah daripada rekan yang terus “menyelesaikan” tiket
Ini terutama parah di organisasi “sepenuhnya agile” yang sama sekali tidak mempertimbangkan refactoring atau perapian kualitas kode
Apple setidaknya pernah menjadi pengecualian. Harga produknya tinggi sehingga pelanggan mengharapkan kualitas, perusahaan punya margin laba yang memungkinkan itu, dan yang terpenting ada Steve Jobs yang punya mata untuk menilai pengalaman
Di ekstrem sebaliknya, ada contoh seperti Juicero, yang membuat mesin pemeras kemasan jus dengan engineering setingkat aerospace
Sepanjang sebagian besar karier saya, jika melihat kesempatan, saya membersihkan technical debt tanpa diminta. Karena saya punya rasa keterikatan dan kepemilikan
Sekarang tempat kerja saya berbasis Jira dengan micromanagement dan tanpa otonomi, jadi saya tidak melakukan apa pun selain yang benar-benar wajib
Dulu upaya sukarela adalah inti karier saya, tetapi sekarang biaya manajemen proyek yang birokratis dan sosial untuk perubahan apa pun terlalu besar sehingga tidak layak dilakukan
Saya tidak peduli apakah produk berjalan baik dalam jangka panjang atau perusahaan sukses; saya hanya mengerjakan tiket sampai menemukan pekerjaan berikutnya
Sebaliknya, jika dilakukan dengan gaya “jangan minta izin untuk refactoring,” Anda dimarahi karena membuat PR yang tidak mengikuti pola yang sudah ada di repository
Jadinya, “Bagus sih, tapi ini harus didiskusikan dengan seluruh tim”
Maka technical debt terus membesar, butuh berbulan-bulan untuk merge satu PR, dan test begitu tidak stabil sampai terasa seperti mesin slot kasino yang tombol restart-nya ditekan sampai akhirnya build berhasil. Agile memang luar biasa
Dalam pengalaman saya, bertindak proaktif di tempat kerja yang hanya bergerak reaktif sama sekali tidak pernah diberi imbalan
Begitu menemukan masalah, saat itu juga masalah itu menjadi masalah saya, dan jika nanti meledak lagi, sayalah yang dianggap merusaknya
PM dan jajaran manajemen selalu bergerak dengan asumsi negatif, jadi tidak sepadan
Terutama karena sebagian orang merasa punya jalan tercerahkan menuju kode yang baik bagi mereka, padahal dalam praktiknya mereka sering memilih jalan yang lebih mudah daripada membaca dan memahami kode yang sudah ada
Ada sedikit kesalahpahaman di komentar-komentar di sini
Bagi programmer individu, motivasi, usaha, energi, kemauan—apa pun sebutannya—adalah sumber daya yang terbatas, dan itu sepenuhnya normal
Keunggulan organisasi adalah bisa menyelesaikan lebih banyak pekerjaan daripada programmer individu, tetapi dalam proses menyatukan berbagai elemen, muncul celah dan pekerjaan jatuh di antaranya
Orang-orang seperti COO, HR, dan product manager yang dibayar bukan untuk pekerjaan teknis melainkan untuk menjalankan organisasi harus membuat proses untuk menangani celah-celah itu
Namun semakin banyak perusahaan melemparkan pekerjaan ini kepada engineer dan designer individual, karena sulit diukur dengan laba-rugi atau OKR
Perusahaan menderita dan engineer burnout. Ada batas untuk terus mengurus tiket dan pekerjaan kecil yang jatuh di celah-celah itu tanpa kompensasi tambahan
Suasananya sangat negatif di sini, tapi saya senang karena tulisan ini menjelaskan perasaan sehari-hari saya dengan tepat
Saat melihat cakupan pengujian yang bagus dan refactoring yang berprinsip di proyek open source, pada hari tertentu saya juga masuk mode “ayo lakukan dengan benar” dan menghasilkan banyak hal yang dibuat dengan baik
Lalu suatu hari energi itu hilang, dan seperti penulisnya saya juga jadi CBF. Saya melewatkan test, menambahkan kode di tempat yang saya tahu tidak bagus, dan membuka jalan yang tidak akan disyukuri oleh diri saya di masa depan
Saya bisa melihat itu terjadi secara real time, tapi tidak punya energi atau motivasi untuk kembali ke mode “ayo lakukan dengan benar” yang penuh inspirasi
Semua ini juga terjadi pada software yang saya buat dan jual sendiri
Saya terkesan saat tahu penulisnya adalah pembuat Lazygit, dan saya benar-benar suka lazygit. Di kepala saya, dia selalu masuk kategori maintainer open source yang mengerjakan semuanya dengan benar
Sepertinya kita berdua punya pengalaman yang mirip soal motivasi
Senang mendengar kamu menyukai lazygit, dan semoga saya bisa terus mempertahankan penilaian baik itu
Sebagian besar keputusan sebenarnya bersifat bawah sadar
Kondisi “benar-benar tidak sanggup” berarti ada sirkuit di otak yang menilai hal seperti refactoring atau testing tidak sepadan untuk dikerjakan
Sirkuit itu bisa saja benar. Karena secara objektif dan menyeluruh, sering kali imbalannya memang tidak cukup dibanding usaha yang dikeluarkan
Misalnya, jika kamu menghabiskan dua bulan membuat end-to-end test, lalu selama enam bulan berikutnya hanya menghemat tiga minggu untuk debugging dan sebagainya, hitungannya tidak masuk
Ada dua ekstrem yang umum. Di satu sisi, bisnis memaksa engineer menanggung technical debt yang benar-benar merupakan trade-off buruk; di sisi lain, engineer kadang menghabiskan waktu untuk struktur ideal dan kumpulan test raksasa yang pada akhirnya tidak akan mendapat imbalan
Sebagian dari itu juga karena ada yang khawatir seseorang akan menemukan struktur kode yang lebih baik atau test tambahan lalu menilai dirinya
Jika saya merasa merilis sesuatu yang tidak memenuhi standar saya, meski standar itu lebih tinggi dari kebutuhan sebenarnya, moral dan motivasi saya rusak parah
Menurut saya masalah terbesar technical debt justru ada pada cara ia menghancurkan moral
Di Lazygit, saya membuat sebagian sistem end-to-end test selama beberapa bulan, dan setiap hari saya memikirkan regresi yang berhasil dicegah sistem itu serta betapa jauh lebih sulitnya jika harus menambahkannya sekarang
Saya tahu jelas itu bernilai, tapi alasan saya tidak menambahkan end-to-end test ke Lazydocker adalah karena saya CBF saja
End-to-end test sangat menyebalkan dan merupakan pekerjaan besar kalau tooling-nya tidak memadai. Framework dasar yang bisa dipasang dengan mudah perlu menjadi lebih baik
Kalau beruntung, orang itu masih punya waktu untuk menangani integration test juga
Menurut saya cara masyarakat dan dunia ini memandang orang sebagai malas pada umumnya benar-benar tidak masuk akal
Kita disuruh bekerja 40 jam seminggu selama puluhan tahun lalu baru beristirahat setelah reinkarnasi, dan di situ kita mau bicara soal kemalasan?
Energi mental diperas untuk menciptakan kekayaan orang lain, lalu ketika sudah terlalu tua untuk melakukan apa pun, kita dibuang
Setiap minggu selalu ada fitur lain yang seharusnya selesai kemarin, jadi saya tidak tahu kapan technical debt harus diperbaiki. Di waktu luang? Saya bahkan tidak tahu kenapa kita harus terus ada sejak awal
Di proyek matang dengan tim kecil, tiket yang tersisa semuanya bug sulit yang tidak diinginkan siapa pun
Meski menginvestasikan beberapa hari, tidak ada yang bisa ditunjukkan selain mencoret beberapa dugaan dari daftar; bug seperti itu bisa saja dicoret secara keliru lalu kembali lagi seminggu kemudian
Setiap hari semua energi mental harus dituangkan ke tiket seperti itu, dan setelah berhasil menyelesaikan bug dengan susah payah mengandalkan kopi atau stimulan, kamu mengirim kode, menutup tiket, lalu langsung lanjut ke tiket berikutnya
Tidak ada istirahat sungguhan; hanya di awal tiket berikutnya, saat belum ada yang mengharapkan hasil langsung, kepala bisa beristirahat sebentar
Tapi setelah beberapa hari orang-orang mulai bertanya apa yang sudah kamu kerjakan sejauh ini, bertanya apakah kamu buntu, dan kamu harus mengarang kebohongan kecil tentang kenapa kamu tertinggal padahal sebenarnya hampir belum mulai
Saat paling butuh istirahat, kamu sudah berada pada titik paling tertinggal dan orang-orang sudah menyadarinya, sehingga mengambil cuti pun tidak terasa seperti pilihan
Sekarang saya bekerja 20–30 jam seminggu di organisasi nirlaba engineering, kadang lebih sedikit, dan uang memang pas-pasan, tapi bekerja lebih banyak benar-benar mustahil
Saya punya sedikit waktu untuk side project dan bersepeda, dan saya tidak pernah bekerja pada akhir pekan. Hari Selasa juga tidak bekerja kecuali ada hal khusus
Saya benar-benar mencintai pekerjaan saya sekarang dan ini pekerjaan impian, tapi tidak layak dilakukan sampai membunuh diri sendiri. Hidup hanya sekali, dan saya akan hidup dengan mencintai secara benar
Hari ini saya menyelesaikan pekerjaan 1 bulan yang hampir menulis ulang total firmware perangkat perusahaan; awalnya pekerjaan itu diperkirakan sebagai tugas 1 minggu untuk memperbaiki bug kecil di sebagian modul komunikasi
Untungnya saya punya PM dan rekan kerja yang santai, jadi mereka mengakui bahwa sekarang bug legacy berusia 8 tahun di kode itu benar-benar bisa diperbaiki
Masih ada pengujian edge case dan perbaikan tambahan, tapi karena update kode jarak jauh sudah berfungsi, perangkat bisa dikirim
Di sini “berbohong” lebih seperti anjuran tindakan. Awalnya saya memulai komentar dengan “berbohonglah”, tapi ternyata menimbulkan salah paham
Juga agar kita bisa memberi tahu rekan kerja bahwa penting untuk punya waktu memikirkan implikasi yang lebih luas dari pekerjaan
Kita juga perlu ada untuk menambahkan pikiran sendiri ke komunitas seperti ini, makan cokelat, mengajak anjing jalan-jalan kalau bisa, dan mendengarkan kuliah Alan Watts di YouTube
Sebagai orang yang berusaha melakukan semuanya dengan benar, menurut saya hal penting dalam technical debt adalah pelacakan
Hanya butuh beberapa menit untuk membuat satu task dari masalah yang terlihat, dan task itu menjadi technical debt
Leadership bertanggung jawab menentukan prioritas technical debt dan terus menguranginya dalam jumlah tertentu
Kadang technical debt juga dikurangi dengan memutuskan untuk tidak melakukan sesuatu, dan itu sepenuhnya baik-baik saja
Tujuan dari prosedur mencatat, memeriksa, dan menangani adalah memberi kesempatan kedua untuk melihat “masalah yang bukan untuk sekarang”
Bisa saja intuisi awal salah sehingga X sebenarnya tidak diperlukan, atau sebaliknya intuisi itu benar karena alasan yang saat itu belum terpikirkan
Yang terpenting, sebagian dari hal-hal yang “tidak bisa dilakukan sekarang” memang benar-benar penting. Tanpa meluangkan waktu untuk melihatnya, kita tidak akan bisa menemukan hal-hal seperti itu