Esai-esai perangkat lunak yang membentuk saya

 (refactoringenglish.com)
74 poin oleh GN⁺ 2025-10-02 | 3 komentar | Bagikan ke WhatsApp
  • Selama 20 tahun saya telah membaca ribuan tulisan blog tentang perangkat lunak, tetapi hanya segelintir esai yang benar-benar mengubah cara berpikir saya, dan di sini diperkenalkan 10 esai kunci mulai dari “Joel Test” karya Joel Spolsky hingga pembelaan Julia Evans terhadap JavaScript murni
  • “Joel Test” karya Joel Spolsky menyajikan 12 pertanyaan untuk menilai apakah perusahaan menghormati pengembang, dan memeriksa apakah mereka memprioritaskan waktu serta fokus pengembang melalui hal-hal seperti manajemen source code, build harian, dan perbaikan bug lebih dulu
  • “Parse, don't validate” karya Alexis King memperkenalkan teknik mengubah data ke tipe baru saat memvalidasi, menunjukkan bahwa sistem tipe dapat membantu meningkatkan keamanan dan keandalan aplikasi
  • “No Silver Bullet” karya Fred Brooks membagi pekerjaan perangkat lunak menjadi kompleksitas esensial dan kompleksitas insidental, serta berpendapat bahwa peningkatan produktivitas 10 kali lipat tidak mungkin dicapai hanya dengan kemajuan alat dan perangkat keras, meski AI kini melempar variabel baru ke teori itu
  • Esai Julia Evans tentang JavaScript murni memberi kesadaran bahwa JavaScript ES2018 saja sudah cukup tanpa framework, dan sejak 2020 saya tidak lagi memasukkan framework JavaScript maupun langkah build ke proyek mana pun

“Joel Test” karya Joel Spolsky (2000)

  • Joel Spolsky adalah blogger perangkat lunak terbaik sepanjang masa, dan esai-esainya sangat memengaruhi pendekatan saya terhadap perangkat lunak
  • “Joel Test” adalah kumpulan 12 pertanyaan untuk menilai seberapa baik perusahaan berinvestasi pada tim perangkat lunaknya

  • Daftar 12 pertanyaan

    • Apakah menggunakan source control
    • Apakah bisa build dalam satu langkah
    • Apakah melakukan build harian
    • Apakah memiliki database bug
    • Apakah memperbaiki bug sebelum menulis kode baru
    • Apakah memiliki jadwal yang selalu terbaru
    • Apakah memiliki spesifikasi
    • Apakah programmer memiliki lingkungan kerja yang tenang
    • Apakah menggunakan alat terbaik yang bisa dibeli dengan uang
    • Apakah memiliki tester
    • Apakah kandidat baru menulis kode saat wawancara
    • Apakah melakukan hallway usability testing

  • Pesan utama

    • Sebagian pertanyaan memang sudah ketinggalan zaman, tetapi yang penting bukan pertanyaannya melainkan meta-poin dari pertanyaan itu
    • Yang sebenarnya ditanyakan Joel adalah: apakah Anda menghormati pengembang?
    • Semua pertanyaan itu menilai apakah perusahaan memprioritaskan waktu dan fokus pengembang di atas ruang kantor murah dan tenggat jangka pendek
    • Ini dipublikasikan di puncak dot-com boom, pada masa ketika pengembang terampil adalah sumber daya berharga, tetapi tidak semua orang menyadarinya
    • Blog Joel selalu menggambarkan programmer sebagai jenius langka dan rapuh yang harus dicari dan dihargai oleh perusahaan
    • Sepanjang karier saya, saya mencari perusahaan yang mendapat skor tinggi pada Joel Test, dan saya berterima kasih kepada Joel karena telah memberi panduan itu

