Kenikmatan Membuat Perangkat Lunak Mainan

• Membuat perangkat lunak mainan adalah cara untuk memulihkan kegembiraan dan kreativitas yang esensial dalam pengembangan perangkat lunak
• Di era ketika kegembiraan murni dalam pengembangan perangkat lunak memudar karena AI dan industrialisasi, membuat program mainan sederhana sebagai proyek pribadi bisa menjadi kesempatan untuk memperoleh pengetahuan yang berguna dalam praktik serta pemahaman yang lebih dalam
• Perangkat lunak mainan mengikuti kaidah 80:20, yaitu mewujudkan fungsi maksimal dengan kode minimal, dan kuncinya adalah menghindari desain berlebihan atau obsesi terhadap kesempurnaan
• Pengalaman membuat sesuatu sendiri tanpa bergantung pada alat AI seperti LLM adalah kegembiraan mendasar dari belajar dan berkembang

---

Mengapa kita perlu membuat lebih banyak program mainan

• Kutipan terkenal Richard Feynman: “Apa yang tidak bisa saya buat, berarti tidak saya pahami” → pengalaman membuat sesuatu secara langsung mengarah pada pemahaman yang mendalam
• Berbeda dengan nasihat lama “jangan menemukan kembali roda”, pengalaman membuat roda itu sendiri mengajarkan lebih banyak daripada membaca atau belajar teori
• Belakangan ini AI dan industrialisasi perangkat lunak mengancam kegembiraan dan jiwa craftsmanship dalam pengembangan
• Membuat perangkat lunak mainan mengembalikan kegembiraan sederhana yang membuat kita jatuh cinta lagi pada komputer

Prinsip program mainan: Keep it simple

• Perangkat lunak mainan mengikuti prinsip 80:20: mencapai 80% fungsi dengan 20% usaha
• Tujuannya bukan produk akhir, melainkan kesederhanaan dan mengimplementasikan sendiri prinsip-prinsip utamanya
• Menekankan cara kerja yang waspada terhadap over-engineering dan hanya menulis kode yang benar-benar diperlukan
• Disarankan untuk membiarkan semua jalur kode tetap belum diimplementasikan, lalu menambahkan implementasi seperlunya saat dibutuhkan
• Bahkan sistem yang tampak kecil pun, saat benar-benar dicoba, sering terasa lebih mudah dibuat daripada dugaan awal

Manfaat tambahan dari perangkat lunak mainan

• Pengetahuan yang diperoleh dari proyek mainan sering kali jauh lebih membantu daripada perkiraan dalam pekerjaan nyata, seperti melacak masalah, memperbaiki bug, dan mencegah kesalahan
• Mengalami sendiri batasan-batasan saat berhadapan langsung memberi wawasan tentang hakikat perangkat lunak, dan juga bisa membuka jalan pada solusi yang inovatif

Contoh: daftar berbagai proyek perangkat lunak mainan

Jenis-jenis proyek mainan yang telah dibuat sendiri selama 15 tahun terakhir dirangkum beserta tingkat kesulitan dan perkiraan waktu pengerjaan. Setiap proyek disertai penjelasan singkat dan bahan referensi tambahan

