- Saat mengerjakan proyek teknis berskala besar, hasil yang terlihat dalam keseharian penting untuk menjaga motivasi dan menuntaskannya
- Proyek dipecah bukan ke unit yang besar dan samar, melainkan ke unit kecil yang terlihat jelas, lalu dipilih cara yang memungkinkan kemajuan nyata bisa dikonfirmasi di tiap tahap
- Pada tahap awal, membuat demo dengan cepat melalui feedback loop yang rapat sangat membantu keterlibatan dan motivasi diri
- Efektif untuk lebih dulu mengembangkan fitur yang dibutuhkan untuk diri sendiri, lalu terus menyempurnakannya lewat penggunaan nyata
- Lebih mengutamakan kemajuan daripada kesempurnaan, dan berulang kali mendapatkan pengalaman sukses dalam skala kecil akan membantu menuntaskan proyek jangka panjang
Dari Titik Awal
- Saat memulai proyek besar, rintangan terbesar adalah memutuskan harus mulai dari mana
- Jika semua komponen dipertimbangkan sekaligus, proyek akan terasa terlalu abstrak dan mudah membuat minat hilang
- Penting untuk mulai dari unit kecil yang bisa cepat menunjukkan hasil nyata
- Setiap subproyek harus bersifat independen dan memberikan tanda penyelesaian yang jelas
- Semakin banyak pengalaman, semakin mudah memahami bentuk umum dan subkomponen proyek
Menciptakan Hasil Awal
- Pada pekerjaan awal, bagian yang tampak dari luar sedikit, sehingga kemajuan bisa terasa tidak terlihat
- Dalam situasi seperti ini, penting memanfaatkan pengujian otomatis (misalnya unit test) secara tepat untuk mendapatkan hasil yang terlihat
- Misalnya saat membuat parser terminal, hasil parsing untuk string input bisa langsung diperiksa lewat test
- Pengalaman berulang saat test berhasil lolos itu sendiri memberi rasa pencapaian
- Melalui keberhasilan kecil seperti ini, kita bisa terus menumpuk bukti objektif atas kemajuan seluruh proyek
Membuat Demo dengan Cepat
- Tujuan awal bukan subkomponen yang sempurna, melainkan implementasi yang cukup untuk demo
- Kompleksitas yang dibutuhkan dalam jangka panjang (misalnya database, struktur data tingkat lanjut, dan sebagainya) ditunda dulu, dan implementasi sederhana diprioritaskan agar bisa maju cepat
- Selalu ingat bahwa 'kesempurnaan bisa menjadi musuh bagi kemajuan'
- Menargetkan pembuatan demo sederhana sekali atau dua kali seminggu
- Meski demonya belum sempurna, kita bisa langsung memeriksanya dan mendapatkan umpan balik intuitif, yang sangat membantu motivasi
Mengembangkan untuk Diri Sendiri
- Khususnya dalam proyek pribadi, penting untuk mulai dari fitur yang benar-benar dibutuhkan diri sendiri, lalu mengadopsi dan memakainya sendiri
- Dengan memakainya langsung, kekurangan bisa dirasakan, lalu perbaikan dilakukan dengan fokus pada fitur yang benar-benar dibutuhkan, sehingga proyek berkembang dari sudut pandang pengguna nyata
- Pada tahap awal penggunaan, ketidaknyamanan atau bug akan terlihat, tetapi justru itu memperjelas apa yang harus dikerjakan berikutnya
- Rasa bangga karena menggunakan software yang dibuat sendiri membantu proyek terus berlanjut
- Pada awalnya, semua fitur yang tidak perlu (scroll, pemilihan dengan mouse, tab, dan sebagainya) dihilangkan
Cara Mengemas Keseluruhan Proyek
- Masalah besar secara keseluruhan dipecah menjadi masalah kecil yang terlihat. Setiap masalah harus memungkinkan hasil nyata untuk diperiksa
- Setiap masalah kecil diselesaikan hanya sampai tingkat yang cukup untuk membuat demo, lalu beralih ke masalah berikutnya
- Membuat demo yang berfungsi secepat mungkin, lalu menambahkan fitur secara berulang setelahnya
- Memprioritaskan implementasi fitur yang bermakna untuk penggunaan sendiri
- Bila perlu, setiap komponen ditingkatkan berulang kali sambil mengulangi proses ini
Kesimpulan
- Dengan pendekatan di atas, proyek pribadi, kelompok, pekerjaan, maupun akademik bisa diselesaikan sambil tetap memotivasi diri sendiri
- Fokusnya bukan pada deployment atau tooling, melainkan pada cara yang benar-benar memungkinkan motivasi tetap terjaga secara berkelanjutan
- Metode yang sama tidak cocok untuk semua orang, tetapi hasil kemajuan yang terlihat adalah kekuatan terbesar untuk menuntaskan proyek jangka panjang
- Penting untuk memahami minat dan cara memotivasi diri sendiri, lalu membangun proses kerja yang sesuai
1 komentar
Komentar Hacker News
Saya setuju dengan semua poin yang disampaikan dalam tulisan itu, sambil ingin menambahkan satu hal: pentingnya loop umpan balik yang cepat
Kalau kita bisa melakukan perubahan dan langsung melihat hasilnya, itu benar-benar memotivasi
Saat kita mengutak-atik kode secara playful dan mengamati efeknya, banyak masalah yang hilang atau berubah menjadi bentuk yang mudah diselesaikan
Dalam proyek-proyek besar, ada korelasi yang jelas antara betapa mudahnya setup dan menjalankannya dengan jumlah masalah proyek yang muncul seperti bug, tenggat terlewat, dan sebagainya
Ceramah ini membahas loop umpan balik
Link YouTube
Saya sedang mempertimbangkan menerapkan tes e2e untuk bug yang ditemukan agar bisa memastikan bahwa bug tersebut benar-benar sudah diperbaiki
Saat ingin mencoba atau memperbaiki sesuatu, kalau setup-nya sendiri memakan waktu berjam-jam, motivasi langsung hilang dan akhirnya ditunda
Karena itu saya suka bahasa seperti lisp yang punya REPL yang benar-benar berguna
Ada kepuasan instan karena bisa langsung melihat hasilnya
Begitu kehilangan motivasi, proyek itu menguap begitu saja
Karena itu, membuat proses development itu sendiri menjadi pengalaman yang menyenangkan adalah salah satu faktor yang nyaris paling penting
Menurut saya ini salah satu area di mana pengalaman justru bisa menghambat
Saya sering melihat engineer senior menggali terlalu dalam demi membuat sesuatu yang sempurna, tetapi ketika akhirnya waktunya demo, hasilnya ternyata kurang bagus
Implementasinya mungkin rapi, tetapi fitur atau produknya sendiri ternyata benar-benar kurang menarik
Kadang saya ingin mematikan otak dan menulis kode jelek seadanya
Dulu saya sering membuat proyek iseng dan bahkan menaruh seluruh source code dalam satu file
Tanpa terlalu peduli soal modularisasi pun tetap terasa menyenangkan dan tetap berjalan
Tapi sekarang, menyelesaikan satu proyek iseng saja terasa sangat sulit
Karena sudah pernah melakukannya sekali, jadi cenderung ingin memasukkan semua fitur tambahan yang sebenarnya tidak perlu
Misalnya dengan mengikuti coding challenge seperti Advent of Code, di mana soal-soal awal sederhana dan baru belakangan perlu optimisasi atau algoritma yang lebih rumit
Atau dengan lingkungan yang terbatas seperti pico-8, sehingga tidak mungkin coding berjam-jam
Atau mencoba dalam lingkungan berbatas waktu seperti hackathon atau game jam juga bisa membantu
Karena orang-orang yang belum terlalu berpengalaman bisa melupakan semua 'best practice' yang sudah membosankan dari bahasa lama dan mencoba sesuatu dengan lebih bebas
Tabel DB saya rancang sendiri, lalu bagian implementasi saya serahkan agak bebas ke LLM
Saya terkesan dengan gagasan bahwa tujuan subproyek awal bukanlah membuat 'subkomponen yang selesai', melainkan membuat subkomponen yang 'cukup bagus' agar bisa lanjut ke tahap berikutnya
Untuk benar-benar mempraktikkan cara ini, saya jadi sadar bahwa kita memang harus 'mengabaikan' sesuatu
Orang lain bilang mereka mengabaikan modularisasi kode dalam mode seperti ini, tetapi bagi saya justru menjaga kode tetap rapi memberi rasa puas dan motivasi
Jadi saya berencana 'mengabaikan' bagian seperti algoritma, struktur data, dan performa
Pada akhirnya intinya adalah, memang pasti ada sesuatu yang harus dilewati, tetapi kalau hal itu justru memberi saya motivasi, maka saya tidak boleh mengabaikannya
Demo berperan sebagai tahap perantara antara mengembangkan software (programming) dan menjelaskannya lewat tulisan (dokumentasi)
Lewat demo, saya bisa terus menguji hipotesis tentang apa yang seharusnya dilakukan proyek saya sendiri, dan itu menjadi semacam mekanisme umpan balik
Demo bertahan lama, sehingga ketika sebuah fitur rusak saya bisa langsung mengetahuinya dan terus mengulang loop perbaikan
Secara pribadi saya bekerja dengan cara ini pada game engine yang sedang saya kembangkan
Contoh demo di GitHub
Saya berharap cara seperti ini menjadi akal sehat umum
Rasanya fokusnya lebih ke proyek pribadi
Saya justru ingin tahu cara yang baik untuk mengerjakan proyek tim teknis berskala besar, di mana semua orang bergerak menuju satu tujuan dan benar-benar menyelesaikan pekerjaan dengan baik
Selama hampir 15 tahun bekerja, saya belum pernah melihat proyek teknis yang bebas dari pembengkakan anggaran, keterlambatan jadwal, kekurangan fitur, dan burnout
Sebaliknya, kalau ada contoh proyek besar yang benar-benar berhasil dijalankan dengan baik, saya ingin orang-orang membagikan tautan bacaan tambahan atau rekomendasi terkait
Pembengkakan anggaran itu hal yang umum, selama uangnya tidak benar-benar habis
Dalam kebanyakan kasus, itu hanya berarti ada seseorang yang mengeluh karena estimasinya meleset
Keterlambatan jadwal juga sama; kalau memang tidak ada tenggat yang benar-benar wajib dipenuhi, itu bukan masalah serius
Sebenarnya, event yang terikat jadwal seperti kampanye promosi besar sebaiknya tidak direncanakan sampai proyeknya hampir selesai
Kekurangan fitur pada akhirnya juga soal ekspektasi
Masalah yang sesungguhnya adalah 'orang-orang benar-benar terkuras sampai burnout'
Setidaknya, itu hal yang benar-benar harus dihindari
Secara pribadi, saya makin menyukai Scaled Agile Framework
Saya memakainya sebagai framework, semacam 'orang-orangan sawah' yang bisa diubah sesuai situasi
Itu membantu saya menggali sumber asli yang lebih dalam dan sampai pada kesimpulan saya sendiri
Saya belajar bahwa keberhasilan sejati dimulai dari 'memahami dengan jelas mengapa kita membuat ini'
Kalau tujuannya tidak jelas, kita tidak bisa menentukan prioritas dan bahkan tidak tahu harus mulai dari mana
Kejelasan seperti ini jauh lebih membantu untuk menentukan 'apa yang dibuat dan kapan', dan kadang juga memungkinkan keputusan untuk 'tidak membuatnya sama sekali'
Hal penting berikutnya adalah 'empati'
Kita harus benar-benar memahami masalah pelanggan sepenuhnya dari sudut pandang mereka dan menawarkan solusi
Bukan sekadar menuruti semua yang diminta pelanggan, tetapi memahami pain point inti secara tepat dan memberikan sesuatu yang benar-benar bernilai
Alasan sebenarnya kebanyakan proyek gagal adalah karena tim menghabiskan terlalu banyak waktu membuat 'hal yang salah'
Kalau kita terus fokus pada fitur-fitur yang memang dibutuhkan, benar-benar diinginkan orang, atau cukup bernilai sampai layak dibayar, jauh lebih banyak proyek akan selesai dengan sukses
Ada sangat banyak orang yang melihat proyek besar lalu jatuh ke analysis paralysis
Yang benar-benar sulit adalah menyelesaikannya
Kalau membuat software yang akan kita pakai sendiri, kita bisa menyelesaikan masalah kita sendiri
Dengan memakainya sendiri, kita juga bisa menemukan bug pada software itu
Saya sendiri menemukan banyak bug saat membuat dan menggunakan web server saya sendiri
Budaya development yang fokus, iteratif, dan selalu mengarah pada hasil yang berfungsi