“Parse, don't validate” karya Alexis King (2019)

  • Ini adalah esai tentang pemanfaatan sistem tipe Haskell, tetapi bahkan jika Anda tidak tertarik pada sistem tipe atau Haskell, cara berpikir Anda tentang perangkat lunak bisa berubah secara mendasar
  • Teknik Alexis dapat digunakan di semua bahasa yang mendukung static typing seperti Go, C++, dan Rust

  • Konsep inti

    • Setiap kali memvalidasi data, Anda harus mengubahnya ke tipe baru
    • Contoh: jika ada aturan bahwa nama pengguna harus alfanumerik dengan panjang maksimum 20 karakter, solusi naifnya adalah fungsi validateUsername(username string) error

  • Masalahnya

    • Kodenya secara default tidak aman
    • Karena setiap nama pengguna yang diterima harus divalidasi, sangat mudah membuat jalur kode yang tanpa sengaja memproses nama pengguna tanpa validasi
    • Jika pengguna jahat menemukan kesalahan itu, mereka bisa menyisipkan kode berbahaya ke kolom nama pengguna atau mengisinya dengan miliaran karakter hingga menghabiskan sumber daya server

  • Solusi Alexis

    • Gunakan fungsi parseUsername(raw string) (Username, error)
    • Di bagian lain codebase, gunakan tipe kustom Username alih-alih string bernama “username”
    • Satu-satunya fungsi yang dapat membuat Username adalah parseUsername, dan fungsi ini menerapkan aturan validasi sebelum mengembalikan instance Username
    • Jika Anda memiliki instance Username, maka ia harus berisi nama pengguna yang valid
    • Input yang tidak tepercaya akan selalu berupa string, sehingga string tidak bisa diberikan ke fungsi yang mengharapkan Username

  • Dampaknya

    • Sebelum membaca esai ini, saya mengira sistem tipe hanyalah cara menyenangkan untuk mengalihkan perhatian para nerd bahasa pemrograman
    • “Parse, don't validate” membuka mata saya terhadap betapa berharganya fitur compiler dalam meningkatkan keamanan dan keandalan aplikasi

“No Silver Bullet” karya Fred Brooks (1986)

  • Saya membaca The Mythical Man-Month karya Fred Brooks saat kuliah
  • Ini adalah kumpulan esai rekayasa perangkat lunak berdasarkan pengalamannya memimpin proyek OS/360 milik IBM

  • Kompleksitas esensial dan kompleksitas insidental

    • Kompleksitas esensial: pekerjaan yang memang harus dilakukan, terlepas dari alat dan perangkat keras
      • Contoh: dalam perangkat lunak perhitungan bonus tenaga penjualan, mendefinisikan rumus bonus dan mencakup semua edge case
      • Pekerjaannya sama baik di superkomputer senilai $5B maupun di mikrokontroler seharga $1
    • Kompleksitas insidental: segala sesuatu selain itu
      • Menangani memory leak, menunggu kode selesai dikompilasi, memahami cara memakai library pihak ketiga
      • Semakin baik alat dan sumber daya perangkat keras, semakin sedikit waktu yang dihabiskan untuk kompleksitas insidental

  • Kesimpulan Brooks

    • Kemajuan alat atau perangkat keras tidak mungkin menghasilkan peningkatan produktivitas pengembang sebesar 10 kali lipat
    • Bahkan jika semua aktivitas insidental dipangkas menjadi nol waktu, peningkatan sebesar itu tetap tidak mungkin kecuali aktivitas tersebut mencakup lebih dari 9/10 dari seluruh usaha

  • Penerapan

    • Sepanjang karier saya, orang-orang terus mencoba menghapus programmer dari perangkat lunak
    • Platform no-code menjadi sorotan dengan menjanjikan semua kekuatan web developer terampil kepada non-programmer
    • Esai Brooks selalu meyakinkan saya bahwa platform penuh buzzword terbaru tidak bisa menggantikan pengembang
    • Platform-platform itu berfokus pada kompleksitas insidental, bukan kompleksitas esensial
    • Bahkan jika sebuah platform bisa secara ajaib menghasilkan kode yang berjalan dari spesifikasi fitur, tetap saja dibutuhkan seseorang untuk menulis spesifikasinya

  • Dampak AI

    • AI modern melempar kunci inggris ke teori Brooks
    • AI benar-benar mengurangi kompleksitas esensial
    • Jika Anda memberi AI spesifikasi yang tidak lengkap atau saling bertentangan, AI akan meminjam dari spesifikasi serupa untuk mengisi kekosongan
    • Bahkan jika AI menghapus pemrograman seperti yang kita kenal, esai Brooks tetap memberi harapan bahwa pada akhirnya, di tingkat abstraksi mana pun, tetap dibutuhkan seseorang untuk mengelola kompleksitas esensial