• Regex engine (tingkat kesulitan 4/10, 5 hari) : Menafsirkan regex gaya POSIX dan mengidentifikasi string yang cocok, sehingga memberi pemahaman mendalam tentang cara kerja internal regex
• x86 OS kernel (tingkat kesulitan 7/10, 2 bulan) : Mencakup CLI, driver sederhana, memory manager, dan lainnya; bisa diperluas dengan tantangan tambahan seperti in-memory filesystem, executable ELF, GUI, isolasi proses, dan sebagainya
• GameBoy/NES emulator (tingkat kesulitan 6/10, 3 minggu) : Memahami instruction set sederhana dan hardware, serta mengimplementasikan PPU, PSG, dan format cartridge yang khas
• GameBoy Advance game (tingkat kesulitan 3/10, 2 minggu) : Game sederhana berbasis sprite; komunitas pengembangan GBA aktif, dan struktur sistemnya cukup mudah dipahami sendirian
• 2D physics engine (tingkat kesulitan 5/10, 1 minggu) : Newtonian mechanics dasar dan penanganan tabrakan sederhana, dengan kemungkinan dikembangkan ke bentuk kompleks, inersia, algoritme penyelesaian, soft body/interaksi gabungan, dan lain-lain
• Dynamic interpreter (tingkat kesulitan 4/10, 1~2 minggu) : Tree-walking interpreter; membuat bahasa sendiri memberikan kegembiraan teknis sekaligus kreatif
• Compiler keluarga C (tingkat kesulitan 8/10, 3 bulan) : Merancang arsitektur yang mendukung type system sederhana dan lingkungan target, beserta berbagai optimisasi dan backend yang beragam
• Text editor (tingkat kesulitan 5/10, 2~4 minggu) : Mulai dari file I/O sederhana; bisa memakai UI toolkit (QT/GTK, dll.), banyak yang lebih suka berbasis konsol, lalu menambah fitur seperti unicode, syntax highlighting, multi-buffer, LSP, dan lainnya
• Async runtime (tingkat kesulitan 6/10, 1 minggu) : Dalam kasus Rust, menangani task impl Future dan mengimplementasikan konkurensi, lalu menambahkan I/O waking
• Hash Map (tingkat kesulitan 4/10, 3~5 hari) : Mempelajari cara kerja internal, closed dan open addressing, aturan Robin Hood, serta memahami performa dan kapan struktur ini tepat digunakan
• Rasteriser / Texture Mapper (tingkat kesulitan 6/10, 2 minggu) : Mempelajari struktur 3D graphics pipeline, vector math, Z-buffer, dan bisa diperdalam hingga texture mapping serta algoritme shading
• Signed Distance Field rendering (tingkat kesulitan 5/10, 3 hari) : Representasi ruang secara matematis, visualisasi sederhana, serta pemahaman tentang shader dan vector math
• Voxel engine (tingkat kesulitan 5/10, 2 minggu) : Mudah dipahami jika sudah punya pengalaman 3D graphics atau game development; bisa diperluas dengan texture, procedural generation, networking, dan tantangan lain
• Threaded Virtual Machine (tingkat kesulitan 6/10, 1 minggu) : Interpreter cepat yang dioptimalkan tanpa code generation spesifik arsitektur, dan bisa memberi pengalaman performa yang menyaingi compiler
• GUI toolkit (tingkat kesulitan 6/10, 2~3 minggu) : Setelah mencoba membuat alat UI dasar, bisa lanjut mengimplementasikan fitur lanjutan seperti layout engine, text shaping, accessibility, dan lain-lain
• Simulator mekanika orbit (tingkat kesulitan 6/10, 1 minggu) : Mengimplementasikan model gravitasi Newton secara sederhana, lalu memperluasnya ke interaksi banyak benda langit, algoritme integrasi, visualisasi, hingga penerapan data NASA
• Bitwise Challenge (tingkat kesulitan 3/10, 2~3 hari) : Game yang direpresentasikan hanya dengan state 64-bit, melatih pengelolaan state secara kreatif, dan aturan detailnya bisa dilihat di GitHub
• Framework ECS (tingkat kesulitan 4/10, 1~2 minggu) : Mengimplementasikan sendiri struktur Entity-Component-System, mengintegrasikannya dengan type system bahasa, serta menyesuaikannya untuk performa tinggi dan batasan tertentu
• CHIP-8 emulator (tingkat kesulitan 3/10, 3~6 hari) : Virtual machine sederhana dari era 1970-an, cepat dibuat, dan bisa dipakai untuk mengamati maupun menjalankan berbagai fan game
• Chess engine (tingkat kesulitan 5/10, 2~5 hari) : Mulai dari aturan dasar lalu berkembang sedikit demi sedikit; pengalaman kalah dari engine buatan sendiri adalah salah satu momen pertumbuhan seorang developer
• POSIX Shell (tingkat kesulitan 4/10, 3~5 hari) : Memahami prinsip dan keterbatasan shell berbasis POSIX, sekaligus memperoleh pemahaman mendalam dan merasakan banyak trik melalui implementasi kompatibilitas bahasa Shell yang nyata

Saran tentang penggunaan alat seperti LLM

• Alat canggih seperti LLM tetap berguna, tetapi pembelajaran sejati menjadi lebih dalam ketika kita mengeksplorasinya sendiri secara langsung
• Daripada melihat solusi yang sudah ada, kita bisa mendapatkan rasa pencapaian yang lebih besar lewat proses menjelajahi wilayah yang belum dikenal dan menemukan jawaban sendiri
• Saat menjalankan proyek mainan tanpa LLM, pada awalnya mungkin terasa sulit karena belum terbiasa, tetapi seiring waktu kita akan merasakan kegembiraan teknis yang khas dan rasa pencapaian yang tinggi

