Bergerak Cepat, dan Berani Menghentikan

• Dalam proses memulihkan game Mac yang belum selesai dari sekitar 1991, terlihat berulangnya cara pengembangan yang cepat mengimplementasikan ide lalu berani menghentikannya jika kurang seru atau kurang mungkin diselesaikan
• Saat itu ada 27 judul dalam daftar, tetapi hanya 5 yang benar-benar dirilis; sisanya lebih mirip prototipe cepat yang dibuat selama sekitar 18 bulan
• Berkat shell umum untuk game berbasis sprite, biaya eksperimen baru menjadi rendah, sementara suara, high score, dan fitur penyimpanan ditunda sampai potensinya terbukti
• Eksperimen seperti kite-fighting, K-10, dan Thief of Baghdad diputuskan lanjut atau tidak berdasarkan keseruan kontrol, tujuan game, serta jumlah art dan implementasi yang sanggup ditangani oleh satu developer
• Proyek yang dibuang pun bukan pemborosan; kode seperti Fisher–Yates shuffle, pergantian kedalaman warna layar, collision detection, dan tabel lookup trigonometri dipakai lagi di proyek berikutnya

---

Memulihkan proyek game Mac lama

• Saat memulihkan file game yang ditulis sekitar 35 tahun lalu dari hard drive lama, eksperimen yang hampir tidak pernah selesai justru menjadi objek yang lebih menarik dibandingkan karya yang dirilis
• Game shareware yang dulu pernah dipublikasikan telah dibundel sebagai disk image dan diunggah ke Soft Dorothy Software — Early Shareware Projects
  • Disk image tersebut berbentuk dapat di-drag-and-drop ke emulator Mac 68K atau PPC seperti Basilisk II, Sheepshaver, dan MiniVMac
• Source dan build tool terkait Glider 4.0, yang diterbitkan oleh Casady & Greene pada 1991, ada di disk image Casady & Greene Projects
• Jika selesai, AirBikes akan menjadi game balap futuristis, tetapi kenyataannya tetap belum selesai

Hanya 5 dari 27 judul yang dirilis

• Dokumen yang dibuat sekitar 1991 merangkum creator code, nama, dan status tiap game
  • creator code mirip bundle identifier yang sangat kasar pada era Macintosh sebelum OS X, dan harus unik untuk setiap aplikasi
• Daftar tersebut berisi 27 judul, dan hanya 5 di antaranya yang dirilis
  • Sisanya sebagian besar adalah prototipe cepat
  • Proyek-proyek ini dibuat selama sekitar 18 bulan
  • Pada saat daftar itu dibuat, tercatat ada 3 judul yang sedang dikerjakan sekaligus
• Utilitas bernama UnMask juga dirilis, tetapi karena tool itu hanya memakan waktu sekitar 10 menit untuk dibuat, ia dianggap layak dikecualikan dari objek analisis

Cara prototyping cepat

• Banyak eksperimen dibuat dengan coding setiap hari sampai larut malam, dan biaya membuat prototipe baru ditekan lewat shell umum untuk game berbasis sprite
• Sketsa game baru terutama memakan waktu untuk membuat sprite dan art dengan MacPaint, sementara cara input unik, mekanik game, dan implementasi fisika membutuhkan sebagian kode
• Fitur seperti suara, high score, dan saved game tidak dibuat sejak awal, melainkan ditunda untuk diimplementasikan nanti hanya pada game yang layak dipertahankan
• Intinya adalah cepat memastikan apakah sebuah ide benar-benar seru
  • Ide yang terlihat seru di atas kertas bisa berbeda dari pengalaman bermain yang benar-benar seru
  • Dengan mengimplementasikan kontrol dan fisika saja dalam beberapa hari, sudah bisa terlihat apakah ide itu layak dilanjutkan

Kriteria untuk cepat memastikan keseruan

