Ketik Kode Secara Langsung

• Latihan mengetik kode secara langsung dan membuatnya kembali dari ingatan menguji pemahaman dan ingatan dengan lebih ketat daripada sekadar menyalin
• Freecoding adalah kemampuan menulis kode pada tingkat karakter sambil mempertahankan sintaks, tipe, dan nama di dalam kepala, dan ini tetap diperlukan di era tool modern
• Sintaks bukan noise yang mengganggu pemikiran tingkat tinggi, melainkan cara memadatkan makna secara presisi sehingga memungkinkan pemikiran pada level yang lebih tinggi
• Jika tipe dan skema hanya dilihat sekilas saat dibutuhkan, desain sistem menjadi kabur, dan jika model tipe tidak dipahami, penghindaran seperti as any akan makin sering muncul
• Jika ingatan terhadap nama dan pemahaman atas pekerjaan yang sudah ada kurang, agen mudah membuat implementasi duplikat, dan hasil keluaran maupun test juga jadi sulit ditinjau

---

Mengapa harus mengetik kode secara langsung

• Dalam kursus “Learn X the hard way” dari Zed Shaw, peserta dianjurkan untuk tidak menyalin-tempel contoh, tetapi mengetiknya sendiri. Belakangan, ia bahkan lebih tegas menganjurkan agar setelah latihan selesai, kodenya dihapus lalu dibuat ulang dari ingatan
• Fenomena bahwa pemahaman menjadi lebih baik ketika kita secara aktif menghasilkan isi, dibanding sekadar mengonsumsinya secara pasif, dalam psikologi kognitif disebut generation effect
• Seperti kata Richard Feynman, “Apa yang tidak bisa saya buat, berarti saya tidak memahaminya”, latihan membuat ulang kode berdasarkan ingatan menguji pemahaman dan ingatan secara bersamaan
• Ini bukan berarti di era agent coding kita tidak boleh memakai tool pengembangan, tetapi sesekali kita tetap perlu melatih kemampuan untuk menulis kode pada tingkat karakter tanpa kenyamanan dari tool
• Latihan seperti ini berfokus pada kemampuan menyimpan detail pemrograman seperti sintaks, tipe, dan nama di dalam kepala agar kita bisa melakukan “freecoding”

Freecoding dan pengetahuan detail di dalam kepala

• Freecoding adalah kemampuan menulis kode secara langsung berdasarkan ingatan, dan ini menuntut elemen dasar seperti sintaks, tipe, dan nama tetap tersimpan di dalam kepala

• Sintaks dan struktur

  • Harus terbiasa dengan keyword, tanda baca, dan elemen bahasa
  • Ini bukan sekadar menghafal tata bahasa, tetapi terkait dengan kemampuan membayangkan bentuk kode secara akurat

• Tipe dan skema

  • Harus akrab dan nyaman dengan sistem tipe dan model data
  • Jika hanya sampai pada level harus mengecek tabel, kolom, relasi, dan struktur tipe proyek setiap kali diperlukan, maka desain pada level sistem akan sulit dilakukan

• Nama

  • Harus bisa langsung mengingat nama fungsi, method, class, import, file, dan package dengan tepat
  • Saat proyek dan dependensi berubah, pengetahuan ini juga harus terus diperbarui
  • Jika kita tidak bisa mengetik kode yang sudah dibayangkan di kepala dengan tingkat presisi tertentu, maka kemungkinan besar kita sebenarnya belum memahami isinya dengan jelas, melainkan hanya merasa seolah memahaminya
  • Bahasa Inggris tidak sepresisi kode, dan spesifikasi yang cukup detail pada akhirnya akan mendekati kode, sebagaimana dibahas dalam tulisan lain A sufficiently detailed spec is code

Sintaks memungkinkan pemikiran tingkat tinggi

• Meskipun IDE atau coding agent bisa membantu memperbaiki sintaks, kemampuan menangani sintaks secara langsung tetap penting
• Jika seseorang kesulitan memasangkan tanda kurung, wajar jika muncul pertanyaan apakah ia juga lancar menghubungkan premis logis dan kesimpulan dari orang lain
• Sikap yang mengabaikan detail dapat berkaitan dengan functional illiteracy, yaitu berkomunikasi berdasarkan nuansa alih-alih menelaah makna kata dengan jelas
• Contoh prompt LLM terlihat meyakinkan di permukaan, tetapi bila dibaca cermat, ia bisa memuat instruksi yang saling bertentangan pada saat yang sama
  • “Jangan usulkan tool eksternal atau alternatif yang tidak termasuk dalam skill yang tercantum di atas”
  • “Jika tugas memerlukan kemampuan yang melampaui skill yang tersedia, katakan demikian”