• Jika bepergian dengan mobil, kita tidak akan merasakan ‘runner’s high’ sebagai pelari → pengalaman langsung, bukan jalan pintas, adalah sumber kegembiraan yang lebih mendalam

[tolluset]

Saya setuju dengan pendapat untuk mencobanya tanpa LLM. Kalau tidak butuh pengembangan yang serba cepat, membuatnya sendiri sambil memahami satu per satu rasanya lebih menyenangkan dan lebih memuaskan.

[nezz1204]

Oh, jadi yang dimaksud itu proyek iseng ya. Dari judulnya saja, saya sempat mengira ini tentang membuat perangkat lunak yang masuk ke dalam mainan. Haha

[GN⁺]

Komentar Hacker News

• Penasaran apakah ada orang lain yang memakai LLM seperti mesin pencari. Dulu saya biasa mencari di Google dengan kueri seperti “pros cons mysql mongodb”, lalu menghabiskan banyak waktu membaca dokumentasi resmi, forum, blog, sampai Stack Overflow. Tapi waktu yang dipakai untuk belajar sambil membaca itu sendiri selalu saya sambut baik. Sekarang saya memberi prompt ke LLM yang lebih spesifik, misalnya “kelebihan dan kekurangan mysql vs mongodb untuk penyimpanan foto, sertakan tautan referensi”. Jadi saya bisa cepat menangkap intinya, dan karena ada tautannya juga, saya tidak perlu bergantung pada halusinasi. Kadang saya juga memberi permintaan yang lebih spesifik seperti “buatkan data schema untuk menyimpan metadata foto di postgres, saya ingin memisahkan X ke tabel lain”, tapi saya hanya melakukan ini saat saya sudah tahu persis hasil seperti apa yang seharusnya keluar. Saya memakainya hanya ketika sayang membuang waktu untuk mengetik atau saat sesaat lupa nama tipe yang spesifik seperti int dan integer

  • Kalau LLM dipakai sebagai mesin tanya jawab teknis, sekilas jawabannya terlihat meyakinkan, tapi sering salah pada bagian yang penting. Kalau dipercaya mentah-mentah dan diikuti, kita bisa membuang waktu berjam-jam atau berhari-hari tanpa guna. Bahkan kalau diminta tautan referensi pun, hasilnya setengah-setengah antara benar-benar berisi informasi yang relevan atau malah tidak nyambung. Meski begitu, ada satu hal yang jelas sangat bagus dilakukannya, yaitu pencarian balik ala "tip-of-my-tongue". Maksudnya, kalau kita menjelaskan sebuah konsep, ia bisa menyarankan kata kunci pencarian yang sesuai dengan cukup konsisten dan memuaskan
  • Sepertinya tak lama lagi perusahaan-perusahaan akan membayar LLM dengan banyak uang supaya produk mereka muncul sebagai perbandingan yang lebih unggul. LLM bisa membingkai dan memberi penekanan secara berbeda agar hasilnya terlihat 'organik'. Itu dimungkinkan karena ia bisa hanya menampilkan informasi yang benar dan berbasis bukti, sambil memainkan 'penekanan konteks'
  • Saya juga memakai LLM untuk pencarian dengan cara yang sama. Rasanya seperti kembali ke masa awal 2010-an saat googling masih sangat kuat. Masa ketika rasanya apa pun bisa ditemukan. Tentu masa itu tidak bertahan lama, dan sekarang googling sendiri adalah penderitaan dan frustrasi. Saya juga banyak keluhan tentang perubahan yang dibuat Google dan para marketer, tapi LLM saat ini terasa sangat efisien untuk memunculkan informasi online ke permukaan secara instan. Tautan referensinya juga umumnya cukup akurat. Pada akhirnya kekuatan perubahan yang sama seperti dulu akan bekerja lagi, jadi ini terasa seperti kesempatan singkat sebelum semuanya kembali memburuk
  • Saya juga salah satu orang yang memakai LLM seperti mesin pencari. Saya belum memakai AI IDE. Baru-baru ini dalam wawancara teknis live, saya mencoba menjawab sambil mengajukan kueri ke LLM pilihan saya seperti saat googling, dan pewawancara bilang ini pertama kalinya dia melihat kandidat memakai AI dengan cara seperti itu. Saya kira kebanyakan developer masih lebih dulu memakainya untuk pencarian daripada AI IDE. Apakah kasus seperti kita ini memang jarang?
  • Bahkan untuk development pun saya memakai LLM seperti mesin pencari. Misalnya, “analisis repo yang saya clone di /src/foo dan jelaskan bagaimana barFeature diimplementasikan. Sekarang lihat proyek /src/baz dan jelaskan kenapa pendekatan di foo sulit diterapkan ke baz”. Saya tidak memintanya melakukan hal baru, tapi memakainya untuk menerjemahkan sesuatu dari proyek yang sudah ada ke ide saya sendiri. Untuk development yang benar-benar baru dan menantang, saya tetap merasa harus menulis kodenya sendiri agar menyenangkan