• Game kite-fighting dapat diuji dengan mengimplementasikan kontrol menerbangkan layang-layang dan fisikanya dalam beberapa hari
  • Jika mengendalikan layang-layang itu sendiri terlalu sulit, kemungkinan hanya sedikit orang yang akan menikmati gamenya
  • Jika sekadar menerbangkan layang-layang tanpa elemen pertarungan pun sudah seru, berarti ada potensinya
• Game arcade Joust sudah seru hanya dari kontrol terbang dengan tombol flap, bahkan sebelum musuh muncul
  • Baik saat harus mengepak perlahan maupun saat menekan tombol dengan panik untuk naik cepat, keduanya membentuk feel permainan
• Game tentang pesawat kertas di dalam rumah yang berantakan, menggunakan ventilasi lantai untuk mendapat gaya angkat, juga sudah cukup seru bahkan sebelum pemain memahami tujuan untuk melewati ruangan dan menghindari roti panggang dan hal lain
• K-10 adalah game balap lain yang dinamai dari Kansas highway 10, tetapi tidak berhasil melewati tahap prototipe

Menilai apakah harus dihentikan atau dilanjutkan

• Sebagian game sudah sempat diimplementasikan pada tahap awal, tetapi tidak jelas apa yang harus dilakukan setelahnya
  • Di daftar, beberapa game ditandai secara dingin dengan <no point>
• Game platform Thief of Baghdad seru pada bagian melompat-lompat di atas karpet terbang, tetapi tujuan game berikutnya tidak jelas
• Dalam kondisi mengembangkan sendirian, sulit melanjutkan proyek yang meski tampak berpotensi tetapi butuh lebih dari setahun untuk selesai
  • Game adventure berbasis sprite bergaya Dungeons and Dragons memang menarik, tetapi beban kerja yang dibutuhkan besar: gerakan untuk setiap senjata pemain, monster, efek mantra, hingga sistem pertarungan
  • Setelah membuat gerakan menusuk dan menangkis dengan pedang, beban art bertambah karena harus menambahkan variasi seperti gada, busur, dan jubah

Dikeluarkan lagi, dan kodenya juga dipakai ulang

• Game yang ditunda bukan proyek yang sepenuhnya mati; jika source, resource, dan file proyek dapat ditemukan, ia bisa dikeluarkan kembali
• Thief of Baghdad dimulai lagi sekitar 18 bulan kemudian dalam versi warna, mendapat nama Scheherazade, dan mulai memiliki semacam tujuan
  • Pada percobaan kedua pun, daya tarik yang sulit dijelaskan itu pada akhirnya tidak tumbuh cukup kuat, sehingga kembali dihentikan
• Kode dari proyek yang ditunda dapat digunakan ulang pada pekerjaan berikutnya
  • Fisher–Yates shuffle algorithm
  • Kode untuk mengubah kedalaman warna monitor pada Mac awal
  • Kode collision polygon-point
  • Tabel lookup sine untuk trigonometri cepat
  • Rutin dot-product dan cross-product
• Pekerjaan prototyping seperti ini tidak dianggap sebagai pemborosan

Pola iterasi yang berlanjut di Apple

• Seiring berjalannya 1990-an, era developer game Mac indie terasa mulai berakhir, dan ketika mendapat tawaran untuk pergi ke California dan bekerja di Apple, tawaran itu diterima
• Setelah bergabung dengan Apple, dipahami bahwa proyek non-Apple tidak boleh dikerjakan pada waktu luang
  • Secara ketat, coding di luar pekerjaan membutuhkan izin tertulis dari manajer
  • Karena Apple tidak menjalankan bisnis game, izin mungkin saja bisa diperoleh, tetapi kemungkinan mengajukan lalu ditolak tetap menjadi beban
• Cara prototyping cepat tetap berlanjut bahkan pada proyek kerja yang bukan game
  • Rekan-rekan lain mengulang desain di whiteboard dan merencanakan dengan hati-hati sebelum menulis kode
  • Penulis lebih suka langsung terjun, mengompilasi, lalu mengulang