• Kemampuan menangani detail kecil seperti tata bahasa, ejaan, dan struktur dengan tepat tidak terpisah dari kemampuan memahami gambaran besar secara akurat
• Sintaks bukan detail yang mengganggu pemikiran tingkat tinggi, melainkan alat mental yang memadatkan dan memungkinkan pemikiran pada level yang lebih tinggi
• Notasi tipe bisa lebih presisi dan ringkas daripada penjelasan dalam bahasa alami

  x adalah array berisi objek, dan setiap objek memiliki properti `domain` wajib yang menyimpan string serta properti `port` opsional yang menyimpan angka
  

  x : { domain: string, port?: number }[]
  

Tipe dan skema adalah petunjuk inti dalam desain sistem

• Fred Brooks dalam The Mythical Man-Month mengatakan bahwa ketika tabel diperlihatkan, struktur umumnya menjadi jelas bahkan tanpa flowchart
• Jika memakai database, kita harus benar-benar hafal tabel, nama kolom, dan relasi dalam proyek
• Alih-alih mengecek informasi ini secara longgar setiap kali dibutuhkan, kita perlu memahaminya lebih dulu dan menyimpannya di dalam kepala agar desain level sistem bisa dilakukan secara efektif
• Tanpa upaya ini, kebingungan dalam berpikir mudah tercermin dalam skema database yang terdenormalisasi, penuh data yang duplikat atau mirip
• Pengalaman dengan bahasa bertipe kuat seperti Rust atau Haskell memperlihatkan dengan jelas manfaat memiliki model mental yang kuat tentang tipe
• Melatih “mental type checker” atau “mental borrow checker” yang akurat tetap membantu bahkan saat memakai bahasa dengan sistem tipe yang lebih lemah
• Jika otot penalaran abstrak ini tidak dipakai, dasar-dasar pemodelan data seperti membuat state yang tidak valid menjadi tidak bisa direpresentasikan juga mudah terlewat
• Jika kita tidak memahami bagaimana tipe saling terkait, kita akan cenderung menaburkan as any ke mana-mana di kode TypeScript
• Jika ketidaknyamanan memikirkan tipe di jalur normal saja tidak sanggup ditanggung, maka jalur abnormal saat harus men-debug error tipe akan terasa jauh lebih berat
• Ini bukan berarti Haskeller atau Rustacean selalu menulis kode yang lebih baik, tetapi jika faktor lain sama, kefasihan terhadap tipe jelas membantu

Harus mengingat nama agar bisa melakukan reuse

• Nama fungsi, method, class, import, package, dan file yang sering dipakai dalam proyek atau dependensi harus bisa langsung teringat
• Ini adalah bentuk khusus dari prinsip yang lebih umum: kita harus akrab dengan apa yang sudah dibuat sebelumnya, yaitu prior art
• Banyak orang bergantung pada coding agent karena mereka tidak tahu bahwa sebenarnya sudah ada prior art yang reusable untuk melakukan fungsi yang mereka inginkan, sehingga agen akhirnya diminta menciptakan ulang roda
• Jika tidak tahu adanya SaaS boilerplate projects, orang mudah mengira agen harus melakukan scaffolding dari nol
• Menyalin proyek open source yang sudah terbukti dan memang dibuat untuk tujuan itu lebih cepat, lebih murah, dan lebih andal daripada meminta agen melakukan pekerjaan yang sama
• Ketika seseorang memprediksi bahwa LLM akan bisa membuat seluruh browser dalam beberapa tahun, sanggahan yang mungkin adalah bahwa hari ini pun itu sudah bisa dilakukan dengan mem-fork Chromium, dan modifikasi serta maintenance-nya juga lebih mudah
• Ingatan terhadap nama juga penting dalam reuse kode di dalam proyek atau perusahaan yang sama
• Jika tidak tahu apa yang harus dicari, kita tidak bisa membangun di atas pekerjaan rekan kerja

Meninjau output agen tetap membutuhkan pemahaman manusia