• Salah satu hal terbaik yang saya lakukan untuk karier saya adalah proyek pribadi yang saya kerjakan saat libur 6 bulan di antara pekerjaan. Awalnya saya punya banyak proyek yang ingin dimulai, tapi karena tidak ada batasan, cakupannya terus membesar dan akhirnya sering tidak selesai. Jadi saya memutuskan untuk hanya mengalokasikan 1 minggu untuk tiap proyek. Saya hanya membuat sebanyak yang bisa diselesaikan dalam 1 minggu. Pengalaman membuat sesuatu yang lumayan berguna hanya dalam 1 minggu, mulai dari nol, dengan bahasa atau framework baru, atau di bidang yang asing, benar-benar membangun rasa percaya diri saya. Itu juga mengingatkan saya kenapa saya dulu suka pemrograman. Kalau suatu saat ada jeda beberapa bulan di antara pekerjaan, alih-alih persiapan wawancara Silicon Valley, membuat proyek mainan justru akan membuat Anda kaget betapa banyak hal yang sebenarnya sudah Anda kuasai

  • Kalau ada alat generasi AI, itu sangat membantu untuk mengerjakan proyek mainan pribadi seperti ini. Saya lebih banyak di backend, tapi front-end juga bisa. Hanya saja CSS dulu memakan terlalu banyak waktu, jadi saya sering tidak menyelesaikan proyek pribadi. Sekarang saya bisa bilang ke AI “buat yang cantik”, dan ia akan membawanya sampai sekitar 85% jadi; sisanya tinggal perbaikan bug atau revisi. Jadi saya bisa menyelesaikannya dengan cepat. Dulu development terasa seperti berkubang di lumpur, tapi sekarang jadi semudah ini, dan itu membuat saya lebih sering membuat proyek pribadi
  • Belakangan ini saya makin tidak puas dengan library yang saya pakai dan jadi beralih ke memperbaikinya sendiri. Kalau saya menemukan dokumentasi onboarding yang tidak lengkap, SDLC yang rusak, atau masalah performa serius, saya bisa menghabiskan seharian penuh untuk memperbaikinya. Berbeda dengan proyek kolaboratif yang ada orang lain menunggu, proyek mainan pribadi itu gampang sekali membuat kita terseret side quest
  • Penasaran bagaimana Anda bisa libur sampai 6 bulan lalu tetap mendapatkan pekerjaan berikutnya. Saya juga ingin istirahat 6 bulan, tapi takut kalau ternyata tidak dapat kerja dan malah jadi menganggur lebih lama
  • Dulu waktu kecil saya menyiapkan server dengan classic ASP + SQL, mengerjakan HTML/CSS/JS sendiri, dan deploy dengan mudah. Waktu itu cukup upload file lewat FTP. Sekarang saya ingin mencoba cara yang lebih modern, tapi setiap kali mengerjakan proyek pribadi saya malah tersesat memikirkan deployment dan proses development (lifecycle). Penasaran bagaimana Anda memilih hosting dan cara deploy untuk proyek mainan
  • Saya juga merasa kecepatan mengerjakan proyek pribadi seperti ini jelas meningkat berkat AI yang bisa menghasilkan bagian boilerplate atau kode otomatisasi testing

