Perbaiki dulu alatmu

• Saat menelusuri bug pada library open-source, muncul masalah debugger tidak berfungsi
• Meskipun kode sudah dijalankan, breakpoint diabaikan, sehingga dicoba cara lain untuk menemukan masalahnya
• Berbagai upaya diagnosis tidak langsung, seperti menambahkan output log, dilakukan, tetapi tidak memberikan insight yang diinginkan
• Pada akhirnya, setelah memperbaiki kesalahan konfigurasi debugger, perilaku program bisa diamati secara rinci dan bug pun berhasil diselesaikan
• Dari pengalaman mengabaikan cacat pada alat itu sendiri karena terlalu fokus menyelesaikan masalah, ditekankan bahwa developer perlu lebih dulu memperbaiki alat agar bisa menyelesaikan masalah secara efisien

---

Masalah yang muncul saat mendiagnosis bug

• Saat mencari bug pada library open-source yang sedang dipelihara, terjadi gejala debugger mengabaikan breakpoint
  • Sudah jelas bahwa kode mengeksekusi baris tersebut, tetapi program selesai tanpa berhenti
  • Karena terlalu fokus pada penyelesaian masalah, persoalan pada debugger diabaikan dan pendekatan lain dicoba
• Diagnosis dicoba dengan mengubah kode dan menambahkan log, tetapi tidak menghasilkan informasi yang berguna

Memperbaiki debugger dan menyelesaikan masalah

• Diputuskan untuk menyelesaikan masalah debugger, lalu perbaikannya tuntas hanya dengan perubahan konfigurasi satu baris
  • Setelah diperbaiki, perilaku program dapat diamati dengan rinci
  • Berdasarkan informasi ini, bug berhasil diperbaiki

Kesadaran dan pelajaran

• Disadari adanya situasi paradoks ketika semangat untuk memperbaiki bug justru membuat masalah pada alat terabaikan
• Dialami langsung bahwa ketika alat tidak bekerja dengan benar, efisiensi pemecahan masalah menurun
• Yang dibutuhkan developer adalah kebiasaan memeriksa dan memperbaiki alat sebelum masalahnya
• Ditutup dengan kalimat “Fix your tools”, sebagai pesan yang mengingatkan semua programmer akan pentingnya alat

[GN⁺]

Opini Hacker News

• Saya sudah 30 tahun berkarier, dan belakangan ini alat pengembangan benar-benar makin rusak
  Saya menulis kode di Linux dengan Clio, dan selama beberapa tahun bug-nya makin parah
  Sekarang saya sering cuma menganggap “kalau tidak jalan ya sudah” lalu lanjut. Hidup ini singkat, dan saya tidak punya waktu luang untuk memperbaiki kode orang lain juga

• Saat mencoba memperbaiki masalah, ujung-ujungnya sering jatuh ke yak shaving
  Saat mencoba menyelesaikan masalah kecil, pekerjaan-pekerjaan detail lain terus bermunculan tanpa habis
  Video terkait bisa ditonton di sini

  • Tidak ada jawaban pasti untuk situasi seperti ini
    Kadang merapikan alat dan library bisa membuat produktivitas meledak, di lain waktu justru lebih cepat kalau langsung hardcoding
    AI membantu merapikan alat, tetapi pada saat yang sama cakupannya ikut membesar sehingga pada akhirnya waktu yang dihabiskan untuk mengelola alat tetap sama
    Pada akhirnya ini masalah prokrastinasi emosional. Kita enggan memikirkan struktur keseluruhan lalu hanya mengulang perubahan kecil, atau sebaliknya menunda desain keseluruhan dan malah sibuk merapikan alat-alat detail
  • Sayang sekali yak shaving sering disalahpahami hanya sebagai buang-buang waktu
    Sebenarnya ini juga proses menghadapi gesekan dan ketidaknyamanan yang memang perlu
    Tapi kita tetap harus selalu memeriksa apakah ketidaknyamanan itu benar-benar diperlukan
    Menginvestasikan 10~15 menit untuk mengotomatisasi atau mempersingkat pekerjaan berulang pada akhirnya sama dengan membeli waktu di masa depan
  • Videonya sesuai dugaan, tapi tetap lucu
  • Ini juga mengingatkan pada XKCD 349
  • Hal seperti ini terjadi karena alat-alat dibiarkan terbengkalai sampai semuanya rusak
    Pada akhirnya utang teknis tetap harus dibayar suatu hari nanti, jadi kita perlu membiasakan diri membayarnya sedikit demi sedikit

