The Pragmatic Programmer, 25 tahun kemudian

Lipatan di halaman 47 sudah ada sejak aku membeli bukunya bekas, sekitar tahun 2012. Seseorang sudah melipat sudutnya sebelum aku — tepat di bagian “broken windows”, yang bilang bahwa satu potongan kode buruk yang dibiarkan tanpa perbaikan memberi sinyal bahwa sisa codebase boleh ikut diabaikan. Aku tidak tahu siapa yang melipat sudut itu. Tapi aku sudah kembali ke halaman itu lebih banyak dari yang bisa kuhitung.

Seorang junior engineer di tim aku tanya bulan lalu, apakah buku ini masih layak dibaca. Dia menemukannya disebut di thread Hacker News. Ada yang komentar: “Lumayan sih, tapi ChatGPT bisa melakukan semua yang mereka jelaskan di bab code generation.” Dia tunjukkan komentar itu lewat ponselnya, sedikit bingung apakah harus setuju.

Malam itu aku ambil bukunya dari rak. Aku baca selama empat malam di perjalanan pulang.

Ini yang aku temukan.

Yang tetap relevan

Biar aku mulai dari apa yang masih terasa benar setelah dua puluh lima tahun, karena daftarnya lebih panjang dari yang aku kira.

DRY — Don’t Repeat Yourself — masih tajam. Hunt dan Thomas mendefinisikannya dengan presisi: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” Bukan sekadar “jangan copy-paste” — meski itu juga termasuk. Ide yang lebih dalam adalah soal pengetahuan. Ketika aturan bisnis yang sama hidup di tiga tempat, aturan itu sendiri menjadi tidak stabil. Aku sudah menyaksikan masalah ini menenggelamkan dua codebase. Prinsipnya sama sekali tidak menua; tim-tim yang mengabaikannya membayar harga yang persis diprediksi buku ini.

Orthogonality adalah yang paling kurang aku terapkan di dekade pertama karier. Framing buku ini elegan: dua komponen bersifat orthogonal jika mengubah satu tidak mengharuskan mengubah yang lain. Dalam praktik, ini adalah argumen untuk decoupled systems, untuk interface yang jelas, untuk tidak membiarkan logika autentikasi mengetahui apa pun tentang logika rendering. Ini juga alasan mengapa microservices jadi begitu menarik — dan mengapa microservices yang dirancang buruk tak lebih dari distributed ball of mud. Prinsipnya abadi; eksekusinya masih terus membuat orang tersandung.

Pragmatic paranoia adalah bagian yang aku baca ulang dengan perasaan paling malu. Buku ini menyuruh kamu untuk “design by contract” — menegaskan apa yang kamu harapkan di batas setiap fungsi, menulis kode yang gagal dengan keras daripada melanjutkan diam-diam dengan input yang salah. Aku tidak mengikuti saran ini di sebagian besar karier aku. Aku menulis kode yang optimis karena lebih cepat ditulis. Aku bayar harganya dalam insiden produksi di mana errornya muncul tiga langkah setelah data buruk itu masuk. Buku ini benar. Aku yang malas.

Tracer bullets tetap valid sebagai model pengembangan, mungkin lebih relevan sekarang daripada tahun 1999. Idenya: alih-alih membangun seluruh sistem lapis demi lapis, tembakkan irisan vertikal tipis melalui arsitektur terlebih dahulu — sesuatu yang menyentuh setiap lapisan tapi melakukan sangat sedikit. Buat itu berjalan end-to-end, baru tambahkan daging pada tulangnya. Ini pada dasarnya adalah tampilan sprint zero yang baik, dan memetakan dengan bersih ke cara tim-tim baik menetapkan ruang lingkup proof-of-concept. Metafor ini lebih awet dari kebanyakan metafor di buku-buku teknologi.