• Mengembangkan software mainan itu mirip merawat sepeda, mobil, atau perahu. Menyenangkan. Tapi memperbaiki sepeda untuk berangkat kerja itu membuat stres. Membuat software mainan itu menyenangkan, tapi begitu suatu hari saya benar-benar ingin memakainya, saya malah menemukan semua bug-nya dan tidak punya waktu untuk memperbaikinya. Di situlah dilemanya

  • Saya lebih suka mengembangkan software yang memang akan saya pakai sendiri. Sama seperti mobil, ada kepuasan tersendiri saat bisa memakainya lebih lama dengan biaya lebih murah
  • Dulu saya pernah mengelola server email sendiri, tapi sekarang tidak lagi. Bukan karena saya ingin mengerjakannya sendiri, justru karena saya ingin pekerjaan seperti itu ditangani ahlinya
  • Baru-baru ini saya membuat aplikasi invoice sendiri. Menambahkan fitur satu per satu itu menyenangkan. Saya bahkan memasukkan semua fitur yang biasanya harus dibayar per bulan di layanan berbayar lain. Tapi saat benar-benar harus mengirim invoice, saya sadar ada terlalu banyak hal yang perlu dibereskan di aplikasi buatan saya sendiri, seperti styling, input alamat, dan lain-lain. Pada akhirnya saya merasa perlu menemukan keseimbangan antara kesenangan mengayuh sepeda dan kepraktisan sepeda untuk pergi kerja. Seiring waktu, saya juga menyadari bahwa kesenangan dan kepraktisan itu mungkin makin lama makin mendekat
  • Saya juga punya terlalu banyak hal yang ingin dijadikan “software selesai”, tapi tidak punya waktu dan energi. Banyak sekali pekerjaan membosankan dan repetitif. Meski begitu, mengelola dan menyaring “hasil AI” juga cukup merepotkan. Ini masih tahap eksperimen awal, jadi saya belum tahu apakah beberapa bulan lagi saya masih akan berpendapat sama
  • Karena alasan inilah membuat homepage pribadi itu benar-benar menyenangkan. Saya bisa memakainya sebagai taman bermain saya sendiri

• Agak mengejutkan melihat banyak opini negatif tentang LLM. LLM itu menyuapi informasi langsung ke kita. Saat memulai proyek baru, tentu kita tidak memulainya dengan sudah tahu segalanya. Mencoba sebaik mungkin lalu gagal, setelah itu belajar, memahami kenapa gagal, dan menyesuaikan pendekatan baru—itulah pembelajaran yang sesungguhnya. Kalau kita merasa sudah tahu semuanya lalu hanya mengikuti tutorial, kita tidak akan benar-benar mengalami batasan atau kelebihan-kekurangan nyata dari tiap metode. Misalnya, mencoba membuat parser dengan regex lalu menemukan sendiri bahwa ia tidak bisa menangani ekspresi rekursif, atau belajar secara nyata soal struktur yang lebih kompleks dan isu kompleksitas waktu. Saat benar-benar mengimplementasikan compiler pengoptimal sendiri dan frustrasi oleh berbagai trik optimisasi, kita baru paham kenapa compiler sungguhan dirancang seperti itu. Saat menulis layout engine sendiri, kita bahkan bisa merasakan sulitnya menangani konsep seperti width dengan benar. Tidak ada pengalaman yang lebih baik daripada belajar lewat trial and error. Jangan sampai karena LLM mencegah kesalahan, kita juga kehilangan kesempatan belajar yang penting

  • Banyak orang bilang kalau tidak memakai LLM kita akan tertinggal, tapi saya justru merasa memakai LLM lebih sedikit mungkin akan jadi keuntungan besar dalam jangka panjang

• Saya juga selama bertahun-tahun menghabiskan akhir pekan dan malam untuk mengerjakan proyek-proyek aneh demi belajar computer graphics. Saya tidak menghasilkan uang sepeser pun, tapi berkat itu saya mendapatkan pekerjaan impian saya. Tautan karya yang representatif:

  • Tiny ray-tracer
  • 2D rigid-body simulator
  • Character animation system
  • Animation curve visualizer
  • Motion capture playback in the web Tujuan sebenarnya dari tumpukan kode ini semuanya adalah “memperoleh pengetahuan”

