Mengode Manusia Lebih Sulit daripada Mengode Komputer

 (erikbern.com)
1 poin oleh GN⁺ 2024-09-28 | 1 komentar | Bagikan ke WhatsApp
  • Alat developer lebih sulit dibuat karena harus merancang bukan hanya logika yang akan dijalankan komputer, tetapi juga model mental yang dapat dipahami dan digunakan orang lain
  • Onboarding cepat bukan sekadar fitur tambahan, melainkan hampir seperti produk itu sendiri; pengguna harus bisa mencobanya di laptop mereka dalam hitungan menit dengan mengurangi friksi pada konfigurasi, token API, dan eksekusi awal
  • Pengguna belajar pola dengan mengutak-atik contoh yang berjalan, bukan dari penjelasan konsep inti yang panjang; makin banyak titik awal yang dekat dengan masalah mereka, makin besar peluang mereka berhasil
  • Pesan error, jumlah konsep, penamaan, cara konfigurasi, default, magic, dan syntax sugar semuanya mengubah jalur keberhasilan pengguna, sehingga diperlukan desain yang mudah dibaca dan dapat dikustomisasi
  • Pengalaman developer yang baik bukan sekadar mengurangi fitur, melainkan menurunkan secara besar-besaran kompleksitas yang perlu diketahui sambil tetap mempertahankan cakupan hal yang bisa dibuat

Kode untuk manusia juga menangani model mental

  • Kode untuk komputer adalah pekerjaan memecah tujuan bisnis besar menjadi pernyataan logis yang dapat diikuti komputer
  • Kode yang ditangani langsung oleh manusia—seperti framework, library, API, SDK, DSL, embedded DSL, dan bahasa pemrograman—tidak cukup hanya bisa dijalankan
  • Kode semacam ini memberi instruksi kepada komputer sekaligus harus menangani bagaimana pengguna akan membaca dan memahaminya
  • Desain alat developer membutuhkan bukan hanya ilmu komputer, tetapi juga pemahaman psikologis tentang cara pengguna bernalar

Pengalaman awal adalah produk itu sendiri

  • Masukan untuk alat developer biasanya banyak datang dari power user yang sering memakai produk
  • Pengguna yang tersangkut di tahap awal tidak meninggalkan masukan, sehingga muncul bias penyintas
  • Seperti produk konsumen yang mengoptimalkan funnel onboarding, alat developer juga harus melihat proses sampai eksekusi pertama sebagai inti produk
  • Demi onboarding cepat, struktur produk itu sendiri layak diubah
    • Menghapus konfigurasi wajib
    • Membuat pengaturan token API menjadi sangat mudah
    • Mengurangi friksi awal
    • Membuat pengguna bisa mencoba produk di laptop mereka sendiri dalam hitungan menit
  • Dalam lingkungan yang sudah dipenuhi terlalu banyak alat developer, pengguna sulit memiliki energi atau kesabaran untuk memahami secara mendalam perbedaan dari paket NPM LRU cache tertentu

Contoh mengajar lebih cepat daripada konsep inti

  • Tidak seperti komputer yang mengikuti perintah ketat, manusia kuat dalam pencocokan pola
  • Banyak dokumentasi alat developer menjelaskan terlebih dahulu model data inti, relasi, konsep atomik, konfigurasi, dan cara menjalankan, tetapi manusia belajar lebih baik dengan mengubah contoh yang berjalan dan melihat hasilnya
  • Beberapa contoh bisa lebih berguna daripada penjelasan “core concepts” sepanjang 5.000 kata
    • Pengguna mempelajari cara kerja alat dengan melihat contoh
    • Orang yang punya masalah untuk diselesaikan bisa menemukan titik awal yang cukup dekat
    • Makin banyak titik awal, makin besar peluang menemukan contoh yang mendekati kebutuhan

Mendorong pengguna ke lubang keberhasilan

  • Keadaan dasar dalam pemrograman mirip dengan terus-menerus memperbaiki suatu jenis error
  • Pengguna bisa menghabiskan sebagian besar waktu memakai alat untuk mencari tahu “apa yang tidak berjalan”
  • Jika developer lebih cepat berhasil, mereka akan menyukai alat tersebut; jika terus tersangkut oleh error, mereka akan menyalahkan alatnya
  • Setiap error adalah peluang untuk mengembalikan pengguna ke happy path
    • Memasukkan snippet kode ke dalam pesan exception
    • Menampilkan peringatan yang berguna saat ada kemungkinan pengguna melakukan hal aneh
    • Memberikan tindakan yang diperlukan agar pengguna berhasil