“Choices” karya Joel Spolsky (2000)

  • Sulit memilih hanya satu esai Joel Spolsky favorit, jadi saya memilih dua
  • “Choices” membahas pembuatan antarmuka pengguna dan biaya halus dari memberi pengguna kuasa

  • Pesan utama

    • Setiap kali Anda memberi opsi, Anda meminta pengguna mengambil keputusan
    • Artinya pengguna harus memikirkan sesuatu dan memutuskannya
    • Ini tidak selalu buruk, tetapi secara umum Anda sebaiknya berusaha meminimalkan jumlah keputusan yang harus dibuat orang

  • Contoh Windows 98

    • Joel membagikan dialog box absurd yang muncul saat mencari dokumen bantuan di Windows 98
    • Alasan dialog box itu membuat Joel marah:
      • Menginterupsi pengguna ketika mereka sedang mencoba mendapatkan bantuan
      • Meminta mereka membuat keputusan tanpa informasi tentang optimasi database
      • Windows menghindari keputusan itu dan melemparkannya ke pengguna

  • Cakupan penerapan

    • Esai Joel berfokus pada graphical user interface, tetapi saya memikirkannya di setiap tempat yang bisa bersentuhan dengan kode, termasuk command line atau pengembang lain yang memanggil fungsi yang saya tulis
    • Apakah saya bisa mengambil keputusan yang berguna atas nama pengguna, sambil tetap memberi mereka kendali atas hal-hal yang memang mereka pedulikan
    • Esai Joel telah berkali-kali mencegah saya melemparkan keputusan yang sebenarnya bisa saya ambil sendiri kepada pengguna

Raymond Chen, “Application compatibility layers are there for the customer, not for the program” (2010)

  • Raymond Chen adalah salah satu pengembang dengan masa kerja paling lama di tim Microsoft Windows
  • Blognya berisi ribuan kisah yang informatif dan menghibur tentang sejarah pemrograman Windows

  • Contoh permintaan pelanggan

    • Permintaan pelanggan terkait mode kompatibilitas Windows Vista:
      • Program yang dirancang untuk Windows XP dan Windows Server 2003 mengalami kesulitan di Windows Vista
      • Jika diatur ke mode kompatibilitas Windows XP, program itu berjalan baik di Vista
      • Pertanyaan tentang perubahan apa yang diperlukan pada installer agar saat dijalankan di Vista, program otomatis berjalan dalam mode kompatibilitas XP

  • Analogi Raymond

    • "Saya biasanya membuang sampah di trotoar depan toko hewan peliharaan, dan setiap pagi saat toko buka, seseorang menyapu sampah itu lalu membuangnya ke tempat sampah. Tapi toko hewan peliharaan itu tidak buka pada hari Minggu, jadi pada hari Minggu sampahnya tetap ada di sana. Apa yang harus saya lakukan agar toko hewan peliharaan itu buka juga pada hari Minggu?"

  • Pelajaran

    • Analogi itu sangat lucu sampai-sampai baru sekarang menyadari bahwa Raymond sebenarnya salah
    • Mengejek dosa para pengembang yang berharap Windows tidak akan merusak aplikasi mereka setelah satu rilis tunggal
    • Meski tidak setuju dengan detailnya, tulisan Raymond sangat lucu dan tajam sehingga kelemahannya bisa terlewatkan
    • Pelajaran hebat tentang mempengaruhi perilaku pengguna:
      • Jika ingin mendorong pengguna melakukan sesuatu yang membantu Anda, Anda harus memikirkan dengan cermat jalur dengan hambatan paling kecil dari sudut pandang pengguna
      • Jika membuang sampah di trotoar tampak seperti menyelesaikan masalah sepenuhnya, mereka akan terus melakukannya