• Pola yang berulang adalah cepat mengumpulkan kode untuk menemukan bottleneck lebih awal, lalu jika perlu memulai proyek hampir dari awal lagi
  • Bahkan setelah memulai proyek sekitar tiga kali lalu mengulang dari awal, sering kali kondisi yang cukup baik tercapai pada waktu yang mirip dengan saat rekan-rekan yang merancang secara hati-hati mulai menjalankan kode mereka
• Revisi kode terakhir biasanya berupa penyederhanaan, dan dengan sejak awal memperlakukan kode sebagai sesuatu yang bisa diubah besar-besaran, penulis memperoleh intuisi tentang bagaimana kode itu sebaiknya diorganisasi
• Ada juga pengalaman saat bisa menjawab rekan yang merekomendasikan Bloom Filter bahwa solusi itu sudah dibuang, karena data nyatanya terlalu kecil sehingga keuntungan performanya minim dan hanya menambah kompleksitas codebase

Always Be Iterating

• Menjelang pensiun, penulis merasa telah menjadi karyawan yang berkontribusi dan rekan kerja di Apple
• Berbeda dari masa coding sendirian semalaman, para engineer yang bekerja bersama menjadi bagian terbaik dari bekerja di Apple
  • Di antara orang-orang yang pernah bekerja bersama, ada programmer yang lebih hebat dari penulis hingga lebih dari satu digit tingkat
• Penulis merasa dirinya termasuk salah satu programmer tercepat, kira-kira orang yang bisa membuat dua versi prototipe jika diperlukan untuk demo rapat minggu itu
• Kalimat yang berulang kali ia ucapkan kepada putri-putrinya adalah A.B.I.
  • “Always”
  • “Be”
  • “Iterating”
  • yaitu “Always Be Iterating”
• Proyek, source, dan tool dari game-game yang tidak pernah dirilis telah dirapikan sebagai disk image dan dipublikasikan di GitHub
  • Soft Dorothy Software: Unfinished Tales (Vol. 1)
  • Soft Dorothy Software: Unfinished Tales (Vol. 2)
• Volume 3 juga direncanakan, tetapi karena ada pekerjaan merapikan setiap proyek agar bisa “release”, waktu publikasinya belum dijanjikan

[GN⁺]

Opini Hacker News