• Rekayasa pada akhirnya adalah rangkaian terus-menerus dari proses mengasah kapak
  Seperti kata Kent Beck, saya suka pendekatan “buat perubahan menjadi mudah terlebih dulu, lalu lakukan perubahan yang mudah itu”

  • Saya pernah mendapat tugas memperbaiki kode yang belum pernah saya lihat sebelumnya, tetapi kodenya begitu berantakan sehingga akhirnya saya memutuskan untuk mulai dari refactoring
    Rasanya jauh lebih memuaskan memperbaiki kode daripada sekadar menambahkan fitur
  • Pendekatan ini masih kurang dalam coding berbasis AI
    AI tidak menganggap aneh meski menulis kode yang sama berulang kali, sehingga hasilnya tidak terstruktur dan tidak dapat digunakan ulang
  • Mengasah kapak selama 4 jam sejak awal mungkin juga tidak efisien
    Dalam praktiknya, lebih realistis untuk mengasahnya lagi saat alat mulai tumpul di tengah pekerjaan
  • Dalam pemrograman saya lebih suka ‘kapak’—alat minimal seperti vim—tetapi untuk menebang pohon, gergaji mesin jelas terasa lebih baik
  • Sebagian besar rekan kerja saya bekerja seperti memotong pohon dengan pipa
    Mereka terus bekerja tidak efisien sambil berkata, “Saya sedang sibuk sekarang, tidak ada waktu untuk mengasah kapak!”

• Saya terkesan dengan kalimat, “Keinginan untuk memperbaiki bug justru menutupi fakta bahwa alatnya harus diperbaiki terlebih dahulu”
  Fenomena ini juga dibahas dalam Why Greatness Cannot Be Planned karya Kenneth Stanley

• Ini nasihat yang sangat bagus. Saya juga berusaha mempraktikkannya setiap hari
  Tapi nasihat lanjutan, “sekarang berhenti memperbaiki alat, dan perbaiki masalah yang sebenarnya,” justru sulit diikuti

• Saya juga sering mengalami situasi seperti ini
  Memperbaiki gesekan kecil memang menghemat waktu nanti, tetapi ada jebakan untuk terus-menerus mengutak-atik alat saja tanpa akhir
  Yang benar-benar sulit adalah menentukan kapan harus berkata, “segini sudah cukup,” lalu lanjut

• Alat adalah sesuatu yang memberi efek pengganda terhadap usaha
  Tetapi sulit menemukan keseimbangan antara yak shaving dan kerja manual yang tidak perlu
  Jika memang berencana memakai alat yang sama dalam jangka panjang, mungkin kita justru perlu lebih condong ke arah yak shaving daripada yang dibayangkan, karena perbaikan 1% pun efek akumulasinya besar

• Pelajaran terbesar adalah bahwa alat all-in-one kebanyakan memang kurang bagus
  Saya sudah mencoba berbagai alat no-code seperti Make, Airtable, dan n8n untuk pipeline konten, tetapi semuanya mulai rusak setelah melewati skala tertentu
  Pada akhirnya, memanggil API langsung dengan skrip Python jauh lebih stabil
  Solusi sebenarnya bukan memperbaiki alat yang rumit, melainkan menggantinya dengan alat yang sederhana dan transparan

  • Saya belum pernah memakai alat seperti n8n, jadi saya penasaran apakah ada situasi di mana itu lebih baik daripada Python
  • Karena itu saya sangat menyukai Airflow

• Melihat langsung alur kode dengan debugger sangat berguna
  Jauh lebih intuitif untuk dipahami dibanding analisis statis

  • Tetapi debugger tidak selalu membantu
    Jika terus mengubah variabel atau breakpoint, kita jadi mudah kehilangan inti masalahnya
    Debugger seharusnya dipakai hanya untuk memverifikasi hipotesis. Kalau tidak, kita mudah terjebak dalam ‘ilusi seolah sudah ada kemajuan’

• Kalau Anda suka tulisan seperti ini, saya ingin bercanda dengan mengatakan: jangan pernah menginstal Emacs