Saran untuk selalu belajar — jaga “knowledge portfolio”, tambahkan satu bahasa baru per tahun, baca secara luas — terdengar sudah jelas jika ditulis begitu saja. Tidak terasa jelas di tahun 1999, saat budaya dominannya adalah memilih satu stack dan menetap di sana. Masih tidak terasa jelas sekarang, melihat orang-orang yang sudah lima tahun di satu framework memperlakukan apa pun di luarnya dengan curiga.

Yang perlu catatan kaki

Di sinilah komentator Hacker News itu ada benarnya, meski dia menarik kesimpulan yang salah.

Bab 7 membahas code generators — alat yang menghasilkan boilerplate dari metadata, template, skrip yang menulis skrip. Di tahun 1999, membuat code generator adalah langkah tingkat lanjut, force multiplier yang mungkin hanya 10% tim yang menggunakannya secara sengaja. Buku ini memperlakukannya sebagai saran aspirasional: kamu bisa melakukan ini kalau cukup canggih.

Di tahun 2026, setiap IDE yang aku sentuh dua tahun terakhir sudah datang dengan copilot yang menghasilkan kode sesuai permintaan. Saran untuk “gunakan code generators” tidak salah — tapi seperti memberitahu seseorang untuk “pertimbangkan menggunakan listrik.” Itu sudah jadi baseline, bukan keunggulan.

Saran “pelajari satu bahasa baru setiap tahun” juga terbaca berbeda sekarang. Niat aslinya masuk akal: belajar bahasa baru memaksamu bertemu paradigma baru, cara baru mendekati masalah. Setahun dengan Lisp mengubah cara kamu memikirkan fungsi. Setahun dengan Prolog mengubah cara kamu memikirkan constraint. Aku masih percaya itu.

Tapi argumen praktisnya — bahwa menguasai banyak bahasa membuatmu lebih employable, lebih serbaguna sehari-hari — lebih lemah ketika copilot bisa menulis Python yang lumayan dari prompt seorang developer Ruby. Kompetensi di permukaan kini datang gratis. Argumen yang lebih dalam, yang soal cara berpikir, tidak berubah. Mereka hanya mencampuradukkan keduanya.

Heuristik estimasi dalam buku ini — aturan praktis tentang berapa lama tugas-tugas memakan waktu — yang paling banyak butuh pembaruan. Semuanya dikalibrasi untuk dunia di mana “tulis endpoint baru” berarti seorang engineer sendirian dengan editor-nya. Tambahkan AI pair-programmer yang bisa membuat boilerplate dalam hitungan menit, dan distribusi waktu pengerjaan tugas bergeser signifikan di ujung bawahnya. Waktu yang kamu hemat untuk struktur dialokasikan ulang ke review, judgment, dan integrasi. Heuristiknya tidak salah; mereka hanya mengukur hal yang berbeda dari sebelumnya.

Yang menua dengan aneh

Edisi Ulang Tahun ke-20 (2019) adalah versi yang layak dibaca sekarang. Hunt dan Thomas kembali dan mengganti rekomendasi alat yang spesifik, memperbarui contoh-contoh, dan menaruh beberapa bagian yang sudah usang ke laci. Hasilnya lebih bersih dibanding edisi aslinya.

Meski begitu, beberapa hal masih terasa berdiri di sudut yang ganjil.

Perlakuan buku ini terhadap “programmer sebagai penulis” bertahan lebih baik dari hampir semua analogi keahlian lain dalam literatur. Mereka membandingkan software dengan prosa: perhatian yang sama terhadap kejelasan, kepedulian yang sama tentang apa yang akan dihadapi pembaca (atau pemelihara di masa depan). Framing itu masih berguna. Aku sudah meminjamnya dalam code review.

Tapi alat tulis dan alur kerja spesifik yang mereka singgung adalah artefak dari 1999. Ada asumsi bahwa version control masih perlu diperdebatkan, bahwa automated testing masih jadi diskusi, bahwa dokumentasi hidup di file terpisah dari kode. Bagian-bagian ini tidak perlu diperbarui — mereka perlu dilewati saja. Mereka ditujukan untuk dunia yang sudah tidak ada.