Erik Kuefler, "Don’t Put Logic in Tests" (2014)

  • Penulis selalu menyukai unit test dan sangat bangga pada kode test yang ditulisnya
  • Esai ini muncul di kamar mandi dan mengejutkan dengan membongkar bahwa ia telah menulis test yang buruk sepanjang kariernya

  • Contoh test yang bermasalah

    @Test public void shouldNavigateToPhotosPage() {  
  String baseUrl = "http://plus.google.com/";;  
  Navigator nav = new Navigator(baseUrl);  
  nav.goToPhotosPage();  
  assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());  
}

  • Masalah yang ditemukan

    • Saat pertama kali membaca esai itu, pikirannya adalah, "Ini persis sama dengan cara saya menulis unit test!"
    • Mengapa string http://plus.google.com/ diduplikasi di dua tempat? Buat single source of truth seperti di kode produksi
    • Penulis selalu menambahkan helper function, variabel, dan loop untuk menghilangkan duplikasi di dalam test
    • Masalahnya, pendekatan ini menyembunyikan bug yang halus: yang sebenarnya di-assert adalah http://plus.google.com//u/0/photos (dua slash)

  • Pencerahan

    • Esai Erik menunjukkan bahwa kode test tidak boleh diperlakukan seperti kode produksi
    • Keduanya memiliki tujuan dan batasan yang sepenuhnya berbeda
    • Kode test yang baik, di atas segalanya, harus jelas
    • Kode test tidak punya kode test-nya sendiri, jadi satu-satunya cara memverifikasi kebenarannya adalah dengan inspeksi
    • Test harus sangat jelas sampai menyilaukan bagi pembaca tentang perilaku apa yang sedang di-assert
    • Demi tujuan ini, duplikasi boleh diterima untuk mengurangi kompleksitas

Julia Evans, “A little bit of plain Javascript can do a lot” (2020)

  • Sebagai software engineer, ia memulai web dengan sangat terlambat secara memalukan
  • Selama 10 tahun pertama kariernya, ia hanya menulis kode untuk aplikasi desktop dan server backend
  • Sampai 2017, ia sama sekali tidak peduli pada HTML atau JavaScript

  • Kesalahpahaman tentang framework

    • Saat mulai serius mempelajari pengembangan frontend, kesannya adalah JavaScript merupakan bahasa berantakan yang dibuat dalam 10 hari dan berperilaku sangat berbeda di tiap browser
    • Untuk menulis web app, dibutuhkan sesuatu yang modern dan rapi yang melindungi dari semua keburukan dan cacat JavaScript
    • Ia mencoba framework web populer seperti Angular, React, dan Vue
    • Ia sudah cukup mempelajari Vue, tetapi tetap menghabiskan banyak waktu untuk masalah dependensi dan jebakan framework
    • Bahkan setelah semua yang dilakukan framework frontend ini untuk memperbaiki JavaScript, pemrograman web tetap buruk

  • Pencerahan dari esai Julia

    • Ia sadar dirinya begitu yakin JavaScript perlu diperbaiki sampai-sampai tidak pernah memberinya kesempatan
    • Saat itu ia sedang mengerjakan prototipe TinyPilot dan berencana membuat antarmuka web-nya dengan Vue
    • Esai Julia menginspirasinya untuk melihat sejauh apa JavaScript murni bisa digunakan
    • Tanpa framework, library pembungkus, build step, atau Node.js, hanya JavaScript biasa (ES2018)
    • Ia terus menduga akan menemui masalah yang memaksanya beralih ke framework atau builder, tetapi itu tidak pernah terjadi
    • Ada beberapa jebakan terkait WebComponents, tetapi itu bukan apa-apa dibanding penderitaan yang dialaminya dengan Vue dan Angular

  • Kebebasan tanpa framework

    • Ia suka terbebas dari framework
    • Saat ada runtime error, stack trace bukan mimpi buruk dari kode yang sudah diminify, ditransformasi, dan di-tree-shake
    • Ia bisa men-debug kode miliknya sendiri persis seperti yang ditulis
    • Prasangkanya tentang JavaScript ternyata salah
    • JavaScript modern cukup bagus, dan telah menyerap banyak ide dari library pembungkus sehingga pembungkus itu kini tidak lagi dibutuhkan
    • Browser kini sudah lebih waras dalam memastikan perilaku yang konsisten antar platform dan perangkat
    • Sejak 2020, ia tidak lagi mengintegrasikan framework JavaScript atau build step ke proyek baru mana pun dan tidak pernah menoleh ke belakang
    • Dengan JavaScript murni, ia mendapatkan 90% manfaat framework dengan hanya 5% kerumitan