• Saya merasa semangat “kesenangan dalam pemrograman” yang diajukan tulisan ini benar-benar dibutuhkan. Di era coding dengan agen AI, ini malah jadi makin berharga. Tapi saya merasa estimasi waktu penulis untuk proyek mainan terlalu pendek. Saya memang mungkin tidak secepat rata-rata, tapi bahkan dengan asumsi hanya bekerja 2–3 jam per hari, saya rasa kebanyakan proyek di daftar itu bukan proyek yang selesai dalam hitungan beberapa hari. Rasanya riset sebelum mulai saja sudah makan waktu cukup banyak. Sebagai contoh, baru-baru ini saya mengganti blog Pelican saya dengan personal Odin static site generator, dan itu butuh 2 minggu meski saya hanya mengerjakan 2–3 jam per hari. Padahal itu termasuk yang lebih mudah dibanding proyek-proyek lain di daftar tersebut

  • Proyekmu itu sudah lebih dari sekadar proyek “mainan”. Kamu sendiri adalah pelanggan sungguhannya, dan setelah dideploy kamu berharap ia benar-benar bekerja dengan baik. Harapan itulah garis pembeda antara mainan dan alat sungguhan. Dalam satu jam pun orang bisa membuat word processor. Mungkin versi yang hanya menangani satu input, sangat sederhana sampai gila, dan bahkan tidak punya tombol keluar. Tapi untuk sebuah word processor “mainan”, itu sudah cukup
  • Kalau waktu “X hari” ditafsirkan sebagai 24*X jam, daftar ini jadi terasa lebih masuk akal
  • Salah satu kelebihan proyek mainan adalah tidak adanya deadline. Jadi kita bisa mengerjakannya dengan santai dan pelan-pelan. Saya sendiri masih mengutak-atik bahasa Turing-complete berbasis PEG yang saya mulai sejak masa COVID
  • Banyak bergantung pada seberapa jauh kita memakai library pihak ketiga, apa yang kita selesaikan sendiri, dan seberapa ketat kita benar-benar fokus hanya pada inti masalah. Kalau melihat GitHub penulis (https://github.com/ssloy?tab=repositories), kita bisa belajar banyak soal cara menjaga skala tetap kecil. Selain itu, penulis memang sudah punya pemahaman yang dalam terhadap domain masalahnya, jadi bisa menulis kode seterfokus itu. Kalau topiknya benar-benar baru, sulit mengerjakannya dengan cara seperti itu

• Saya juga setuju dengan nasihat “jangan pakai LLM untuk proyek seperti ini”, tapi saya tidak ingin orang menerimanya secara terlalu ekstrem. Menarik juga bahwa nasihat soal bagaimana menerima bantuan dari AI terasa berbeda dibanding meminta bantuan pada manusia. Kalau di bagian bawah blog tertulis “kalau kamu punya teman yang jago programming, jangan pernah minta bantuan darinya”, itu akan terdengar aneh. Teman yang ahli akan memahami konteks dan membantu kita menyelesaikan sendiri. Hampir tidak ada orang yang benar-benar mencoba meminta AI untuk “jangan selesaikan masalahnya untuk saya, tapi bimbing saya seperti teman ahli”. Tentu saat ini mungkin belum bisa atau masih kurang bagus, tapi 1–2 tahun lagi gaya panduan seperti ini bisa jadi terasa sangat alami. Jadi, sebaiknya kita membiasakan diri menyampaikan dengan jelas bentuk bantuan seperti apa yang kita inginkan. Tidak perlu berpegang pada anggapan tetap bahwa LLM pasti hanya akan memberi jawaban salah

  • Saya jelas merasa AI itu masih belum seperti developer ahli
  • Menggunakan LLM seperti teman ahli adalah cara yang paling sering saya pakai. Agar lebih dapat diandalkan, prompt atau pertanyaannya sendiri harus diubah supaya tidak bias. Belakangan ini Claude dan ChatGPT terasa terlalu cenderung setuju dengan pikiran saya
  • (penulis) Sebenarnya saya juga benar-benar akan merekomendasikan “jangan minta bantuan bahkan pada teman ahli”. Menurut saya, kecuali benar-benar buntu, lebih baik hanya membaca sedikit literatur sederhana yang relevan dengan topiknya. Saya sangat percaya bahwa pengalaman mencoba berbagai cara sendiri, menabrak sana-sini, dan memecahkan masalah sambil tersandung adalah unsur penting untuk menumbuhkan kreativitas dan kemampuan problem solving. Masa-masa bingung itu memang perlu. Tentu saja, ini keputusan masing-masing
  • Saya memang memperlakukan LLM seperti “guru”. Saya tidak bertanya dengan gaya meminta jawaban dari seorang intern

• Berkat vibe coding berbasis Claude, saya akhirnya memulai lagi side project yang benar-benar menyenangkan setelah sekian lama. Setelah terbiasa dengan tool dan prosesnya, dalam beberapa minggu saya cepat membuat berbagai aplikasi: dashboard kalender/cuaca untuk keluarga, aplikasi pembaca Bluesky (menyembunyikan posting yang sudah dibaca), dashboard PM perusahaan yang digamifikasi, ekstensi Chrome yang menyembunyikan posting Reddit setelah jangka waktu tertentu, dan aplikasi pengganti plugin WordPress yang tidak terawat. Di awal saya menyerahkan banyak hal ke Claude seperti perbaikan UI, tapi sekarang saya sudah belajar puas di tingkat penyelesaian 90% dan fokus pada fitur aplikasi baru daripada terus menyempurnakan

  • Saya sering dibuat kesulitan karena Claude kadang memperbaiki bug tapi tidak langsung menunjukkan hasilnya. Pernah ada satu perbaikan yang mengharuskan saya meminta output hasil pembaruan sampai 6 kali. Penasaran apakah ada yang mengalami hal serupa

• Daftar ini benar-benar mengesankan. Banyak proyek yang menurut penulis terasa mudah, tapi buat saya mungkin tingkat kesulitannya langsung jauh lebih tinggi. Meski begitu, efek motivasinya untuk membuat saya mulai lagi mengerjakan proyek mainan sendiri jelas nyata. Hanya saja, kesimpulan soal pembelajaran dengan LLM terasa lebih bernuansa. Semuanya benar-benar tergantung bagaimana kita memakainya. Misalnya, permintaan seperti “tolong langsung implementasikan masalah ini” itu buruk sekali untuk belajar, sedangkan “tolong jelaskan struktur ELF pada tingkat abstraksi tertinggi, dengan fokus pada ‘mengapa’” justru pendorong belajar yang luar biasa. Mungkin ada sisi negatif karena kita jadi tidak selalu melakukan riset sendiri, tapi kalau sikap kita benar-benar intelektual dan mau berpikir, bisa mendapat tanya-jawab ala Socrates kapan saja adalah akselerator belajar yang luar biasa

  • (penulis) Itulah tepatnya yang saya maksud di tulisan utama sebagai “jenis pembelajaran tertentu”. Misalnya, untuk mempelajari struktur binary ELF, kita memang tidak bisa mengetahuinya hanya dari menebak sendiri. Kita perlu tahu sejarahnya atau proses pengambilan keputusannya, jadi kita harus memakai referensi seperti spesifikasi, dokumentasi, termasuk LLM. Yang penting secara mendasar adalah “constructive learning” lewat mencoba membangun sendiri; proses eksplorasi dengan jatuh bangun saat membuat format binary sendiri itulah yang membuat kita paham alasan, masalah, dan keseluruhan ruang desain dari format nyata seperti ELF. Untuk pembelajaran eksploratif seperti ini saya menyarankan untuk tidak meminta bantuan LLM. “Kalau hanya diberi laptop, text editor, dan compiler lalu ditinggalkan selama 10 tahun, sampai sejauh mana saya bisa membuat sesuatu? Di titik mana saya macet dan perlu mencari informasi yang konkret?”

• Proyek-proyek yang diperkenalkan di sini memang ide yang bagus, tapi bagi saya tidak ada satu pun yang menarik. Di saat seperti ini saya jadi bertanya-tanya apakah saya memang benar-benar pernah menyukai pemrograman

  • Rasanya saya kebalikan total dari Anda. Sebagian besar proyek di daftar itu menarik buat saya, dan merupakan hal-hal yang ingin dicoba atau memang sudah pernah saya coba. Sebenarnya saya juga sampai baru-baru ini menanyakan hal yang sama, lalu setelah bayi saya lahir dan saya cuti, saya memulai proyek coding yang “sederhana” benar-benar demi bersenang-senang. Saya memutuskan menghapus semua dependency dan membuat semuanya sendiri dari nol, dan ternyata itu jadi jauh lebih rumit dari yang saya bayangkan. Tapi justru karena itu, saya jadi sangat menantikan beberapa jam coding tersebut. Tiba-tiba coding terasa sangat menyenangkan lagi. Mungkin Anda sedang burnout