• Sejak mulai memprogram sekitar 1989, ada setidaknya belasan, paling banyak mungkin seratus proyek yang saya tinggalkan begitu saja, dan sebagian besar adalah game. Kebanyakan dibuat untuk Mac Plus atau Mac LC, dan banyak yang punya mekanik atau gaya seni mirip dengan yang disebutkan di tulisan itu
  Beberapa proyek yang sempat dirilis atau saya ikuti terasa seperti bayangan diri saya. Resume dan karier saya juga begitu. Rasanya seperti sidik jari dari sosok utuh yang menjalani kehidupan impian yang tak pernah terwujud, karena tidak punya kesempatan membangun keberhasilan sejak awal. Karena itu saya melihat pendapatan dasar bisa melipatgandakan potensi manusia 10x atau 100x, membawa kita dari ekonomi jasa menuju agensi dan aktualisasi diri, serta memungkinkan tiap orang menciptakan pendapatan residual. Dan saya benar-benar banyak memainkan Pararena

  • Saya punya pandangan berbeda, dan saya mulai melihatnya begitu karena saat pandemi, di sekitar saya dan teman-teman muncul situasi yang mirip pendapatan dasar. Orang-orang yang tidak perlu bekerja lagi menjadi depresi cukup cepat dibandingkan mereka yang tetap bekerja, dan itu mengubah pandangan saya tentang pendapatan dasar
    Lingkungan Anda mungkin berbeda, atau negara Anda mungkin tidak mengambil pendekatan seperti itu. Saya penasaran apa bedanya mengerjakan banyak game dengan fokus pada satu game sampai selesai. Jika ada pendapatan dasar, apakah hal-hal seperti ini bisa terus dilakukan—bukan hanya sebentar—sampai menghasilkan proyek yang selesai? Pada tahap hidup tertentu seperti saat menjadi orang tua atau masa kanak-kanak, pendapatan dasar mungkin masuk akal, tetapi pada masa mencari jati diri, saya rasa tanggung jawab justru membantu
  • Pendapatan dasar tidak akan berhasil. Di negara kami, itu hampir sudah diterapkan. Orang bisa menerima 600 euro per bulan dan berbagai tunjangan kesejahteraan tanpa bekerja, tetapi hasilnya adalah defisit publik tertinggi di UE, tarif pajak termasuk tertinggi di dunia, kriminalitas merajalela, sulit mencari uang dari bekerja karena pajak tersebut, orang-orang terdidik pergi ke luar negeri secara besar-besaran, dan sebagainya
  • Kalau upah minimum saja tidak berjalan baik, saya tidak tahu indikator apa yang membuat orang percaya bahwa sistem serupa yang memberi uang kepada orang yang tidak bekerja akan berhasil
    Pola pikir seperti ini benar-benar sulit dipahami. Pendapatan dasar yang seperti sulap itu akan menjadi upah minimum bagi massa yang tidak bekerja; bagaimana mungkin itu bisa berkelanjutan atau baik?
  • Kita menjalani kehidupan yang berbeda. Saya hanya pernah terlibat dalam proyek-proyek yang produknya seharusnya lebih baik dibuang saja. Memang bukan game, tetapi maksud saya begitulah kondisinya saat dirilis
    Secara teori, ada opsi untuk menyelesaikannya dengan benar, tetapi kalau itu dilakukan, organisasinya akan bangkrut, jadi itu hanya opsi teoretis. Melihat kondisi perangkat lunak yang saya gunakan untuk bekerja dan terpaksa saya gunakan juga secara pribadi, sepertinya semua orang di sekitar saya menjalani hidup seperti ini. Untungnya pengguna tidak punya pilihan, jadi mereka harus membeli sesuatu yang buruk atau tidak membeli apa pun sama sekali. Kami aman meski menjual barang buruk
  • Hal-hal yang tidak selesai cukup disebut riset. Saya punya beberapa proyek Unreal Engine 4/5 dan pasti tidak akan pernah menyelesaikannya, tetapi dari sisi menguji mekanik game, rigging dan animasi, pengembangan shader, serta pembuatan aset 3D, itu menyenangkan