Dan McKinley, “Choose Boring Technology” (2015)

  • Ini esai yang aneh untuk dimasukkan ke daftar ini karena sebenarnya ia belum pernah membacanya
  • Orang-orang mengutip esai ini, dan begitu ia memahami idenya, gagasan itu terasa begitu intuitif sehingga ia tidak merasa perlu membacanya

  • Ide inti

    • Saat memulai proyek baru, ada godaan untuk memakai teknologi mutakhir yang sedang ramai dibicarakan
    • Google mengumumkan database baru yang bisa diskalakan hingga exabyte, 40% lebih cepat daripada Postgres, dan biayanya 20%
    • Rasanya bodoh memakai Postgres ketika alternatif baru yang seksi ini ada tepat di depan mata
    • Kenyataannya, teknologi baru punya bug dan kelemahan, hanya saja belum terlihat jelas
    • Saat menabraknya, Anda akan kebingungan
    • Postgres juga punya masalah, tetapi setelah 30 tahun pengalaman nyata di lapangan, ia memiliki solusi yang sudah teruji untuk hampir setiap masalah yang kemungkinan akan Anda hadapi

  • Konsep token inovasi

    • Dan mengakui bahwa kadang teknologi baru memang perlu dipakai, tetapi harus secara strategis dan dalam jumlah terbatas
    • Setiap bisnis mendapat tiga "token inovasi" untuk dibelanjakan
    • Jika Anda ingin database baru yang mewah itu, Anda harus menghabiskan salah satu token
    • Esai Dan terasa sangat cocok dipasangkan dengan esai Julia
    • Andai saja ia membaca salah satu dari keduanya sebelum membuang begitu banyak waktu pada framework frontend

Terence Eden, “I’ve locked myself out of my digital life” (2022)

  • Terence Eden adalah blogger teknologi yang ceria dan eklektik
  • Ia menulis banyak artikel baru setiap minggu, tetapi yang paling berdampak adalah “Saya mengunci diri saya sendiri dari kehidupan digital saya”

  • Skenario bencana

    • Mensimulasikan apa yang akan terjadi jika petir menyambar rumah Terence dan menghancurkan semua barang miliknya
    • Menyimpan kata sandi untuk semuanya di pengelola kata sandi
    • Jika semua perangkat hancur, pengelola kata sandi tidak bisa diakses
    • Alasan ini tidak bisa digantikan dengan passkey perangkat keras adalah karena semuanya juga berada di rumah

  • Kesadaran

    • Penulis merasa datanya cukup aman karena menyimpan semuanya di drive redundan dan memiliki backup offsite di tiga benua dengan dua vendor
    • Tulisan Terence membuatnya memikirkan banyak ancaman yang masuk akal yang dapat menghilangkan semua perangkat sekaligus: kebakaran, banjir, lonjakan listrik, penyelidikan kriminal
    • Karena semua data dienkripsi dengan kata sandi yang ada di kepala, amnesia, ketidakmampuan, dan kematian juga ditambahkan ke dalam daftar

  • Masalah layanan online

    • Layanan online rentan dalam membantu pengguna pulih dari bencana
    • Banyak layanan digunakan dengan asumsi bahwa kehilangan ponsel adalah hal yang mustahil, belum lagi akun email dan semua perangkat digital yang dimiliki

  • Dampak

    • Sejak membaca esai Terence, penulis lebih banyak mempertimbangkan layanan dan perangkat mana yang penting, serta bagaimana bisa pulih dalam skenario yang dijelaskan Terence
    • Saat membeli laptop berikutnya, penulis menyiapkannya di perpustakaan untuk menguji apakah akses ke pengelola kata sandi dan akun-akun penting bisa dipulihkan tanpa perangkat yang ada di rumah
    • Masih bisa menjadi lebih baik dalam kesiapsiagaan bencana digital, tetapi tulisan Terence terus terngiang di kepala setiap kali memikirkan cara mengamankan perangkat dan data
    • Apa yang akan terjadi jika semuanya tiba-tiba hancur?

