- Perangkat lunak yang tak berguna adalah bentuk bermain yang membebaskan kita dari tekanan untuk menghasilkan sesuatu yang praktis dan mengembalikan kesenangan dalam komputasi; Hurl juga merupakan eksperimen yang berawal dari sebuah “lelucon”
- Orang teknis mudah terlalu lama berada dalam lingkungan yang menuntut hasil yang berguna, sehingga percikan kesenangan yang dulu membuat kita mulai memrogram bisa memudar
- Dalam proyek main-main, kita sendiri yang menentukan pengujian, issue tracker, dan kriteria selesai, dan bisa berhenti kapan saja saat sudah belajar cukup banyak atau ketika kesenangannya hilang
- Mesin catur, penyimpanan key-value yang mengimplementasikan sebagian Redis API, utilitas Wake-on-LAN, visualisasi catur, dan basis data catur adalah eksperimen untuk mempelajari GUI, sistem, jaringan, dan internal DB
- Memperlakukan komputer dengan lebih santai dan mencoba membuat sesuatu yang “terlihat tidak berguna” adalah cara yang realistis untuk mendapatkan pembelajaran sekaligus kesenangan
Kebebasan yang Diberikan oleh “Ketidakbergunaan”
- Penulis mendapat pertanyaan, “mengapa membuat Hurl?”, dan jawaban singkatnya adalah untuk lelucon
- Jawaban yang lebih panjang adalah bahwa perangkat lunak yang tak berguna memungkinkan kita merasakan kembali kesenangan dan eksplorasi dalam komputasi
- Orang teknis biasanya terikat pada pekerjaan membuat sesuatu yang berguna
- Software engineer menulis kode untuk menyelesaikan masalah nyata
- Ilmuwan komputer meneliti masalah untuk menghasilkan temuan baru yang nyata dan praktis
- Penulis dokumentasi teknis berurusan dengan teknologi dan dokumen yang nyata
- Banyak orang yang mulai memrogram merasakan kesenangan dalam pekerjaan itu dengan caranya sendiri, dan perasaan itu mungkin ikut memengaruhi pilihan karier mereka
- Jika sepanjang hari harus melakukan hal-hal yang berguna, minat mudah memudar
- Hal yang wajib dilakukan selalu datang dengan kewajiban dan tekanan
- Semua aktivitas menjadi terhubung dengan pekerjaan itu sendiri
- Dalam prosesnya, kita mudah kehilangan unsur bermain yang penting
- Perangkat lunak yang tak berguna adalah cara untuk keluar dari kewajiban itu
- Kita bisa menentukan sendiri apa yang ingin didapat dari proyek
- Kita bisa berhenti kapan saja
- Jika tidak ingin menulis pengujian, itu boleh dilewati
- Jika tidak ingin memakai issue tracker, itu bisa dibuang
- Jika sudah mempelajari hal yang ingin dipelajari dan kesenangannya hilang, proyek bisa diakhiri
Proyek-Proyek yang Dibuat untuk Bermain
- Mesin catur dan UI yang buruk penuh bug, tetapi menjadi kesempatan untuk memahami lebih dalam pemrograman GUI, pemrograman game, dan cara kerja mesin catur
- Penyimpanan key-value digunakan untuk mempelajari pemrograman sistem dan cara menulis kode yang lebih efisien sambil mengimplementasikan sebagian Redis API
- Utilitas Wake-on-LAN adalah proyek untuk mempelajari cara kerja WOL dan pemrograman jaringan Rust
- Visualisasi permainan catur memungkinkan eksperimen membuat seni dengan kode dan memvisualisasikan game favorit
- Dalam basis data catur, penulis banyak belajar tentang bitmap dan struktur internal basis data
- Penulis juga membuat alat berbasis LLM yang “mansplain” apa yang dilakukan suatu perintah
- Implementasi protokol sisi server POP3 masih belum selesai, tetapi prosesnya menyenangkan untuk mempelajari protokol itu dan membayangkan seperti apa aplikasi berbasis POP3
- Dengan mengikuti “Crafting Interpreters” dalam Rust, penulis banyak belajar tentang interpreter dan compiler, dan tujuannya bukan menyelesaikan, melainkan menikmatinya
- “Mazes for Programmers” dikerjakan sekitar setengahnya dalam Rust lalu dihentikan karena sudah terasa seperti pekerjaan, dan penulis tidak ingin melanjutkannya
- Skrip-skrip kecil juga ditulis untuk bermain-main dengan ide dan konsep serta bereksperimen
- Hurl juga merupakan salah satu bentuk permainan seperti ini; meskipun tidak berguna, proses belajar dan membuat sesuatu tetap bisa memberi kesenangan
1 komentar
Komentar Hacker News
Saya suka membuat perangkat lunak yang tidak berguna. Yang saya buat tahun ini saja ada uncolouring book di https://lines.potato.horse, MeatGPT di https://meat-gpt.sonnet.io, Medieval Content Farm di https://tidings.potato.horse, You deserve butter di https://butter.sonnet.io, Mrr di https://mrr.sonnet.io, dan Mrr yang akurat secara fisika di https://mrrr.sonnet.io
Sebagian di antaranya sebenarnya lebih mirip tulisan blog yang dibuat rumit; karena lebih mudah mengekspresikan diri dengan bermain-main memakai kode daripada memecahkan masalah nyata, hasilnya jadi dibuat berlebihan. Daftar yang lebih panjang ada di https://sonnet.io./projects
Anak saya yang berumur 8 tahun bermain Scratch setiap hari dan saya sering membantunya kalau ada pertanyaan; ternyata cukup menyenangkan membuat proyek konyol sekadar untuk bersenang-senang, lengkap dengan animasi yang tidak berguna. Berkat itu, sekarang di rumah kami “Hurry to love! Hurry to love!” menjadi ungkapan populer
Ternyata saya sudah lupa cukup banyak dari hal-hal itu
Sepenuhnya setuju. Baru-baru ini saya pergi ke sekolah badut, dan menyadari bahwa selama ini saya terlalu terobsesi untuk mengerjakan proyek dengan “benar” atau “baik”
Hidup itu untuk dijalani, dan kalau kita terlalu berusaha membuat perangkat lunak secara “benar”, kesenangannya jadi terperas habis. Jadi belakangan saya mencoba menulis kode dengan lebih gembira; hasilnya saya menulis jauh lebih banyak kode dan semuanya mengalir lebih mudah. Baru-baru ini saya membuat sendiri library serialisasi biner bergaya protobuf untuk menguji ide evolusi skema, dan sekarang sedang membuat database local-first berbasis CRDT. Kemarin sinkronisasi data pertama berhasil, dan saya benar-benar bersemangat. Selama bertahun-tahun saya menulis banyak kode untuk memecahkan Serious Problems dan juga banyak kode impulsif, tetapi ironisnya kode yang paling saya banggakan adalah yang saya buat untuk bersenang-senang. Proyek yang menyenangkan membuat saya terus kembali untuk memelihara dan memperbaikinya, sementara proyek yang serius sering kali layu dan mati begitu saya tinggalkan
Dalam game, alih-alih mengikuti alur dan memercayai prosesnya, orang mulai membaca panduan untuk membuat karakter terkuat, memaksimalkan stat, dan mengejar penyelesaian 100%. Akhirnya kesenangan dari eksplorasi dan pertemuan tak terduga yang membuat game itu bagus menghilang, dan waktu dihabiskan untuk memaksimalkan stat seperti lemparan dadu acak. Aktivitas lain juga mirip: saat kita berusaha memaksimalkan sesuatu, entah itu kekayaan atau kualitas kode, rasa takjub dan semangat “coba saja” ikut menghilang
https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
Lalu begitu saya terjebak dalam optimasi, tiba-tiba game itu menjadi permainan yang hanya punya satu jawaban benar, dan dalam semalam semua kesenangannya menguap. Sering kali kita belajar lebih banyak saat membuat sesuatu dengan buruk karena kesombongan dan keisengan. Pikiran “Memangnya sesulit apa?” beberapa kali membuat saya terjun ke kedalaman yang sulit saya tangani, tetapi dalam proses keluar dari sana saya selalu belajar banyak dan menemukan kesenangan
Dalam keahlian (craft) apa pun, ada bagian yang terasa berlawanan dengan intuisi. Kalau kita sekadar melakukannya lebih banyak, umumnya pada akhirnya kemampuan kita meningkat. Tulis saja cerpen yang jelek, bentuk tembikar yang buruk rupa, lukis pemandangan yang miring
Mungkin memang ada efek latihan, tetapi juga besar kecenderungan kita untuk membatalkan ide sendiri kalau kita tidak bisa melihat dengan jelas produk jadi yang layak di kepala kita. Terutama bagi orang yang analitis, itu terasa seperti keputusan cerdas untuk mengurangi waktu terbuang, tetapi sekaligus juga cara yang pasti untuk tidak membuat apa-apa. Banyak proyek perangkat lunak “tidak berguna” yang tetap tidak berguna, tetapi ada juga yang dalam proses pembuatannya menemukan kegunaan yang lebih besar. Pada akhirnya ini mengarah ke klise seperti “100% tembakan yang tidak kamu ambil pasti meleset”, tetapi Anda paham maksudnya
Ini bukan hanya soal menulis perangkat lunak yang “tidak berguna”, tetapi juga menjadi argumen untuk menghindari apa yang disebut praktik terbaik dalam proyek kecil
Saya membuat generator situs statis untuk katalog item, dan katalognya sederhana serta tidak sering berubah. Setelah mempertimbangkan basis data apa yang akan dipakai, akhirnya saya memutuskan memasukkan semuanya ke dalam array statis di dalam codebase. Satu dependensi yang perlu dipikirkan berkurang, dan itu sangat cocok untuk tujuan saya
Saya tidak tahu apakah akhirnya benar-benar diubah begitu, tetapi sejak itu, setiap kali ada yang berkata “kita butuh database”, itu selalu menjadi pertanyaan pertama yang saya ajukan
Karena saya toh harus memuat semua data ke memori untuk menjalankan algoritma graf, saya sadar hampir tidak ada gunanya menyimpan data read-only di database. Saya sama sekali tidak berniat mengimplementasikan Bellman-Ford dengan SQL
Saya belajar hal ini saat ngoding bersama seorang teman yang saya kira coder payah
Kami akrab, jadi banyak mengerjakan proyek seru bersama, tetapi ia benar-benar terlihat seperti tidak tahu apa yang sedang dilakukannya. Copy/paste di sana-sini, tanpa arsitektur, tanpa desain, penamaan buruk, dan separuh waktu tampaknya ia sendiri tidak yakin kodenya sebenarnya melakukan apa. Tapi berjalan. Akhirnya saya sadar ia menyelesaikan lebih banyak hal daripada saya. Ia tidak terpaku pada hal-hal sepele, dan bekerja jauh lebih banyak. Ia tidak menulis unit test, tetapi terus menguji secara manual dengan memainkan hasilnya seperti anak kecil. Pada akhirnya saya menerima cara pikir itu. Saya tidak menemukan software kontak yang melakukan fungsi yang saya inginkan, jadi saya hendak membuat sendiri, tetapi saya tidak mencoba membuat UI yang rapi dan cukup memakai django-admin. Saya sudah memakai kumpulan form mengerikan itu selama 10 tahun dan itu menjalankan tugasnya. Saat belum ada CLI untuk TOTP, saya membuatnya dengan Python dan membuang seed ke TOML plaintext. Butuh 5 tahun sampai saya menambahkan enkripsi, karena cukup dengan membuat symlink file dari container Veracrypt dan pekerjaannya sedikit. Dua bulan lalu, saya menginginkan timer yang mengisi anggaran waktu saat saya berolahraga dan menguranginya saat bermain video game, jadi saya membuatnya (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). Saya menempelkan gumpalan Tailwind yang dimuntahkan ChatGPT dan mengendalikannya dengan HTMX, dan itu sudah cukup. Saat saya menunjukkannya kepada teman-teman, 4 orang meminta akun, dan satu orang meminta uji coba untuk dokter pada program adiksi. Bahkan tidak ada form pendaftaran, jadi saya hardcode saja. Saya ingin memberi tahu diri saya yang lebih muda untuk berhenti terobsesi melakukan sesuatu dengan benar atau hanya mengerjakan masalah penting. Toh seumur hidup saya juga belum pernah benar-benar mencapai “kebenaran” itu
Setelah saya mulai membiarkan nama yang diberikan IDE apa adanya sampai proyek itu terbukti menarik, rasanya tingkat keberhasilan saya meningkat. Sepertinya ini terkait dengan prinsip dasar yang sama
Terutama saat merapikan kode orang lain, ada logika yang aneh. Kita mengumpat sambil berkata, “sebenarnya dia mikir apa?”, tetapi pada saat yang sama ada fakta bahwa orang itu sudah memulainya
Namun ia menghasilkan 100 dolar per jam dari negara dengan upah rendah. Ia membeli domain dan konten, membangun ulang perangkat lunaknya, melakukan hal-hal seperti optimasi mesin pencari, lalu menjualnya dalam 3 bulan dengan harga 10 kali lipat dari harga beli. Untung sekitar 7000 dolar untuk kerja 3 bulan tidak buruk, dan kemungkinan besar itu pun bukan pekerjaan purnawaktu
Namun kesimpulannya begini. Pertama, mereka gagal sesering mereka berhasil, tidak mungkin memprediksi mana yang akan terjadi, dan karena memperbaikinya setelah kejadian lebih sulit daripada tidak melakukannya begitu sejak awal, itu terlihat seperti judi dengan nilai ekspektasi negatif. Kedua, secara pribadi saya tidak suka bekerja dengan cara seperti itu. Ketiga, karena itu saya tidak ingin menghabiskan waktu untuk pekerjaan yang mungkin cocok dengan cara seperti itu. Pengalaman ini membuat saya mencari proyek yang lebih dalam dan besar, alih-alih rangkaian pekerjaan kecil dan remeh. Sebagai gantinya, sekarang saya jauh lebih nyaman menerima bahwa orang lain bisa punya preferensi yang berbeda dari saya. Saya jadi lebih banyak memikirkan cara yang cocok untuk saya daripada cara yang benar untuk membuat perangkat lunak
Tapi tetap berjalan. Memang melelahkan, tetapi produktif, dan saya banyak belajar dalam prosesnya. Saya tahu cara merapikan, memoles, serta membuatnya bisa dipelihara dan diperluas nanti, jadi itu akan saya lakukan setelah ada sesuatu yang benar-benar berjalan. Terutama saat mencoba hal baru, pendekatan ini dulu juga cukup produktif, jadi saya sangat mendukungnya
Apple pernah menolak aplikasi saya karena dianggap tidak berguna. Tim peninjau aplikasi menelepon langsung dan mengatakan aplikasi ini tidak berguna dan tidak akan disetujui di Mac App Store
Sekitar 12 tahun kemudian, aplikasi kecil yang tidak berguna itu, KeyboardCleanTool, dipakai oleh ribuan orang. Itu aplikasi gratis yang sangat kecil yang memblokir semua input keyboard dan Touch Bar, dan orang-orang memakainya dengan cara yang tak terbayangkan. Misalnya membiarkan balita memukul-mukul keyboard sesuka hati, atau membiarkan kucing tidur di atas laptop. Apa yang berguna itu benar-benar subjektif
Setelah sekitar sepuluh pencarian lagi, saya baru paham ketika membaca artikel tentang cara yang baik untuk membersihkan keyboard, yang merekomendasikan aplikasi itu karena bisa mengunci keyboard. Akhirnya saya mengunduhnya, dan untuk aplikasi yang “tidak berguna”, ternyata cukup berguna
Saat kecil, ibu saya pernah tidak sengaja menyalakan Mac IIsi kami ketika sedang bersih-bersih, dan saya berhasil memakai kejadian itu sebagai alasan untuk meyakinkannya bahwa kami butuh screen saver After Dark. Tak lama kemudian, toaster beterbangan muncul di layar. Terasa nostalgia
Saat membersihkan, layar MacBook dan monitor harus benar-benar hitam agar debu yang bisa menggores terlihat, dan trackpad juga harus dinonaktifkan. Kombinasi tombol untuk mematikan mode pembersihan perlu sulit ditekan secara tidak sengaja tetapi mudah diingat, jadi saya menetapkan caranya dengan menekan tombol Command berturut-turut minimal 8 kali. Praktik peninjauan aplikasi Apple selalu menyebalkan. Saya tidak mengerti mengapa mereka mencoba memutuskan apa yang berguna atas nama pengguna. Belum lagi aplikasi scam yang lolos peninjauan bisa bertahan berbulan-bulan di App Store
Saya suka memakai software yang ekspresif dan menyenangkan. Untuk belajar dan bereksplorasi; itulah yang menarik saya ke pemrograman dan membuat saya tetap bertahan
Sayangnya, kebutuhan ikut campur. Di bawah ancaman kelaparan, kita harus produktif. Saya peduli pada orang-orang yang berproduksi bersama saya, dan merasa bersalah bila tidak bisa produktif. Itu bahkan menyedot motivasi di waktu pribadi. Mengejutkan bahwa ada banyak orang yang punya stabilitas dan kebebasan untuk mengekspresikan diri. Saya iri, tapi juga senang, pada orang-orang yang bisa pergi ke Recurse Center, orang-orang yang punya begitu banyak tulisan blog berisi proyek pribadi dan kisah petualangan. Kebanyakan dari mereka mungkin telah bekerja keras untuk sampai di posisi yang memungkinkan hidup seperti itu. Saya juga ingin begitu. Namun untuk melakukannya, tampaknya saya harus membakar lebih banyak hidup saya di atas altar produktivitas. Jika saya mengorbankan cukup banyak tahun, mungkin keberuntungan akan memberi saya hak untuk menikmati hidup. Lucu juga. Setelah itu, saya mungkin akan lebih menikmati software yang tidak berguna
Dulu saya merasa membuat software yang berguna adalah tanda pengembang software yang kompeten, dan saya tidak menghabiskan waktu untuk hal-hal yang tidak jelas-jelas berguna dengan cara yang mudah dijelaskan
Itu cara yang sangat bagus untuk mengubah software menjadi pekerjaan remeh. Sekarang saya merasa nyaman membuat sesuatu yang tidak berguna, dan itu menyenangkan. Saya membuat ulang ide yang sudah ada dengan cara baru, dan tidak peduli apakah sudah ada orang yang melakukannya. Kalau hanya untuk bersenang-senang, boleh saja melakukannya dengan cara yang sama seperti meng-cover lagu orang lain. Belajar, menikmati, dan itu sendiri bernilai. Kadang-kadang saya juga menemukan cara untuk memperbaikinya. Saya mempelajari ini ketika mulai menulis firmware. Tekanan untuk selalu harus berguna terlalu besar, dan saya harus merendahkan ego serta menyingkir. Saya mendapati bahwa menulis kode berantakan yang melakukan hal bodoh itu sangat menyenangkan, dan menjadi cara hebat untuk belajar serta mengalami ide dengan tekanan rendah. Selain itu, hal-hal yang tidak berguna kadang menjadi sangat berguna secara mengejutkan. Semua hal tidak berguna yang saya buat selama beberapa tahun terakhir berujung pada kode, wawasan, atau pengetahuan berguna yang tak terduga
Dulu saya menjalankan sebuah pertemuan bernama Houston Recreational Computer Programming Group. Hampir seluruhnya merupakan pertemuan untuk menunjukkan proyek software yang tidak berguna dan menyenangkan, dan itu sangat seru
Sekarang saya sudah pindah, dan saya tidak tahu apakah kota tempat saya tinggal sekarang cukup besar untuk membuat pertemuan seperti itu, atau apakah saya punya energi untuk menjalankannya lagi. Hal yang secara pribadi saya sukai adalah sebulan sekali saya harus membuat proyek kecil untuk ditampilkan kalau-kalau tidak ada orang lain yang membawa apa pun. Selama sekitar 2 tahun, itu hanya terjadi beberapa kali, tetapi salah satunya[1] keluar cukup keren dan saya bangga dengannya. Itu juga tidak sepenuhnya tidak berguna. [1] https://github.com/smcameron/gaseous-giganticus
Baru beberapa menit lalu saya menyelesaikan software yang tidak berguna, jadi tulisan ini sangat tepat waktu
CFR Brackets: https://susam.net/cfr.html
Demo: https://susam.net/cfr.html#3
Source: https://github.com/susam/cfr
Ini adalah bahasa menggambar yang sangat kecil, hanya mendukung 5 perintah: C(ubah warna), F(bergerak maju), R(berputar), [(mulai blok), dan ](ulang blok). Perintahnya sedikit terinspirasi dari bahasa pemrograman Logo, dan minimalismenya terinspirasi dari P′′. Namun, tidak seperti keduanya, bahasa ini tidak Turing-complete. Tidak ada kegunaan praktis yang dimaksudkan; saya membuatnya untuk bersenang-senang. Saya berencana bermain-main lebih lanjut dengan menggambar bentuk-bentuk menarik sambil menjaga kode input sekecil mungkin. “Saya rasa sangat penting untuk mempertahankan kesenangan komputasi dalam ilmu komputer.” — Alan J. Perlis