• Banyak perusahaan tempat saya bekerja berjalan seperti ini. Para engineer membuat fitur baru yang berkilau, fitur itu dirilis, dan semua orang senang. Beberapa bulan kemudian bug menumpuk
  Orang-orang yang awalnya membuatnya sudah pindah ke tim lain. Dalihnya “memecah silo”, tetapi praktiknya lebih mirip “membuat semua orang bisa digantikan”. Engineer yang mewarisi proyek harus memelihara dan memperbaiki bug sampai tim lain lagi mengambil alih. Mengerikan

  • Ini neraka yang kita ciptakan sendiri dengan menerima minimum viable product secara luas sebagai cara pengembangan produk yang benar. Kita menilai kelayakan dari daftar fitur, bukan dari apakah benda bodoh itu kokoh atau bisa dipelihara
    Selain itu, “minim layak jalan” hanya satu langkah dari “tidak layak jalan”. Semua proyek menjadi seperti Icarus, menguji seberapa dekat ia bisa terbang ke matahari sebelum sayapnya meleleh
  • Saya sering bercanda bahwa semua lowongan startup setelah Series A seperti meminta kita melakukan Viscera Cleanup Detail[1] untuk membereskan kekacauan para “pahlawan” dari tahap sebelum product-market fit
    [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
  • Saya adalah pembuat asli fitur yang mendefinisikan perusahaan, lalu setelah diberi tahu bahwa “kita harus memecah silo” dan saya disingkirkan, saya menyaksikan pekerjaan saya dirusak selama bertahun-tahun; jadi saya sepenuhnya setuju
    Orang-orang yang mewarisinya kurang layak mengambil keputusan, visi besar saya tersisih, dan melihat ketidakmampuan dalam mengelola fitur itu sulit ditahan. Sampai sekarang saya masih kesal setiap kali bug bodoh muncul. Apalagi saya sudah memperingatkan mereka ketika masih ada cukup waktu untuk menyesuaikan. Namun saya mendapat pelajaran penting, dan lain kali saya bisa mengatakan dengan yakin bahwa meski terlihat seperti orang keras kepala, saya tidak akan mundur dan akan melawan
  • Benar sekali, tetapi menurut saya itu bukan poin yang ingin disampaikan tulisan asli, atau bukan maksud tulisannya. Tulisan itu lebih berupa anjuran untuk mencoba berbagai hal, mendapatkan intuisi apakah itu memungkinkan secara teknis dan terlihat menarik bagi pelanggan, lalu mendorongnya lebih jauh
    Ini cocok untuk developer indie, dan sampai batas tertentu juga bisa diterapkan di perusahaan besar. Filosofi ini bagus untuk mengidentifikasi fitur atau produk yang layak diberi waktu bermakna. Justru situasi yang Anda gambarkan bisa dilihat sebagai akibat langsung dari tidak mengikuti cara yang disarankan tulisan asli
  • Yang Anda gambarkan tampaknya tidak terlalu berkaitan dengan tulisan ini

• Belakangan ini saya kembali mengerjakan pengembangan retro. Saya sedang membuat perangkat lunak untuk Macintosh 68K, tempat saya pertama kali belajar pemrograman.
  Saya banyak membongkar buku-buku lama, tulisan comp.sys.mac.programmer, serta kode sumber seperti Soft Dorothy dan GliderPro. Melihat kode lama dengan sudut pandang baru adalah pengalaman yang aneh. Saya jadi melihat mengapa Mac zaman dulu begitu sering crash, lebih dari sekadar penjelasan “tidak ada proteksi memori”. Seperti yang dikatakan penulis, saya juga suka seni 1-bit, jadi saya mengelola daftar akun Twitter yang mengunggah seni 1-bit. Kalau ada yang terlewat, beri tahu saya: https://twitter.com/i/lists/1578111923324944397
  Hal bagus dari memprogram untuk sistem yang terbatas adalah ia membatasi pilihan. Ini menjadi jeda yang menyenangkan dari pengalaman modern, ketika kita bisa melakukan apa saja asal menarik library yang tepat. Kadang saya membayangkan dunia ketika kemampuan komputasi membeku, dan perangkat lunak untuk sistem yang sudah dipahami dengan baik saja yang terus membaik. Sistem lama seperti Mac 68K terasa memusingkan karena laju kemajuan hardware terlalu cepat. Ketika prosesor baru seperti 68020 atau 80386 muncul, waktu untuk membuat sesuatu yang benar-benar memanfaatkan potensinya paling lama hanya beberapa tahun. Kalau terlambat, kita harus bersaing dengan software baru untuk generasi hardware baru

  • Melihat kembali kode saya dengan hindsight lebih dari 30 tahun, saya jadi ingin melakukan refactoring dan menyederhanakan pekerjaan rutin seperti merespons event jendela.
    Saya juga ingin membuat fungsi wrapper untuk menangani Handle dan sebagainya. Meski begitu, seperti yang dikatakan, mengejutkan betapa sederhananya Toolbox dibanding sistem operasi modern. Mencoba lagi pengembangan retro terasa sangat menyenangkan
  • Saya membuat seni 1-bit untuk Playdate, platform yang terbatas. Tidak seterbatas Macintosh Plus. Di Twitter saya @gingerbeardman dan contohnya ada di sini: https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
  • Saya menyukai seni 1-bit karena gambar-gambar dithering di Mac 68k. Beberapa foto yang saya punya untuk wallpaper komputer juga sudah saya dithering

• Seluruh blognya keren. Ada banyak hal menarik yang layak dijelajahi.
  Tidak apa-apa membuang sesuatu; dari proyek yang dibuang pun kita bisa belajar, dan sebagian darinya mungkin bisa digunakan ulang. Momen terobosan bagi saya adalah ketika saya memutuskan untuk membuatnya cukup kecil agar bisa diselesaikan. Itu membantu saya mengembangkan keterampilan menyelesaikan, dan ini adalah keterampilan tersendiri yang sulit dipelajari. Alasannya, keterampilan itu baru muncul di akhir proses yang terlalu panjang dan melelahkan, sehingga hampir tidak pernah sampai ke sana. Semua teman saya yang membuat video game selalu mulai dengan menulis engine sendiri, lalu burnout ketika tiba saatnya membuat level editor. Mereka belajar banyak hal seperti pembuatan tool, yang ironisnya mirip dengan hal yang memang sudah bisa mereka lakukan, tetapi game-nya sendiri tidak pernah jadi. Itu seperti belajar pertukangan batu sambil membangun katedral; akhirnya tidak akan pernah selesai. Mulailah dari sesuatu yang begitu kecil hingga nyaris tidak mungkin gagal, lalu naik ke proyek yang makin besar

  • “Semua teman saya yang membuat video game mulai dengan engine mereka sendiri” adalah hal yang juga beberapa kali saya alami. Bahkan ketika memutuskan memakai tool yang sudah ada, kita tetap mudah jatuh ke kubangan kompleksitas yang tak berdasar.
    Saya sedang mengerjakan proyek Unity, dan sempat kesulitan memikirkan cara terbaik membuat sistem penempatan bangunan bergaya RTS. Alih-alih langsung terjun seperti biasanya, saya memutuskan mengubah konsep game agar pemain tidak perlu menempatkan bangunan sama sekali. Setelah dicoba, ternyata untuk hal yang ingin saya buat, pengalaman penggunanya justru lebih baik. Awalnya saya merasionalisasi, “tambahkan sistem bangunan di iterasi berikutnya,” tetapi sekarang sepertinya saya tidak akan melakukannya.
    Mengurangi hampir selalu lebih baik. Benar-benar menyelesaikan titik awal yang kecil itu seperti nitrometana untuk iterasi berikutnya. Harus mencapai 100% agar giliran berikutnya jauh lebih baik. Jika berhenti di 80%, yang tersisa hanya perasaan harus mendorong batu itu kembali ke atas bukit
  • Rasanya saya belum pernah menyelesaikan satu pun proyek pribadi. Setidaknya bagi saya, itulah keterampilan yang paling sulit dikembangkan
  • Berfokus memangkas proyek pribadi sampai cukup kecil untuk benar-benar diselesaikan mungkin tepat sekali saya butuhkan sekarang
  • Baru-baru ini saya berpindah dari pengembangan frontend ke bidang aksesibilitas. Beberapa tahun lalu saya membuat beberapa situs statis, template, dan proyek desain, tetapi akhirnya terbengkalai karena berbagai alasan.
    Setelah bekerja di aksesibilitas, saya mengeluarkan kembali banyak di antaranya dan membuatnya ulang agar accessible. Beberapa memakai versi Bootstrap yang sangat lama, jadi saya sekaligus meng-upgrade-nya ke Bootstrap terbaru. Hanya dengan memperbaiki desain lama agar accessible, saya belajar sangat banyak. Saya merasa mendapatkan sudut pandang yang jauh lebih baik tentang apa yang harus dilihat saat mengevaluasi situs dan aplikasi. Itu juga membuat saya sadar betapa tidak accessible-nya hal-hal yang pernah saya buat
  • Keterampilan menyelesaikan apa yang sudah dimulai terasa seperti sesuatu yang hilang dari diskusi tentang produktivitas. Saya penasaran apakah ada tulisan blog atau artikel yang menjelaskannya lebih rinci

• Game-game John adalah inspirasi bagi saya ketika pertama kali belajar pemrograman di Mac saat kecil. Saya sering memainkan Glider, dan lebih sering lagi Pararena. Sampel pembuka yang bergema itu masih tertanam di kepala saya sampai sekarang.
  Saya mungkin menghabiskan lebih banyak waktu lagi mengutak-atik resource fork game-game itu dengan ResEdit. Saya tidak menyelesaikan banyak hal, tetapi saya sempat merampungkan beberapa game shareware kecil dan mengunggahnya ke AOL. Beberapa bulan kemudian, saya benar-benar terkejut ketika sebuah cek dari California yang jauh tiba di kotak surat.
  Masa-masa awal Mac benar-benar waktu yang istimewa, dan ada perasaan bahwa seorang developer solo, hanya dengan kreativitas dan waktu, bisa membuat sesuatu lalu merilisnya ke dunia. Terima kasih sudah menulis ini dan membawa saya kembali ke kenangan itu; semoga Anda menikmati masa pensiun

  • Mungkin Anda pernah membaca tulisan saya yang lain atau README di repositori disk image saya. Masa itu memang istimewa.
    Apakah itu istimewa karena bagi kami, sebagai pengguna komputer awal dan developer awal, semuanya terasa baru? Ataukah memang ada sesuatu yang berbeda di udara saat itu? Saya senang Anda menyukai game-game kecil yang saya buat. Saya juga penasaran apakah cek dari California itu yang mendorong Anda ke jalur karier apa pun yang Anda jalani sekarang

• Jika tujuan tulisan ini adalah menormalkan tindakan membuang proyek, saya tidak yakin itu ide yang bagus. Terlepas dari hal lain, itu bisa menjadi pemborosan waktu yang luar biasa, dan tidak bisa dibenarkan hanya dengan mengatakan “setidaknya ada yang dipelajari”. Bukankah kita juga harus belajar sambil menyelesaikannya?

  • Dalam sebuah episode bagus dari Smarter Every Day, Destin bekerja bersama bengkel kerajinan kaca untuk memasukkan Prince Rupert's drop yang sudah pecah ke dalam blok resin.
    Karena belum pernah ada yang melakukannya, mereka mencari caranya sambil berjalan, dan membuat cukup banyak kesalahan di tengah proses. Salah satu poin yang ditekankan dalam video itu adalah ketika hal seperti ini terjadi, tim tidak berhenti begitu saja lalu mencoba hal yang sama lagi. Mereka tetap melanjutkan sampai benar-benar rusak, lalu menjadikannya kesempatan untuk bereksperimen sebebas mungkin dengan material tersebut.
    Ia berbicara panjang lebar tentang betapa hebatnya hal ini. Karena mereka bebas mencoba hal-hal yang tidak akan dilakukan jika sedang berada di jalur membuat produk jadi yang sempurna dan dipoles, mereka memanfaatkan kesempatan yang tak tertandingi untuk mempelajari lebih banyak perilaku material yang sedang ditangani. Karena sulit untuk membuat sesuatu yang sudah menjadi sampah menjadi lebih rusak lagi, bisa dibilang mengambil risiko tambahan pun bukan lagi benar-benar risiko.
    Saya rasa benar bahwa pola pikir yang lebih menekankan pembelajaran dan eksperimen daripada hanya keberhasilan adalah salah satu cara terbaik untuk menjadi benar-benar hebat dalam pekerjaan yang dilakukan.
  • Ia memang benar-benar menyelesaikan sesuatu juga. Intinya adalah menghindari analysis paralysis dan “langsung mencoba” alih-alih terus berpikir saja. Ini adalah bias untuk bertindak sekaligus sikap menolak sunk cost.
  • Itu salah membaca tulisannya. Tulisan ini lebih dekat dengan penemuan lewat prototyping iteratif yang cepat, termasuk menemukan cacat fatal sejak awal dan dengan cepat.
  • Menurut saya judulnya kurang bagus. Pelajarannya lebih dekat ke “kerjakan semua yang terpikir olehmu, tetapi jangan merilis apa pun sebelum siap. Beberapa proyek mungkin tidak akan pernah siap, dan itu tidak apa-apa. Tiga puluh tahun kemudian, kamu bisa mengunggahnya ke GitHub sebagai kenangan.”
    ChatGPT merangkumnya sebagai “buat cepat, dan jangan pernah rilis. Sampai saatnya rilis.”
  • Saya rasa matinya sebuah proyek itu sehat. Itu membebaskan waktu untuk memulai proyek lain, alih-alih terjebak dalam satu kerangka.
    Kadang kita berpegang pada proyek yang tidak menuju ke mana-mana, berpikir bahwa kalau kita berusaha cukup keras, proyek itu akan menuju suatu tempat, padahal sudah tidak menyenangkan dan tidak ada hal baru yang dipelajari. Kita memaksa diri dengan pikiran “harus diselesaikan, harus diselesaikan”, lalu ketika bertanya “kenapa?”, biasanya jawabannya karena takut tidak bisa menyelesaikan, atau mungkin takut tidak bisa membedakan antara fase sulit dan fase proyek yang gagal. Apa pun itu, sudah terlalu sering saya merasa lega ketika gagal. Itu menjadi kesempatan untuk memulai lagi.

• Beberapa pixel art di tangkapan layarnya benar-benar keren.

• Secara pribadi, saya belajar dan menghasilkan jauh lebih banyak dengan merilis sesuatu yang kecil lalu mengiterasi atau membuangnya.

• Saya suka pendekatan ini dan menganggapnya menarik, tetapi di tingkat organisasi tampaknya lebih rumit. Banyak hal yang kita temukan tentang proyek dan teknologi berkaitan dengan kelayakan pada skala ketika proyek nyata berjalan, dan itu tidak selalu terlihat dalam eksperimen kecil.
  Kadang masalahnya bukan soal teknologi, melainkan hal seperti “bisakah kita membuat sebagian besar developer di sini memahami cara kerja dengan pendekatan ini?” Bukan berarti kita sebaiknya tidak melakukan lebih banyak percobaan seperti ini. Ada hal-hal yang bisa dipelajari dengan mencoba proyek kecil. Hanya saja, itu tidak menjamin akan berhasil pada skala besar.

• Masalah saya cuma waktu. Setelah pulang kerja dan tiba di rumah, hal yang paling tidak ingin saya lakukan adalah duduk di depan komputer.
  Dua hari libur dalam seminggu pun harus diisi pekerjaan rumah, jadi saya tetap tidak ingin duduk di depan layar komputer.

  • Saya masih junior dan sedang mencari magang serta pekerjaan berikutnya.
    Saya iri pada orang yang bisa melakukannya seperti Anda. Industri saat ini terasa seperti kultus yang hanya mencari orang-orang yang menjadikan teknologi dan pemrograman sebagai seluruh hidupnya. Bukannya saya tidak suka dengan tuntutannya, saya juga punya etos kerja dan ingin menjadi bagus, tetapi ekspektasinya tampak lebih tinggi daripada sebelumnya.
    Saya berharap bisa punya stabilitas kerja yang cukup untuk memiliki hobi yang tidak mengharuskan saya menatap layar. Saya ingin segera mencoba pengerjaan logam.