Bonus: “parsing user input” karya Brad Fitzpatrick (2009)

  • Secara teknis ini bukan esai, tetapi kutipan dari wawancara perangkat lunak ini terus terlintas di pikiran
  • Membaca Coders at Work sebagai hasil dari ulasan penuh pujian Joel Spolsky pada 2009
  • Sebuah kumpulan wawancara dengan programmer-programmer sukses

  • Kutipan terkenal Brad Fitzpatrick

    • Brad Fitzpatrick, pendiri LiveJournal dan Memcached, muncul sebagai salah satu narasumber wawancara
    • Saat itu ia berusia 28 tahun, programmer termuda dalam buku tersebut, dan orang yang paling banyak mengumpat sekaligus paling lucu
    • Untuk pertanyaan tentang etika rekayasa perangkat lunak, ia memberikan pernyataan penuh semangat tentang validasi input:
      • “Saya ingin semua orang secara konsisten mengizinkan orang memasukkan spasi atau tanda hubung di formulir kartu kredit. Komputer sangat pandai menghapus hal-hal seperti itu. Jangan suruh saya bagaimana harus memformat angka saya.”

  • Penerapan

    • Setiap kali mencoba menempelkan nomor telepon ke formulir web, penulis teringat kutipan ini
    • Menggerutu saat tanda kurung atau spasi tidak diizinkan, atau yang lebih buruk, ketika nomor telepon dipotong karena tanda kurung lalu dikeluhkan bahwa tanda kurung tidak diperbolehkan
    • Setiap kali membuat kolom input dalam perangkat lunak dan memikirkan karakter yang tak terduga, penulis mendengar Brad Fitzpatrick berkata “Komputer sangat pandai menghapus hal-hal seperti itu”

Bacaan terkait

3 komentar

 
shakespeares 2025-10-07

Ada masa kini karena ada sejarah.
 