Mengurangi beban konsep

  • Setiap konsep baru yang harus dipahami sebelum memakai alat menjadi titik friksi
  • Dua atau tiga konsep mungkin masih bisa diterima, tetapi tidak banyak pengguna yang mau mempelajari delapan konsep baru
  • Kubernetes tidak membutuhkan semua konsepnya saat mulai digunakan, tetapi makin banyak konsep baru, makin besar bebannya
  • Ada keanggunan pada framework yang kuat tetapi hanya memiliki 3–5 konsep
  • Saat pertama kali memakai React, setelah satu atau dua jam melewati tanjakan konseptual, pengguna bisa mendapat kesan bahwa struktur besar dapat dibuat dari beberapa building block sederhana
  • Tujuannya bukan sekadar mengurangi jumlah konsep, melainkan mengurangi konsep yang harus diketahui pengguna sambil mempertahankan cakupan hal yang bisa dibuat
  • Alat yang hebat bisa mengurangi kompleksitas 90% sambil mempertahankan kemampuan yang sama
  • Alat yang mengurangi kompleksitas 90% dan hanya mengurangi kemampuan 10% pun tidak buruk

Prinsip bebek konseptual

  • Jika di dalam framework ada elemen yang menerima nilai dan menghitung nilai baru, lebih baik menyebutnya function daripada nama baru seperti “compute node”, “valuator”, atau “frobniscator”
  • Prinsip bahwa jika sesuatu berjalan seperti bebek dan berbunyi kwek-kwek seperti bebek, kemungkinan besar itu bebek, juga dapat diterapkan pada desain konsep
  • Meski ada perbedaan halus atau nilainya di-cache, jika cukup dekat dengan function, itu bisa disebut function
  • Menggunakan istilah yang sudah ada menghubungkannya ke model mental yang sudah dimiliki pengguna dan sangat mengurangi jumlah penjelasan yang diperlukan

Membuatnya bisa diprogram

  • Pengguna akan melakukan hal-hal tak terduga dengan codebase, dan dapat menaruh elemen framework di dalam for-loop, fungsi, atau struktur lain
  • Karena itu, hampir semua hal dalam framework harus bisa diprogram
  • Arah desain terkait saling terhubung
    • Membuatnya bisa dipanggil langsung dari kode tanpa melalui CLI
    • Mengurangi file konfigurasi dan menggantinya dengan SDK atau API
    • Jangan membuatnya hanya bisa dibuat satu buah; buat agar dapat diparameterisasi sehingga bisa dibuat n buah
  • Desain seperti ini dapat membuat pengguna menemukan use case baru
  • Memanfaatkan keinginan untuk “meng-hack” di atas framework dapat menimbulkan sedikit kekacauan, tetapi juga bisa mengarah pada penemuan tak terduga

Magic, default, dan syntax sugar harus digunakan dengan hati-hati

  • Misalkan ada fungsi run_notebook yang menjalankan Jupyter notebook di cloud, dan pengguna harus menentukan container image yang akan dipakai
  • Ada beberapa pilihan yang mungkin
    • Selalu mewajibkan argumen image=...
    • Menyediakan image default yang sudah berisi sebagian besar library data science, lalu mengizinkan pengguna melakukan override
    • Memeriksa kode dalam cell dan memilih image secara “magic” berdasarkan dependency yang dibutuhkan
    • Selain cara magic, tetap memungkinkan pengguna memilih image tertentu
  • Jika ingin mengurangi jumlah input dan mendukung use case seluas mungkin, pilihan terakhir bisa tampak menarik
  • Namun selain pilihan pertama, masih ada masalah yang tersisa
    • Magic akan rusak dalam sebagian situasi
    • Pengguna yang membaca kode yang bergantung pada default mungkin tidak menyadari bahwa itu dapat dikustomisasi
  • Jika default tidak berlaku pada 97% lebih kasus dan magic tidak benar pada 99% lebih kasus, harus sangat berhati-hati
  • Coding bukan golf, dan tugas penyedia alat bukan hanya meminimalkan jumlah kode yang ditulis pengguna
  • Perl sangat dioptimalkan untuk kode pendek, tetapi programnya bisa terlihat seperti deretan karakter khusus; Python, meski kodenya 50% lebih panjang, lebih mudah dibaca dan dipahami
  • Orang membaca kode 10 kali lebih banyak daripada menulisnya, sehingga keterbacaan penting
  • Syntax sugar juga harus dilihat dengan standar yang sama
    • Mungkin ada keinginan memasukkan sintaks khusus untuk use case yang umum
    • Namun itu bisa mengaburkan konsistensi dan membuat cara kustomisasi kurang jelas
    • Jika syntax sugar tidak berlaku pada 99% lebih kasus, mungkin lebih baik tidak memperkenalkannya