• Agen bisa membantu mencari nama dan menghasilkan kode, tetapi muncul persoalan baru: apakah manusia masih bisa meninjau hasilnya secara bermakna
• Jika tidak tahu fitur yang sudah ada, sulit menilai apakah agen sedang membuat implementasi duplikat
• Jika pemahaman kita terhadap kode lebih buruk daripada agen, kualitas output agen pun sulit ditinjau dengan layak
• Kita bisa meminta agen membuat test, tetapi jika test yang dihasilkan tidak diteliti dengan saksama, test itu sendiri bisa menjadi kode yang tidak bermakna
• Contoh nyatanya adalah test yang tidak memanggil kode implementasi, melainkan langsung memakai some atau includes pada array dan string hanya untuk memeriksa nilai yang diharapkan

  describe("abort detection logic", () => {
    it("detects aborted stopReason in messages", () => {
      const messages = [
        { role: "assistant", stopReason: "aborted", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(true);
    });
  
    it("detects abort in error string", () => {
      const error = "The operation was aborted";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(true);
    });
  
    it("does not false-positive on normal errors", () => {
      const error = "Network timeout";
      const isAborted = error.includes("abort");
      expect(isAborted).toBe(false);
    });
  
    it("does not false-positive on normal stop reasons", () => {
      const messages = [
        { role: "assistant", stopReason: "stop", content: [] },
      ];
      const isAborted = messages.some((m: any) => m.stopReason === "aborted");
      expect(isAborted).toBe(false);
    });
  });
  

• Dalam pengembangan software ada banyak gesekan kecil sehari-hari. Jika kita memilih untuk tidak melewati gesekan kecil seperti mengingat nama, kemungkinan besar kita juga tidak akan melewati gesekan yang lebih besar seperti meninjau test
• Coding agent menjadikan instruksi pengguna sebagai konteks utama, sehingga pengguna yang malas secara intelektual dapat mendorong agen ke arah yang sama-sama malas

Ketekunan dan kemahiran tidak bisa dipisahkan

• Eustress adalah stres yang bermanfaat. Saat kita mendorong diri sendiri untuk mengerjakan hal baru dan sulit, toleransi terhadap ketidaknyamanan kecil meningkat dan kita jadi mampu melewati ketidaknyamanan yang lebih besar
• Jika selalu menghindari ketidaknyamanan, kita akan jatuh ke siklus buruk yang memperbesar rasa tidak berdaya dan frustrasi
• Ketika kita melatih presisi, ingatan, dan pemikiran struktural di satu bidang, kemampuan di bidang lain juga ikut meningkat
• Seperti LLM yang melakukan generalisasi dari data latih, manusia juga menggeneralisasi kebiasaan dan kemampuan yang dilatih di satu bidang ke bidang lain
• Pengembangan software pada dasarnya menuntut kita untuk secara teratur keluar dari zona nyaman, sejalan dengan tulisan terkait Software engineers are not (and should not be) technicians

[GN⁺]

Pendapat di Lobste.rs

• Sangat setuju. Setelah menyelesaikan latihan, menghapus apa yang baru saja dilakukan lalu mengerjakannya lagi hanya dari ingatan itu benar-benar penting
  Kalau buntu, boleh melihat petunjuk, tetapi tidak banyak hal yang lebih penting daripada membiasakan diri merekonstruksi semaksimal mungkin proses yang barusan dilakukan dari ingatan

• Pesan commit dan dokumentasi sebaiknya diketik sendiri
  Programmer cenderung tidak suka menulis hal-hal seperti ini sehingga mudah berkata, “biarkan LLM saja yang menulis,” tetapi kalau menulisnya sendiri, kita dipaksa menghadapi pengalaman pengguna dan keputusan implementasi di satu tempat yang sama. Akan muncul peninjauan seperti, “untuk melakukan X harus mengoper -Y... tunggu, apakah ini yang terbaik?” atau “ini memperbaiki X dengan Y... tapi bukankah Z juga bisa?”

  • Ini kadang disebut pengembangan yang dipandu tutorial. Alih-alih memikirkan pengalaman pengguna belakangan, pendekatannya adalah memulai dari pengalaman pengguna yang diinginkan, menulis tutorialnya, lalu bekerja mundur dari sana

• Saya tertawa pada bagian yang mengatakan, “jika Anda kesulitan menyeimbangkan tanda kurung, saya meragukan seberapa lancar Anda bisa menghubungkan premis dan kesimpulan logis orang lain,” tetapi juga sempat merasa tersindir
  Kalau boleh membela diri, kadang fungsi memang jadi terlalu besar

• Memperbaiki sampah vibe coding yang tidak kita pahami juga sebenarnya cara yang bagus untuk belajar. Kita jadi banyak mengetik, dan bekerja dalam konteks nyata, bukan dalam ruang hampa

  • Belakangan ini saya membuat sesuatu dengan vibe coding yang lumayan jalan tetapi tidak terlalu bagus, dan kodenya benar-benar berantakan
    Saya menjadikannya kesempatan untuk menulis ulang semuanya dengan tangan dan mengasah lagi naluri pemrograman yang sudah mulai berkarat selama 8 bulan terakhir. Saya suka hasil penulisannya ulang dan memang berjalan lebih baik. LLM tetap berguna untuk menjelaskan atau membantu saat buntu, tetapi rasanya jauh lebih enak ketika saya merasa benar-benar memahami seluruh codebase
  • Tergantung kasusnya. Kadang, sekalipun lipstik pada babi dioles ulang, tetap saja itu babi

• Saya kurang paham mengapa prompt “jangan pernah menyarankan alat eksternal atau alternatif yang tidak ada dalam kemampuan yang terdaftar. Jika sebuah tugas memerlukan kemampuan di luar yang tersedia untuk pekerjaan itu, katakan demikian” dianggap sebagai dua instruksi yang saling bertentangan
  Mengatakan “saya tidak bisa melakukan ini hanya dengan kemampuan yang disediakan” konsisten dengan kedua instruksi tersebut. Kalaupun kalimat terakhirnya berbunyi “katakan kemampuan apa yang diperlukan,” barulah ada benturan, tetapi dengan kalimat yang sekarang saya tidak melihat kontradiksi

  • Sepertinya itu interpretasi yang benar, tetapi ada kemungkinan penulis prompt bermaksud agar LLM tidak sekadar berkata “maaf, saya butuh kemampuan lain tetapi tidak bisa mengatakannya,” melainkan mengatakan apa yang dibutuhkan. Tentu saja, bisa juga memang maksudnya persis seperti bunyinya
  • Saya melihat respons “tidak bisa dilakukan hanya dengan kemampuan yang tersedia” sebagai tidak konsisten dengan instruksi kedua
    Kalimat kedua terbaca bukan sebagai larangan menyiratkan keberadaan alat eksternal atau alternatif secara negatif, melainkan sebagai instruksi untuk mengakui keberadaannya secara konstruktif

• Pernyataan bahwa “orang yang tidak bisa mengekspresikan sesuatu secara fungsional dengan jelas hampir tanpa pengecualian juga kesulitan menulis kalimat yang benar secara ejaan atau tata bahasa” terlihat seperti prasangka yang cukup kasar terhadap orang dengan disleksia atau sekadar orang yang berpikir berbeda
  Tentu itu bukan berarti ia juga mengklaim kebalikannya, yakni bahwa siapa pun yang buruk dalam ejaan atau tata bahasa otomatis tidak jelas secara fungsional, tetapi bagaimanapun ungkapannya terdengar tidak inklusif
  Kalau mau melihatnya lebih konstruktif, kita bisa memikirkan editor node. Sistem berbasis node memang punya banyak masalah dalam implementasinya saat ini, tetapi bila dibuat dengan baik, ia bisa mengendalikan cara program ditulis sehingga beberapa kesalahan sintaks bisa tersaring sejak awal. Misalnya, jika sebuah node menerima string, Anda tidak bisa memberikan angka. Bukan karena pembatasan itu dipaksakan saat build time atau run time, melainkan karena angka sejak awal tidak bisa “diucapkan” di posisi itu. Hal-hal seperti rentang perulangan yang salah, jumlah argumen yang keliru, atau tanda kurung yang tidak seimbang juga bisa dibuat mustahil salah secara struktural
  Menulis perangkat lunak dengan alat yang menegakkan batasan tertentu secara struktural bukan berarti kita tidak memahami batasan tersebut. Itu hanya berarti kita tidak perlu terlalu khawatir akan keliru memasukkan kesalahan jenis itu secara tidak sengaja. Merasa frustrasi ketika alat tidak membantu mengurus detail sintaks seperti jumlah kurung kurawal pada fungsi atau indentasi blok logika juga bukan berarti kita tidak memahami mengapa sintaks itu penting
  Saya memakai sistem node sebagai contoh karena ia menghilangkan unsur LLM yang “lempar lalu lupakan” atau vibe coding tanpa berpikir, dan hanya menampilkan masalah sintaks secara terpisah. Jika LLM dikeluarkan dari pembahasan, argumen yang berfokus pada sintaks menjadi jauh lebih lemah
  Saya setuju dengan bagian lain dari tulisannya, tetapi saya rasa menganggap kemampuan sintaks sebagai indikator mendasar atas pemahaman seseorang terhadap kode atau kemampuannya menulis kode yang baik adalah arah yang sangat keliru

  • Saya tidak bermaksud mengatakan bahwa jika seseorang tidak bisa menulis kalimat yang benar secara ejaan atau tata bahasa, berarti ia tidak jelas secara fungsional
    Saya mengerti ini disampaikan sebagai masukan dengan niat baik, dan saya tidak ingin terlihat defensif. Saya merasa sudah berusaha merumuskannya agar tidak terdengar seperti klaim yang tidak inklusif seperti itu, tetapi saya terbuka jika ada frasa atau susunan lain yang bisa menyampaikan hal yang sama dengan lebih baik
    Namun saya juga tidak ingin menghapus poin itu sepenuhnya. Inti yang ingin saya sampaikan adalah bahwa ketika seseorang mulai menghindari ketidaknyamanan mental secara pengalaman, biasanya ejaan dan tata bahasa adalah hal pertama yang mulai runtuh. Sepertinya ada cara untuk menyesuaikan argumen itu agar orang dengan disleksia tidak dirugikan dalam prosesnya