GN⁺ 2025-10-02
Opini Hacker News

  • Setelah membaca tulisan berjudul "I've locked myself out of my digital life", saya merasa itu berhasil mengungkapkan dengan tepat kecemasan yang selama ini saya miliki tetapi sulit dijelaskan
    Di dunia analog, saya mungkin masih bisa meyakinkan manusia tentang siapa diri saya, memverifikasi identitas, lalu mendapatkan kembali akses ke akun saya, tetapi di hadapan algoritme kejam dunia digital, tanpa kredensial, memohon pun tidak ada gunanya
    Bahkan perusahaan layanan password manager saya sendiri tidak punya hak akses ke kata sandi saya
    Bahkan tidak ada orang yang bisa diyakinkan, dan yang ada hanyalah kode sebagai hukum
    Saya rasa semua orang perlu memahami masalah ini sebelum mendorong penghapusan interaksi tatap muka dari semua proses
    Di artikel itu mungkin terdengar seperti situasi langka, tetapi ini sangat bisa terjadi dalam kasus bencana alam atau pencurian
    Tulisan terkait: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my-digital-life/

    • Saya rasa sebenarnya tidak banyak orang yang benar-benar mendukung otomatisasi seekstrem ini atau pengurangan interaksi langsung seperti itu
      Dan ini bukan cuma masalah AI; software berbasis aturan juga sama saja
      Di Uni Eropa (EU), hak untuk mengajukan keberatan kepada manusia atas keputusan apa pun dijamin oleh hukum

  • Grug Brained Developer adalah tulisan yang selalu membekas di kepala saya, tetapi tidak masuk dalam daftar
    Mungkin karena isinya sebenarnya sudah saya setujui sejak awal, jadi alih-alih mengubah cara berpikir saya, tulisan itu hanya sangat berkesan
    Referensi: https://grugbrain.dev/

    • Dari semua itu, saya sangat suka bagian tentang "perasaan terbaik adalah akhirnya mengurung iblis kompleksitas ke dalam kristal yang telah diperbaiki"

    • Saya bilingual dan menggunakan bahasa Inggris sebagai bahasa kedua, jadi tulisan bergaya grug brain cukup sulit dibaca dan dipahami
      Saya juga tidak tahu arti kata 'grug' itu apa
      Meski begitu, saya tetap menikmati membaca blog itu

  • Saya tidak setuju dengan kesimpulan Fred Brooks dalam "No Silver Bullet"
    Saya juga tidak setuju dengan klaim belakangan ini bahwa AI telah mengurangi kompleksitas esensial sampai-sampai membantah teori Brooks
    AI mungkin bisa mengisi spesifikasi yang tidak lengkap atau saling bertentangan dengan merujuk pada kasus serupa, tetapi kompleksitas esensial tetap tidak cukup teratasi bahkan dengan AI, dan saya rasa ke depan pun akan tetap begitu
    Analisis saya yang lebih rinci terkait hal ini ada di sini: https://smartmic.bearblog.dev/no-ai-silver-bullet/

    • Terima kasih sudah membaca dan membagikan tulisan saya
      Seperti yang Anda sebutkan dalam penjelasan Anda, saya setuju bahwa LLM tidak bisa sepenuhnya menghapus kompleksitas esensial
      Namun, saya rasa LLM bisa menguranginya sampai tingkat tertentu
      Sebagai contoh nyata, saya meminta Claude 4.1 Opus mendefinisikan domain-specific language untuk gambar yang dihasilkan komputer
      Saya hanya menyampaikan kebutuhan saya dan membiarkan detail-detail tertentu tetap samar, lalu LLM menunjukkan bahwa ia bisa menuliskan spesifikasinya
      Dalam kasus seperti ini, saya yakin LLM memang mengurangi kompleksitas esensial
      Saya tentu bisa mendefinisikannya sendiri dengan kualitas tinggi, tetapi jika hasil dari LLM sudah memadai, maka alasan untuk mencurahkan upaya tambahan demi peningkatan kualitas jadi berkurang
      Awalnya saya merasa tidak terlalu membutuhkan LLM karena saya lebih pandai dan lebih menikmati menulis kode sendiri, tetapi setelah mencobanya, saya melihat bahwa LLM bisa mengambil alih porsi besar kompleksitas esensial pada bagian-bagian yang tidak perlu saya habiskan waktu dan energi untuk mengerjakannya sendiri
      Contoh: https://kagi.com/assistant/1b8324a2-ae54-4a1b-9c69-51d76fc5c7d1

    • Kompleksitas yang dikurangi AI pada akhirnya hanya beban kognitif orang yang menulis kode
      'Kompleksitas nonesensial (nonessential complexity)' yang dibicarakan Brooks sebagian besar masih tetap melekat pada kode itu sendiri
      Akibatnya, beban itu dipindahkan kepada orang yang harus membaca kodenya
      Ini seperti memakai baju eksoskeleton untuk mengangkat barang berat ke rak, lalu meminta rekan kerja mengecatnya agar terlihat bagus

  • Makalah "Parse, don't validate" menurut saya adalah karya klasik
    Dan saya merasa sulit setuju dengan kalimat "Don't put logic in tests"
    Dalam contohnya, masalahnya muncul dari fakta bahwa seharusnya tipe URI dipakai alih-alih string, dan saya berpikir bahwa karena kode test juga memengaruhi berhasil atau gagalnya deployment, maka kode test juga harus dianggap sebagai kode produksi
    Bagaimanapun, diskusi-diskusi seperti ini tetap sangat layak ditinjau langsung dan dipertimbangkan apakah relevan untuk diterapkan pada diri sendiri

    • Saya juga heran "Parse, don't validate" tidak terlalu dikenal
      Mungkin karena orang-orang di sekitar saya kebanyakan memakai Go, Python, dan C++, dan tampaknya tulisan itu hanya terkenal di kalangan bahasa fungsional
      Saya rasa sudut pandang kritis terhadap contoh di "Don't put logic in tests" itu valid
      Contohnya mungkin bisa diganti dengan kasus yang sedikit lebih baik, tetapi inti pentingnya adalah bahwa bahkan penggabungan string sederhana pun bisa menambah kompleksitas ke dalam test dan membuat bug terlewat

    • Secara pribadi, saya tertarik pada filosofi untuk tidak menaruh logika (terlalu banyak) di dalam test
      Saya sudah beberapa kali mengalami false positive akibat bug di kode test, jadi saya menjadi tidak terlalu percaya pada bagian itu
      Saya merasa kita seharusnya tidak sampai perlu menulis 'test untuk test'
      Memang kasus seperti itu jarang, tetapi belakangan ini kode test buruk yang ditulis LLM mulai menjadi arus utama, sehingga masalahnya membesar terlepas dari filosofi tersebut

  • Saya merekomendasikan materi investigasi dan ulasan Nancy Leveson tentang kecelakaan Therac-25

  • Bagi saya, tulisan favorit saya di bidang ini adalah "The Parable of the Two Programmers" karya Neil W. Rickert
    Ini adalah kisah yang merangkum kehidupan dan tantangan para programmer dengan ringkas
    https://c00kiemon5ter.github.io/code/philosophy/2011/10/30/Tale-of-two-Programmers.html

    • Saya cukup mengenal Neil karena selama bertahun-tahun sering berinteraksi dengannya di newsgroup Usenet comp.ai.philosophy
      Nada tulisan dan isinya benar-benar sangat khas dirinya

    • Tulisan ini benar-benar luar biasa

  • Bagi saya, tulisan inilah titik baliknya
    https://stevemcconnell.com/articles/software-quality-at-top-speed/

    McConnell tidak terlalu terkenal di sini

    • Terima kasih sudah membagikannya!
      Ini pertama kalinya saya membaca tulisan ini, tetapi dulu di awal karier saya sangat terkesan setelah membaca Code Complete
      Buku itu terus ada di rak saya, dan setiap kali saya membacanya lagi beberapa kali, saya selalu berpikir, 'ini benar-benar luar biasa! Saya harus membacanya lagi nanti'
      Sudah lama saya tidak mendengar kabar tentang McConnell, jadi saya penasaran karena para penulis sezamannya seperti Kent Beck, Martin Fowler, dan Ward Cunningham tetap menulis walaupun popularitas mereka menurun setelah tahun 2000-an, sementara McConnell justru tampak diam
      Ternyata mengetahui bahwa ia meninggalkan software dan beralih menjadi penasihat keuangan cukup mengejutkan bagi saya
      https://raindogllc.com/steve-mcconnell-investment-advisor/

  • Ini mungkin sulit dikategorikan sebagai esai software yang ortodoks, tetapi posting blog "Ban on Imports" karya Gilad Bracha sepenuhnya mengubah sudut pandang saya tentang sistem modul
    Tulisan itu menekankan bahwa import/export pada dasarnya sama dengan global state, dan karena itu membawa semua masalah yang juga dimiliki state global
    Sejak saat itu saya jadi jauh lebih menghargai konsep dependency injection
    https://gbracha.blogspot.com/2009/06/ban-on-imports.html

  • Mungkin tidak mudah diklasifikasikan secara ketat sebagai esai software, tetapi "Don't Call Yourself A Programmer, And Other Career Advice" karya Patrick McKenzie adalah harta karun sejati
    https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

  • Sebagai seseorang yang sangat tertarik pada bahasa pemrograman, tulisan "slumming with basic programmers" sangat membekas di kepala saya
    https://prog21.dadgum.com/21.html
 
secret3056 2025-10-02

Saya sangat relate dengan parsing input pengguna.
Kira-kira di lingkungan seperti apa para coder yang mengembangkan fitur input nomor telepon alternatif itu bekerja, sampai begitu takut memanggil replace() dua kali pada sebuah string?