Yang tidak hilang adalah perasaan yang sedang mereka lawan: programmer yang memperlakukan software sebagai keahlian yang perlu dipelajari dengan hati-hati versus programmer yang melihatnya sebagai serangkaian tugas yang harus diselesaikan. Buku ini mencoba membentuk jenis pikiran tertentu. Proyek itu abadi.

Yang tidak digantikan LLM

Inilah yang dilewatkan komentator Hacker News itu.

Buku ini sebenarnya bukan soal teknik. Ini soal postur. Hunt dan Thomas mendeskripsikan cara berdiri dalam hubunganmu dengan software — penasaran, skeptis, empiris, rendah hati. Mereka berargumen untuk programmer yang membaca kode mereka sendiri seperti orang asing, yang bertanya “kenapa ini perlu ada?”, yang menolak baik over-engineering maupun under-engineering karena mereka memahami biaya masing-masing.

LLM pair-programmer bisa membuat REST endpoint dalam tiga puluh detik. Tapi dia tidak bisa memberitahumu apakah endpoint itu seharusnya ada. Dia tidak bisa melihat arsitektur sistemmu dan berkata: ini adalah incidental complexity, bukan essential — di sinilah desainnya berbohong padamu. Dia tidak bisa memutuskan broken window mana yang harus diperbaiki duluan, atau broken window mana yang sebenarnya load-bearing dan tidak boleh disentuh.

Judgment adalah hal yang sebenarnya diajarkan buku ini. Taste. Disiplin untuk berhenti sebelum gold-plating. Keberanian untuk membuang sesuatu ketika kamu sudah membangun hal yang salah dengan baik. Kesadaran diri untuk menyadari ketika kamu terikat pada solusimu daripada pada masalah penggunamu.

Tidak satu pun dari itu datang dalam bobot model. Itu masih pekerjaanmu.

Gerakan yang terus berbunga

Di bagian akhir buku, Hunt dan Thomas menyatakan tesisnya dengan jelas. Seorang pragmatic programmer, tulis mereka, tidak dogmatis. Mereka tidak menikahi satu alat, metodologi, atau bahasa. Mereka menggunakan apa yang berhasil, membuang yang tidak, dan tetap benar-benar penasaran dengan apa yang belum mereka coba.

Ini adalah ide yang tenang. Tidak menghasilkan talk di konferensi. Tidak melahirkan framework yang dinamai sesuai namamu. Tapi aku sudah menyaksikannya terus berbunga selama lima belas tahun pekerjaan aku sendiri dan dalam diri engineer-engineer yang aku lihat tumbuh menjadi praktisi yang benar-benar luar biasa.

Pengetahuan programmer yang dogmatis mengalami stagnasi. Alat yang mereka cintai menjadi legacy system. Metodologi yang mereka jadikan pegangan jatuh dari mode. Cara belajar programmer yang pragmatis tidak stagnan. Dia hanya menemukan hal-hal baru untuk dipelajari.

Meta-skill itulah — disposisi, kebiasaan pikiran — yang sebenarnya dijual buku ini. Semua yang lain hanyalah contoh.

Apa yang aku katakan ke junior engineer

Aku masih merekomendasikan buku ini. Aku bilang ke kolegaku untuk membacanya.

Yang aku katakan untuk dilewati: sebagian besar rekomendasi alat di Bab 6, lampiran-lampirannya, dan bagian mana pun di mana contohnya tentang CVS atau makefile. Lewati tanpa rasa bersalah.

Yang aku katakan untuk dibaca pelan-pelan: bagian broken windows (halaman 47, di kopiku — tapi di bukumu itu ada di dekat bagian depan), bab orthogonality, bagian “dead programs tell no lies” di bawah pragmatic paranoia, dan semua yang ada di bawah “Your Knowledge Portfolio.”

Lalu aku bilang padanya untuk melipat sudut halaman-halaman yang membuatnya tidak nyaman. Bukan yang dia setujui — yang dia sadari selama ini dia abaikan.

Halaman-halaman itulah yang layak untuk dikunjungi kembali. Seseorang sudah melipatnya untukmu.

---