Prinsip desain untuk pengguna pertama kali

  • Masih ada lebih banyak masalah desain dalam menulis kode untuk manusia
    • Sebagian besar sebaiknya immutable, tetapi tidak semuanya
    • Menghindari scaffolding, yaitu pembuatan kode secara otomatis
    • Membuat feedback loop sangat cepat
    • Membuat pengguna mudah menanggapi fitur yang akan dihentikan
    • Menggunakan automated test untuk snippet kode di dokumentasi dan contoh
  • Mendesain pengalaman pengguna pertama kali mirip dengan membuat lagu pop
  • Meski produser mendengarkan lagu seribu kali, pada kali ke-999 ia harus membayangkan bagaimana lagu itu terdengar bagi orang yang mendengarnya untuk pertama kali
  • Dalam alat developer juga sangat sulit bagi orang yang membuatnya berulang-ulang untuk membayangkan pengalaman pengguna pertama kali

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-28
Pendapat di Hacker News

  • Setiap orang punya cara belajar yang berbeda. Saya perlu konsep inti terlebih dahulu sebelum masuk ke contoh. Apalagi kalau konsep intinya tidak sangat sederhana
    Banyak tutorial mirip seperti merakit Lego sambil dituntun. Kurang lebih, “ini ada kepingan Lego, jadi ikuti saya membuat proyek mainan, dan menjelang akhir hari kamu akan bisa bermain Lego”
    Cara seperti ini tidak terlalu cocok untuk saya. Saya ingin tahu bagaimana dan mengapa keputusan diambil, dan ingin melihat dari sudut pandang penulis. Saya ingin tahu seperti apa rasanya tiap keping Lego, bagaimana mereka saling terhubung, dan bagaimana sampai pada desain tertentu
    Mengikuti tutorial tanpa penjelasan konsep tingkat tinggi yang minimal terasa seperti reverse engineering sesuatu yang seharusnya tidak perlu dilakukan. Saat melihat library atau framework baru, saya biasanya membaca tulisan pengantarnya dan melewati contoh kode “getting started”. Biasanya bagian “advanced” punya lebih banyak pembahasan konsep, jadi saya mulai dari sana, lalu melihat referensi API untuk memahami antarmuka pentingnya, dan terakhir kembali ke contoh kode dasar di awal tutorial

    • Dulu saya mengira diri saya tipe orang “konsep inti”, tetapi belakangan saya sadar saya membawanya terlalu jauh. Sebelum merasa benar-benar memahami semuanya di awal, saya sering menolak melakukan hal di luar zona nyaman
      Sekarang saya jauh lebih sering langsung terjun dan mengerjakan contoh, dan merasa lebih produktif. Sampai batas tertentu ini soal kepercayaan. Saya percaya bahwa orang-orang yang membuat software berkualitas sudah cukup memikirkan agar antarmukanya mudah dipahami untuk kasus penggunaan umum tanpa perlu menggali bagian dalamnya terlalu dalam
      Tentu saja saya sering menemui hambatan yang menuntut saya masuk lebih dalam. Namun situasi itu muncul karena ada 10 hal lain yang berhasil saya lewati hanya dengan kesan permukaan. Jadi ketika saya benar-benar menggali lebih dalam, biasanya saya tidak menganggapnya sebagai buang-buang waktu
    • Sangat setuju. Saat mulai belajar, saya tidak suka “project generator” seperti create-react-app. Itu hanya contoh, dan saya bersyukur belajar React jauh sebelum alat seperti itu muncul
      Alat seperti ini membuat struktur folder tertentu, file template, dan tool yang sudah dikonfigurasi sebelumnya. Jika saya tidak langsung memahami secara tingkat tinggi apa yang dilakukan file-file yang dihasilkan dan mengapa dibuat seperti itu, saya merasa tidak nyaman karena terlalu banyak sihir yang tidak saya pahami
      Setiap kali ada hal baru masuk, saya butuh pengantar tingkat tinggi yang menjelaskan tujuannya dengan mengaitkannya ke konsep yang sudah saya kenal. Setidaknya sebelum memahami secara garis besar antarmuka utama dari black box itu, saya tidak nyaman menangani black box yang terasa seperti sihir. Misalnya jika saya belajar create-react-app dari awal, saya mungkin akan segera mulai menyelidiki tujuan tool yang dikonfigurasikannya, seperti Babel atau ESLint
    • Saya pernah mencoba cara seperti itu, dan saya tidak tahu bagaimana saya bisa belajar ilmu komputer dengan cara itu sampai lulus. Saya bisa mereproduksi solusi, tetapi tidak memahaminya
      Baru beberapa tahun kemudian, setelah melihat banyak contoh praktis yang baik, saya memahami apa yang dimaksud oleh konsep-konsep itu. Setelah pencerahan itu, saya menyempurnakan cara belajar saya
      Pertama saya meninjau konsep inti, lalu mencoba berbagai contoh sampai memahami mengapa konsep itu diperlukan, kemudian membaca konsep inti dengan saksama untuk menyingkirkan edge case yang hilang dari contoh yang naif
    • Saya juga mirip. Saya mengalami masalah ini ketika mencoba memahami mengapa Maven tidak berfungsi. Yang saya butuhkan bukan tutorial “cara memulai”, melainkan prinsip dasar agar bisa memahami apa yang sedang terjadi
      Namun saya pikir memulai dari contoh bisa membantu desain API yang baik. Jika API dirancang dengan pendekatan “konsep inti dulu”, API itu cenderung menjadi API yang baru bisa digunakan setelah konsep intinya dipahami, dan itu tidak baik bagi pengguna yang hanya sesekali memakainya
    • Rangkuman yang bagus. Kecurigaan saya mulai muncul terutama pada kalimat “manusia tidak belajar dengan cara seperti ini”
      Sesuai gaya hacker, tidak ada kutipan. Saya hanya sedikit melihat pedagogi, tetapi itu adalah bidang ilmu yang besar dan matang, yang menarik prinsip-prinsip modern dari psikologi pengalaman Dewey dan Piaget. Ada jauh lebih banyak hal untuk dibahas daripada yang bisa dicakup oleh satu posting blog, apalagi satu bagian dari posting blog
      Masalah terbesarnya, seperti yang sudah ditunjukkan, adalah tiap orang berbeda. Masalah besar berikutnya adalah kita bahkan belum tahu pasti mengapa perbedaan itu muncul dan seberapa stabil perbedaan itu seiring waktu. Tulisannya sendiri bagus dan menggali kegunaan praktis dari strategi pendidikan tertentu, tetapi saya berharap ada sedikit lebih banyak kerendahan hati

  • Belum sampai 2 minggu lalu ada tulisan serupa: https://news.ycombinator.com/item?id=41566097
    Menulis untuk manusia pada akhirnya bisa diringkas menjadi dua keterampilan: empati dan menulis.
    Ada perbedaan besar antara menulis sedikit kode dan menulis aplikasi atau produk. Tulisan ini juga, meski tidak seblak-blakan itu, pada akhirnya membicarakan hal tersebut. Empati penting karena menciptakan perbedaan antara berpusat pada diri sendiri dan berorientasi ke luar.
    Developer yang berpusat pada diri sendiri terutama peduli pada kemudahan, kenyamanan, kesombongan kode, dan kriteria subjektif lainnya. Pada akhirnya yang mereka perhitungkan hanya upaya penyampaian mereka sendiri. Developer yang berorientasi ke luar terutama peduli pada arsitektur dan dokumentasi, karena mereka melihat keberhasilan bergantung pada bagaimana orang lain menerima hasil kerja mereka.
    Kesederhanaan lebih penting daripada kemudahan. Developer yang berorientasi ke luar tidak bisa membaca pikiran orang lain dan tidak tahu apa yang akan terasa mudah bagi mereka, tetapi mereka tahu cara mengurangi jumlah langkah dan menjaga kode tetap kecil.
    Dari sudut pandang produk secara keseluruhan, menulis aplikasi tidak berbeda di dalam otak dari menulis esai, artikel, atau buku. Intinya adalah pengorganisasian dan fungsi. Kode datang belakangan, seperti kata-kata di atas halaman. Orang yang hanya menulis potongan kode tidak mengembangkan keterampilan pengorganisasian tingkat tinggi yang menyatukan semuanya.
    Karena itu saya sangat tidak suka framework. Framework merampas latihan yang dibutuhkan developer untuk menulis software yang orisinal, dan akibatnya menghambat mereka mengembangkan keterampilan pengorganisasian. Orang yang bersangkutan tidak bisa melihatnya, tetapi bagi orang yang bisa melihatnya, ini adalah kesenjangan besar yang sangat jelas.

    • Itu benar, dan juga sebuah dilema. Orang yang membuat framework melakukannya agar orang lain bisa lebih mudah merilis produk. Dalam proses membuat framework, mereka sendiri menjadi developer yang lebih baik.
      Namun orang lain kini harus mempelajari abstraksi mereka, dan sejauh itu menjadi makin jauh dari konsep dasarnya. Itu bisa membuat keterampilan inti yang dibutuhkan untuk melampaui framework menjadi lebih sulit dikuasai. Saya merasakan hal itu saat mempelajari Rails, dan akhirnya menyadari bahwa Rails menyembunyikan terlalu banyak hal, lalu meninggalkannya dan mencoba membangun dari awal.
    • Saya cukup mahir menulis potongan kode, tetapi ketika aplikasi menjadi cukup kompleks, saya cenderung menyerang masalah dengan cara menulis ulang secara melingkar. Saat kompleksitas meningkat, kadang saya terjebak dalam loop penulisan ulang tanpa akhir.
      Menyadari bahwa ini adalah keterampilan yang benar-benar berbeda terasa membuka mata. Bisa dibilang, sekarang ini menjadi unknown unknown yang sudah diketahui.
    • Empati itu bagus, tetapi kita harus memahami kognisi. Kalau tidak, empati dipakai ke arah yang keliru.
      Bagaimana kode ini akan terlihat bagi atasan yang sedang mencekik kita, atau bagi orang yang memperbaiki masalah operasional pukul 2 pagi? Kita tidak tahu seberapa bernilainya jawaban itu sampai benar-benar membutuhkannya. Dan saat membutuhkannya, kita akan membayar mahal untuk jawaban itu—kalau bisa menemukan orang yang mampu melakukannya. Orang seperti itu langka.

  • Saya tidak setuju dengan pernyataan “manusia belajar dari contoh, bukan dari konsep inti.” Mungkin ini terdengar mencari-cari kesalahan, tetapi tidak semua manusia bekerja seperti itu.
    Orang-orang yang lebih suka bergerak dari yang umum ke yang spesifik sudah pada umumnya diabaikan dalam pendidikan SD-SMP-SMA, dan baru mulai merasa cocok saat masuk pendidikan tinggi. Mereka sudah cukup terasingkan, jadi tidak perlu sampai menyangkal keberadaan mereka.

    • Baru-baru ini, saat bepergian dengan pacar dan ayahnya, saya belajar mengemudikan transmisi manual. Pacar saya hanya memberi tahu tindakan kapan harus menginjak dan melepas kopling, dan itu sama sekali tidak membantu.
      Saya tidak memahami nuansa kapan harus melakukan apa, mana yang harus dilakukan benar-benar bersamaan dan mana yang harus langsung menyusul. Lalu ayah pacar saya menjelaskan singkat apa sebenarnya fungsi kopling, dan bagaimana hubungan antara roda dan mesin memengaruhi kedua sisi.
      Saat itu juga saya langsung paham, dan tidak lagi perlu diberi instruksi tentang apa yang harus dilakukan dalam situasi tertentu. Sekitar 20 menit kemudian saya sudah bisa mengemudikan mobil dengan transmisi manual dalam situasi yang katanya paling sulit: mulai jalan di tanjakan miring ke belakang menggunakan rem tangan. Bagi sebagian orang, memahami cara kerja sesuatu dari prinsip pertama jauh lebih berguna, dan menurut saya di kalangan software engineer ada cukup banyak “sebagian orang” seperti itu.
    • Saya membutuhkan keduanya. Bagi saya, pembelajaran sejati adalah mempelajari konsep inti, tetapi contoh adalah kasus dengan jawaban yang sudah diketahui untuk memverifikasi pemahaman itu.
      Jika ada bagian yang mengejutkan dalam contoh, berarti model saya belum lengkap. Atau contohnya yang salah.
    • Mungkin saya lebih lamban daripada teknisi rata-rata, tetapi saya membutuhkan keduanya. Banyak bagian dari pekerjaan saya sekarang terasa membuat frustrasi karena ini perusahaan besar, jadi setiap kali menghadapi pekerjaan baru, yang diberikan hanya contoh bagaimana orang sebelumnya melakukannya.
      Bukan “yang ingin kita capai adalah ini, ini bekerja seperti ini, dan kita melakukannya seperti ini,” melainkan yang selalu terlihat oleh praktisi hanya “kita melakukannya seperti ini.” Begitu ada sedikit saja perbedaan, kita jadi tidak bisa menalar, menyesuaikan, dan memecahkan masalah.
      Untuk tugas yang sering dilakukan memang ada dokumentasi sampai batas tertentu, tetapi biasanya sudah usang atau tidak lengkap. Karena bukan wiki, tidak sembarang orang bisa memperbaikinya kapan saja, dan untuk memperbaiki dokumen harus melewati prosedur yang menyebalkan, sehingga akhirnya tidak diperbarui. Kalau dipikir-pikir, ini cukup mirip dengan masa saya di militer.
    • Saya juga setuju. Cara belajar saya, secara kiasan, adalah membaca manual referensi dari awal sampai akhir. Sering kali materi pengantar yang direkomendasikan saat saya ingin mempelajari hal baru justru kebalikan dari yang saya cari.
      Sekarang pun saya mengalami itu saat meluangkan waktu untuk mempelajari Drizzle ORM. Materi pertama yang saya temukan semuanya berupa “enam contoh query,” dan saya jadi frustrasi karena tidak ada penjelasan mengapa sintaks itu dipakai atau apa pilihan lainnya. Saya lebih nyaman menutup materi seperti itu, membaca semua halaman dokumentasi, lalu baru melakukan sesuatu.
    • Di sekolah, semuanya baru mulai berjalan baik setelah saya mulai berlatih membangun teori di dalam kepala. Caranya adalah membuat hipotesis, mengujinya, lalu menyempurnakannya.
      Saya tidak tahu apakah saya masih bisa melakukannya secara real time sekarang. Cara ini memakai cukup banyak siklus berpikir, jadi sekarang ritme yang lebih cocok adalah membaca tulisan atau menghentikan video sejenak lalu memprosesnya.
      Saya sering harus mengajar secara spontan orang-orang yang belum paham. Jika kita memiliki teori tentang sebuah sistem, kita bisa menjawab pertanyaan yang tidak bisa dijawab oleh teman sekelas yang baru sedikit melampaui hafalan belaka.

  • Ini adalah kalimat dari Code Complete: “Sebagian kecil dari pekerjaan pemrograman adalah menulis program agar dapat dibaca oleh komputer, sementara bagian yang lebih besar adalah menulisnya agar dapat dibaca oleh manusia lain.” hlm. 733
    Kalimat ini terus saya ingat selama hampir 20 tahun

    • “Program dibuat untuk dibaca manusia, dan bahwa komputer menjalankannya hanyalah hal sampingan.”
      Kalimat ini muncul dalam pengantar edisi pertama Structure and Interpretation of Computer Programs karya Abelson dan Sussman, dan mendahului Code Complete sekitar 10 tahun
      Ini adalah pepatah yang berusaha saya pegang, tetapi anehnya para pemberi kerja tampaknya selalu bersikeras pada bagian yang dijalankan komputer
    • Abelson, salah satu penulis SICP, juga pernah mengatakan hal serupa. Intinya, kode harus ditulis agar dipahami manusia, dan pemahaman oleh komputer seharusnya menjadi yang paling akhir

  • Ini agak menyimpang, tetapi beberapa hari lalu saat membuat game Unity, saya sempat berpikir apakah IDE benar-benar hampir tidak berkembang selama 10–20 tahun terakhir
    IntelliSense dasar memang jelas sudah jauh lebih baik, tetapi selain beberapa hal kecil lain, keseluruhan konsep coding tampak hampir sama seperti dulu
    Perubahan positif terbesar justru ada di luar editor. Akses ke library dan dokumentasi jauh lebih mudah, pertanyaan dan jawaban dari pengguna bertambah sangat banyak, dan kadang ada juga alat baru seperti ChatGPT yang mengumpulkan jawaban-jawaban itu lalu memberikan jawaban yang cukup meyakinkan
    Namun secara keseluruhan, aktivitas menulis kode terasa mandek. Jadi sekarang saya sedang berhenti sebentar dari pekerjaan game dan melakukan beberapa eksperimen. Saya tidak ingin membuat bahasa baru, tetapi ingin menyerahkan semua pekerjaan remeh yang mungkin kepada komputer agar bisa fokus pada kreasi
    Tiga hal pertama yang ingin saya uji adalah ini. Mengapa saya harus memikirkan detail kecil bahasa seperti kurung atau terminator; bukankah alat bisa melengkapinya otomatis? Modifier seperti rantai akses private-public atau unsafe juga bukankah bisa ditentukan otomatis oleh alat sebagai himpunan yang paling efisien? Saat fokus pada sekitar 5 method yang saling berinteraksi, saya ingin melihat semuanya di satu layar tanpa membuka banyak jendela dan bertarung dengan slider horizontal/vertikal di VS. Kalau saya membuat HashSet lalu harus mengubahnya menjadi Dictionary atau Tuple, saya ingin alatnya langsung mengubahnya, lalu hanya menunjukkan bagian yang perlu keputusan agar saya bisa menyetujui atau memperbaikinya sendiri. Di Unity, saya juga ingin bisa mengklik method atau kumpulan data lalu memerintahkannya untuk mengubahnya menjadi Burst Job beserta kumpulan NativeData yang terkait

    • Bahwa keseluruhan konsep coding hampir sama seperti dulu itu karena keseluruhan konsep bahasa pemrograman memang tidak banyak berubah. Ada dua pilar besar, mesin Turing dan kalkulus lambda, lalu setelah itu semuanya adalah abstraksi. Kalau abstraksinya bagus, kita menyebutnya paradigma
      Namun pada akhirnya semuanya tetap abstraksi, dan kita hanya menulis instruksi agar mesin yang sangat bodoh menghitung data
      Anda bilang bukankah kurung atau terminator bisa dilengkapi otomatis oleh alat, tetapi komputer benar-benar sederhana, dan bahasa pemrograman adalah saluran untuk menyampaikan pikiran di dalam kepala. Pemisah seperti itu sama pentingnya dengan keyword bahasa, karena merupakan bagian dari aturan. Untuk melengkapinya otomatis, diperlukan lebih banyak aturan dan lebih banyak pemisah
      Kalau ingin melihat beberapa method yang saling berinteraksi di satu layar, ada Vim dan Emacs, atau IDE Smalltalk seperti Pharo
      Transformasi data bisa dilakukan dengan macro Vim dan Emacs. Namun kenyataannya, encoding data sangat penting. Bagi komputer, semuanya adalah bit, dan kitalah yang memberi makna pada bit itu serta membuat aturan untuk memanipulasinya berdasarkan makna tersebut. Untuk mengubah bentuk dari satu kumpulan aturan ke kumpulan aturan lain, diperlukan lebih banyak aturan
      Saya sarankan mencoba lingkungan live programming. Misalnya SLIME untuk Common Lisp, Pharo untuk Smalltalk, atau web inspector untuk JavaScript. Rasanya seperti bekerja di atas kapal yang berada di tengah laut, alih-alih menaruh kapal di darat lalu membayangkan seperti apa rasanya berlayar
    • Menurut saya alasan pengalaman text editor tidak banyak membaik adalah karena itu sering kali bukan bottleneck
      Bagian tersulit dalam pemrograman adalah berpikir dan belajar. Mengetik lebih cepat tidak banyak membantu
    • Soal autocomplete, saya setuju. Bahkan setidaknya 35 tahun lalu editor Brief untuk MS-DOS sudah bisa mendefinisikan template arbitrer dan melengkapinya otomatis
      Misalnya saat menulis program C, kita bisa membuat “f” diekspansi menjadi “for (=; <=; ++) {;}” atau bentuk indentasi yang disukai
      Banyak editor pemrograman modern juga mendukung pengaturan pengguna serupa, tetapi sayangnya dalam banyak kasus prosesnya lebih rumit daripada dahulu kala
      Untuk bahasa pemrograman dengan sintaks yang verbose, menurut saya perlu meluangkan waktu mendefinisikan template agar struktur program apa pun bisa ditulis cepat dengan penekanan tombol seminimal mungkin di editor
    • Hal seperti kurung atau terminator membuat sintaks eksplisit dan sangat meningkatkan dukungan alat. Biasanya editor punya fitur untuk memasukkan hal-hal seperti ini. Namun dalam beberapa kasus, meski tampak jelas bagi saya, sebenarnya itu hanya salah satu dari beberapa pilihan valid, sehingga tanpa dokumen desain atau semacamnya, alat tidak bisa membaca pikiran
      Masalah seperti apakah harus memakai HashSet, Dictionary, atau Tuple punya dampak performa, dan secara abstrak tidak selalu jelas mana yang harus dipakai. Bahasa eksplisit seperti Java, dan mungkin C# juga demikian, mungkin bisa me-refactor pemanggilan method agar menerima tipe lain. Dengan begitu, cukup ubah satu method lalu refactor semua pemanggilannya
      Saya sudah bereksperimen dengan Gemini pro dan ChatGPT o1, dan keduanya benar-benar buruk dalam coding Python dan JavaScript. Mereka menulis kode yang buggy, dan saat mencoba memperbaiki satu bug, sering memasukkan bug lain. Keduanya terasa terburu-buru memberi jawaban alih-alih memikirkan requirement. Menurut saya kita masih agak jauh dari alat yang bisa “membaca pikiran” atau memahami apa yang penting dan tidak penting dengan cara yang kita inginkan
      Hal yang mungkin lebih buruk lagi adalah data pelatihan. Karena sebagian besar kode dibuat oleh coder di bawah rata-rata dan tingkat rata-rata, alat seperti ini akan mengadopsi pola pikir coder rata-rata. Bahkan jika dilatih hanya dengan kode kualitas tertinggi, belum jelas apakah sebagian besar coder bisa memberi prompt dengan benar. Jadi kalau Anda sudah coding selama 10–20 tahun, kemungkinan cukup besar Anda akan selalu agak kecewa pada alat selama mengharapkan sihir instan
      Meski begitu, alat analisis statis non-AI sudah sangat bagus sejak lama dan akan makin baik. Menambahkan AI ke sana bisa membuatnya lebih meningkat lagi. Jika kita memandang alat bukan sebagai seniman yang kita lempari spesifikasi lalu mengembalikan hasil yang lumayan, melainkan sebagai sesuatu yang membantu saya menjadi seniman, menurut saya pengalamannya bisa luar biasa
      Bereksperimen dengan memberi tahu AI hal-hal yang Anda ingin editor lakukan lebih banyak, lalu memintanya membantu konfigurasi, juga bisa menarik. Ada banyak alat non-AI dalam bentuk plugin. Menggunakan model bahasa besar untuk memilih plugin yang cocok dengan gaya hidup mungkin bisa menjadi yang paling efisien
    • Untuk bagian tentang ingin melihat sekitar 5 method yang saling berinteraksi di satu layar sambil mengedit bagian dari beberapa file, haystack mungkin menarik
      https://haystackeditor.com/
      Saya belum mencobanya sendiri, tetapi berniat mencobanya

  • Judul tulisannya bisa diperdebatkan. Karena kode ditulis semata-mata untuk manusia. Komputer tidak membutuhkan “kode”, apalagi kode tingkat tinggi. Bagi komputer, instruksi bahasa mesin saja sudah cukup
    Alasan kita menulis kode adalah karena instruksi bahasa mesin terlalu sulit untuk ditulis manusia, dan lebih sulit lagi untuk dibaca
    Kode tidak boleh dipikirkan sebagai cara berinteraksi dengan komputer. Kode adalah cara manusia memformalkan pikiran, sehingga menjadi cukup tidak ambigu sampai bahkan mesin pun bisa mengikutinya

  • Mempromosikan secara altruistis tulisan blog yang saya tulis dan bagikan minggu lalu
    Move Fast & Document Things [1]
    Saya bukan bermaksud menulis esai filosofis, melainkan ingin berbagi kiat praktis tentang bagaimana tim kecil kami [2] menegakkan budaya penulisan kode untuk diri kami sendiri dan satu sama lain melalui review yang mendalam dan sulit, bukan lewat otomatisasi atau AI
    Semua teman pribadi saya yang menjadi engineering leader di organisasi lain berkata, “Kami juga melakukan hal yang sama, tapi kamu benar-benar menuliskannya.” Jika menurut Anda ini bernilai, mohon rekomendasinya
    [1] https://olshansky.substack.com/p/move-fast-and-document-thin...
    [2] https://github.com/pokt-network/poktroll/graphs/contributors

  • “Terlalu banyak buku dan tutorial pemrograman yang gayanya ‘mari kita bangun rumah dari nol, bata demi bata’, padahal yang saya inginkan adalah ‘ini ada rumah yang sudah berfungsi; mari ubah sesuatu dan lihat apa yang terjadi’”
    Saya belajar pemrograman secara otodidak dengan cara seperti itu. Saya menghabiskan bertahun-tahun menggunakan program-program kecil, sederhana, dan agak buruk dengan cukup baik
    Belakangan saya menyadari bahwa saya tidak cocok untuk pekerjaan pengembangan software yang lebih baik, karena sama sekali tidak punya pengetahuan dasar tentang desain software, bahasa pemrograman, dan komputer. Karena tidak mempelajarinya dengan cara yang membosankan, pengalaman menyadari betapa banyak yang tidak saya ketahui saat keluar dari ruang wawancara itu sangat membuat rendah hati
    Selalu baca dokumentasi lengkapnya, dan selalu pelajari dasar-dasarnya

  • Semua kode saya tulis untuk manusia
    Entah manusia itu saya sendiri, atau seseorang malang yang beberapa tahun kemudian harus memahami maksud saya
    Menulis kode itu sendiri menurut saya tidak sulit. Yang menunjukkan bakat adalah menalar masalah secara menyeluruh, berkolaborasi dengan para pemangku kepentingan lain untuk menemukan jalan terbaik dan memimpin mereka, mempelajari keterampilan khusus seperti matematika baru atau konvensi industri, merancang algoritma yang efisien, serta mengomunikasikan struktur dan pola program agar memiliki batas yang jelas dan elegan
    Pada akhirnya, banyak hal bergantung pada komunikasi dan kejelasan

  • Bagian besar dari tulisan ini membahas dokumentasi, dan akan sangat membantu jika merujuk ke model 4doc: https://docs.divio.com/documentation-system/
    Pada dasarnya, maksudnya jangan hanya menyediakan dokumentasi referensi, tetapi sediakan juga dokumentasi penggunaan. Dan karena bagian itulah yang biasanya ingin dilihat pengguna terlebih dahulu dari keseluruhan dokumentasi, letakkan bagian itu di depan
    Tentu saja itu secara umum; saya sendiri cenderung langsung menuju materi referensi, tetapi tidak selalu
    Ini bukan berarti 4doc adalah solusi ajaib atau hukum alam. Hillel Wayne juga membahas masalahnya dengan baik di sini: https://www.hillelwayne.com/post/problems-with-the-4doc-mode...