Kisah "Just Ship It" yang Paling Menyedihkan (2020)

• Proyek sampingan yang dimulai pada 2018 memiliki MVP yang siap dalam hitungan hari, tetapi karena terus menunda waktu rilis, proyek itu berubah menjadi proyek tak pernah dirilis selama 2 tahun
• Di pusat penundaan itu ada keputusan berulang “tinggal satu hal lagi”, dan cakupan produk pun membesar sampai harus mempelajari React Native dan Expo
• Aplikasi pesaing yang memecahkan masalah yang sama memang lambat dan punya bug, tetapi sudah dirilis, mendapatkan pengguna dan komunitas, serta terus membaik setiap minggu
• Setelah masa uji coba 30 hari berakhir dan akhirnya membayar aplikasi pesaing itu, aplikasinya sendiri yang hanya tersisa di hard drive menjadi produk yang pada dasarnya sudah mati
• Dalam pembaruan 2024, ia menyebut bahwa pada 2022 akhirnya meluncurkan aplikasi produktivitas Benji, dan kesimpulannya, meski terdengar klise, tetap condong pada merilis lebih dulu

---

Alasan MVP yang dibuat dalam beberapa hari tak kunjung dirilis selama 2 tahun

• Pengembangan aplikasi dimulai pada 1 Januari 2018, dan MVP sudah siap dalam beberapa hari
• Versi alpha 0.0.1 sebenarnya sudah cukup siap untuk dipublikasikan, tetapi setiap kali rilis ditunda dengan alasan “tinggal satu fitur lagi”, “tinggal satu layar lagi”
• Dengan anggapan bahwa “orang tidak akan memakainya jika tidak ada aplikasi mobile native yang layak”, ia memutuskan mempelajari React Native dan menghabiskan beberapa bulan lagi untuk itu
• Setelah itu, selama 2 tahun berikutnya, ia terus berulang kali berpindah antara platform web, React Native, Expo, GraphQL, kebingungan soal tech stack, beralih ke proyek lain, merilis aplikasi lain seperti Sizzy, kehilangan semangat lalu mendapatkannya kembali
• Pada akhirnya ia berhenti mengembangkan, dan juga melepaskan gagasan untuk merilis aplikasi tersebut

Momen ketika menemukan aplikasi yang memecahkan masalah yang sama

• Seiring waktu, saat terus memakai aplikasi itu sendiri, ia menyadari ada banyak fitur yang dibutuhkan, dan situasinya menjadi harus mengembangkan lagi atau mencari alternatif
• Begitu melihat landing page aplikasi alternatif itu, ia langsung dihantam perasaan kuat bahwa ada orang lain yang sudah memecahkan masalah yang tadinya ingin ia selesaikan
• Ia pernah mengirim video aplikasinya kepada beberapa orang sebelumnya, sehingga sampai curiga apakah video itu dibagikan, karena fitur dan cara pandang terhadap masalahnya terasa sangat mirip
• Namun, ia menerima bahwa keberadaan aplikasi pesaing itu bukanlah kesalahan mereka, melainkan karena dirinya terlalu lambat dan gagal merilis tepat waktu

Aplikasi pesaing yang lebih dulu dirilis daripada lebih dulu sempurna

• Saat membuat akun dan menonton video di pusat bantuan, setiap kali merasa cara implementasinya cerdas, ia sekaligus sadar bahwa dirinya sedang melihat pesaing
• Selama 2 tahun ia berpikir aplikasinya masih canggung, penuh bug, dan kurang fitur sehingga tak akan dipakai siapa pun, tetapi setelah mencoba aplikasi pesaing itu ia menyadari penilaian tersebut salah
• Aplikasi pesaing itu juga telah dikembangkan selama beberapa tahun, tetapi masih lambat, penuh bug, dan belum banyak dipoles
• Aplikasi mobile-nya bahkan buruk sampai sinkronisasi memakan waktu 10 detik, tetapi itu sudah menjadi produk yang dirilis, dan para pengguna bisa menunggu pembaruan berikutnya
• Meski daftar pekerjaan masih besar, mereka terus merilis setiap minggu sehingga aplikasi dan komunitas tumbuh bersama

Pelajaran yang tersisa setelah melakukan pembayaran

• Setelah masa uji coba 30 hari berakhir, ia memasukkan informasi kartu kredit, dan berubah dari sekadar pelanggan menjadi penggemar
• Notifikasi pembayaran itu menjadi pengalaman yang terus mengingatkannya bahwa ia gagal merilis produknya sendiri
• Pada momen itu ia menerima bahwa aplikasinya resmi mati
• Kebanyakan orang yang berada dalam situasi serupa mungkin bahkan baru memulai proyek mereka beberapa minggu lalu, jadi mereka harus menghindari kesalahan yang sama
• Jika “tinggal satu hal lagi” berarti membangun ulang autentikasi, pembayaran, dan boilerplate, itulah jebakannya; lalu untuk mengurangi jebakan itu, ia membuat Zero To Shipped

Pembaruan 2024: akhirnya merilis Benji

• Menurut pembaruan 2024, pada 2022 ia akhirnya meluncurkan Benji
• Alasan merilisnya adalah karena tidak ada aplikasi pesaing yang cukup dekat dengan visinya
• Aplikasi yang ia inginkan adalah gabungan Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing, Trips, dan lainnya
• Benji juga memiliki timeline publik tempat orang-orang memperbaiki hidup mereka sambil membagikan keberhasilan dan pencapaian
• Meski terdengar klise, tarik napas dulu, lalu tetap Just Ship It

[GN⁺]

Opini Hacker News

• Dalam cerita seperti “berakhir karena waktu itu tidak langsung dirilis”, ada petunjuk besar: terkadang nilai aplikasi yang sedang dibuat justru ada pada detail teknis yang tidak bisa diburu-buru, dan dalam kasus seperti itu “rilis saja” bukan jawabannya
  Pekerjaan software engineer/architect juga termasuk menahan sebisa mungkin tekanan manajemen yang berkata “keluarkan saja”. Kalau itu bukan produk yang dimiliki sendiri dan rilisnya bukan situasi yang menguntungkan diri sendiri, bila waktu tambahan menghasilkan hasil yang lebih profesional, maka waktu itu harus dipakai. Kita bukan mesin otomatis yang menerima tiket JIRA lalu secepat mungkin memuntahkan kode asal-asalan; kalau terus bekerja seperti itu, mental akan terkuras dan akhirnya burnout
  Jika tidak punya saham perusahaan, tugasmu bukan memaksimalkan keuntungan perusahaan, melainkan membuat software yang bagus yang tidak memalukan untuk ditaruh di CV. Rasa lega karena sekali lagi memenuhi deadline arbitrer hanyalah motivasi negatif jangka pendek dan tidak akan bertahan lama, jadi tahan tekanan dari atas dan bangunlah dengan benar. Kalaupun dipecat, sekarang pindah kerja toh memang sering menjadi jalan naik

  • Pandangan “kalau tidak punya saham perusahaan, tidak perlu peduli profitabilitas” terlihat seperti sikap buruk yang menunjukkan kurangnya senioritas seorang software developer. Jika bukan organisasi nirlaba, semua anggota perusahaan harus berkontribusi pada profitabilitas
    Namun profitabilitas bukan berarti sama dengan “rilis saja”. Jika sebuah perusahaan sering mencampuradukkan keduanya, itu tanda kurangnya senioritas di pihak manajemen
    Pekerjaan developer lebih dekat ke membuat produk yang bagus, bukan “software yang bagus”. Produk yang bagus biasanya membutuhkan software yang bagus, tetapi tidak selalu begitu, dan sering juga ada software buruk di balik produk yang hebat. Ketegangan antara produk, penjualan, dan pengembangan seharusnya mengarah pada kompromi yang memaksimalkan nilai jangka pendek, menengah, dan panjang; developer harus memahami apa yang boleh dikerjakan sekadarnya, prioritas apa yang dimiliki perusahaan, dan kapan tidak boleh berkompromi serta harus membuat software yang baik
    Developer yang tidak pernah bisa berkompromi dalam kualitas software justru kehilangan daya tawar pada momen ketika kompromi memang benar-benar tidak boleh dilakukan
  • Pertama-tama harus dilihat dulu kenapa kita mengembangkan sesuatu. Bisa untuk hobi, kesenangan, atau keindahan kode, tetapi kebanyakan alasannya adalah agar software menjalankan pekerjaan yang dibutuhkan seseorang
    Jadi prioritas pertama adalah menciptakan nilai bagi pengguna dan mengembangkannya seefisien mungkin. Apa artinya software yang tidak dipakai siapa pun?
    Pekerjaan developer bukan membuat software yang bagus, melainkan menyampaikan nilai kepada pengguna. Dalam karier saya, yang justru lebih sering saya lihat adalah developer mabuk over-engineering, menggembungkan kode dengan fitur yang tidak dibutuhkan siapa pun, dan menambah kode demi mengantisipasi pengembangan masa depan yang belum tentu datang. Karena itu tantangan sulitnya adalah tetap minimalis, dan sepertinya itulah yang dibicarakan tulisan aslinya
  • Seluruh komentar ini terbaca seperti orang yang melihat hubungan dengan rekan kerja sepenuhnya secara antagonistik dan hampir tidak punya kepercayaan. Sepertinya cukup melelahkan
  • Saya dulu salah satu karyawan awal di sebuah startup, dan kalau kami tidak berkompromi, besar kemungkinan perusahaan itu tidak akan ada sekarang. Pendekatan seperti itu hanya cocok di perusahaan besar yang sudah mapan, di mana pengaruh tim terhadap hasil relatif terbatas
    Di perusahaan kecil-menengah, kompromi jelas diperlukan, dan memilih opsi yang mengarah pada hasil bisnis terbaik juga bagian dari pekerjaan profesional
    Banyak developer “dilindungi” oleh beberapa lapis manajer, PM, dan desainer, sehingga keterhubungan mereka dengan sisi bisnis lemah. Jika produk dirilis cepat, feedback juga datang cepat, dan ada kesempatan untuk menilai apakah implementasi sesuai dengan asumsi. Itu lebih tidak membuat stres dibanding men-deploy solusi yang “sempurna” di bawah tekanan lalu harus menulis ulang
    Di tempat kerja saya sekarang, pekerjaan saya sebagai developer adalah mengurangi kompleksitas dan membuat PM serta desainer memangkas rencana awal seminimal mungkin. Dengan begitu deadline arbitrer pun tidak terlalu membuat stres, dan dampak keterlambatan juga lebih kecil
  • Sepertinya satire. Ada rangkaian kalimat mengesankan seperti “kalau itu bukan urusanmu, lakukan hal yang salah; kalau itu urusanmu, rilis cepat”, dan “pekerjaanmu adalah menaruh sesuatu di CV lalu merasa senang”
    Bagian yang bernilai hanya sebatas jangan terlalu terikat pada tempat kerja tertentu dan jangan terlalu khawatir dipecat, tetapi menurut saya penjelasan alasannya pun keliru. Mengejutkan bahwa kita mungkin benar-benar bekerja bersama orang-orang dengan sikap antagonistik seperti ini
    Sepertinya sebagian orang suka menjalani hidup di kuadran yang salah dalam teori permainan

• Saat membaca bagian “Saya curiga siapa yang membagikan video aplikasi saya kepada orang-orang ini. Karena secara harfiah mereka sedang memecahkan masalah yang sama”, saya teringat pernah bertemu seseorang yang punya ide aplikasi yang cukup bagus
  Dia meminta saya mengodekan aplikasinya secara gratis dan mengusulkan bagi hasil. Ketika saya bertanya kontribusi dia apa, dia menjawab akan “mengoperasikan” perusahaan, dan porsi 50% miliknya karena “dia yang punya ide”. Jadi saya bilang akan memberinya masa keunggulan 6 bulan, dan kalau sampai saat itu dia belum bisa membawanya ke pasar, saya akan membuatnya sendiri

  • Saya pernah ikut proyek game indie. Idenya biasa saja, hampir mendekati game buruk, tetapi kami bertiga sama-sama ingin pengalaman pengembangan software di bidang itu
    Dua dari tiga orang langsung duduk dan mulai membentuk sesuatu, tetapi orang ketiga mengunggah kode rusak ke SVN, membuat dokumen desain yang menulis seluruh ide sebagai jasanya sendiri, lalu mengadakan rapat dan menyatakan bahwa dialah game designer-nya serta akan menuntut kami kalau kami membuat game di tempat lain. Dua orang yang benar-benar berkontribusi saling berpandangan dan menutup proyek itu. Dia sudah membuka semua kartunya, dan kami tahu dia bukan siapa-siapa
    Belakangan saya melihat game dengan ide serupa di Steam. Kalau mereka memikirkannya secara independen, bagus; kalau mereka mencurinya dari pecundang itu, juga bagus; kalau mereka bertahan sampai akhir di bawah orang itu, mereka pantas mendapatkan uangnya
  • Sebagai orang yang sangat condong ke logika dan pemrograman, saya justru ingin bertemu orang seperti itu. Sepertinya saya sendiri bukan tipe manusia ide
    Kalau idenya benar-benar bagus dan dapat dipercaya, sejujurnya itu mungkin tawaran yang cukup lumayan
  • Menangani penjualan, pemasaran, akuntansi, dan semua hal lain yang diperlukan untuk menjalankan perusahaan bernilai 50%, mungkin bahkan lebih. Namun kemungkinan orang yang akan mengodekannya cukup kompeten memang tinggi, sementara peluang dia cukup kompeten untuk “mengoperasikan” perusahaan tampaknya rendah
  • Kalau sama sekali tidak tahu kondisi mental pihak lain, saya tidak yakin bijak mengatakan hal seperti itu
    Jika merasa boleh mengatakan kepada seseorang “6 bulan lagi saya akan mencuri ide hebatmu”, sebaiknya berharap orang itu bukan tipe yang akan menimbulkan masalah atau, secara ekstrem, mencelakai orang lain

• Saya ingin ada orang lain yang menyelesaikan masalah saya. Alasan saya masih berkutat dengan masalah itu sekarang hanyalah karena tidak ada solusi yang bisa langsung dibeli dan dipakai
  Kalau ada orang yang bersusah payah menyelesaikan masalah saya, lalu juga menanggung on-call dan pemeliharaannya, itu hal yang menggembirakan
  Mengapa harus Anda sendiri yang menyelesaikan masalah ini? Mengapa solusi Anda harus menjadi bisnis? Bisnis adalah pekerjaan menciptakan nilai bagi diri sendiri dan pelanggan. Kalau yang Anda obsesikan adalah masalahnya sendiri, Anda bisa berterima kasih bila orang lain mengerahkan banyak usaha untuk menyelesaikannya; kalau yang Anda obsesikan adalah pelanggan, semestinya Anda sudah sejak lama menyerahkan sesuatu kepada pelanggan untuk mendapatkan umpan balik

  • Sepertinya sebagian developer solo ingin mengimplementasikan ide baru, menumbuhkannya menjadi bisnis yang cukup sukses, menguasai pasar dengan kuat, lalu menjualnya ke perusahaan yang lebih besar untuk menghasilkan banyak uang
    Mungkin tidak banyak orang yang ingin menjalankan perusahaan dalam jangka panjang, tetapi kebanyakan orang tentu tidak keberatan tiba-tiba menerima uang besar karena telah memecahkan atau menangani masalah yang menarik
  • Saya penulis aslinya: alasan ini penting bagi saya adalah karena aplikasi yang saya pakai selama beberapa waktu mandek dan tidak lagi mendapatkan pembaruan. Ketika saya belajar lebih banyak tentang produktivitas, saya mentok pada keterbatasan aplikasi itu dan menginginkan lebih banyak fitur
    Ide untuk dimasukkan ke aplikasi saya terus bermunculan, tetapi developer lain mungkin tidak tertarik mengimplementasikan ide-ide semacam itu. Saya menginginkan kendali, dan karena itulah akhirnya saya meluncurkan Benji: https://benji.so

• Saya penulis aslinya. Tulisan ini perlu saya perbarui. Beberapa tahun kemudian, setiap kali tulisan ini muncul, komentar-komentar HN yang masuk benar-benar memotivasi saya
  Orang-orang selalu bertanya “mengapa tidak meluncurkan aplikasinya saja”, jadi akhirnya saya meluncurkannya
  Saya senang bisa menuntaskannya, dan menurut saya ini jauh lebih baik daripada produk pesaing mana pun di kategori ini
  Bisa dilihat di https://benji.so. Landing page-nya masih dalam pengerjaan

  • Landing page-nya membuat browser tersendat. Itu cuma layar awal dengan beberapa gambar, jadi saya tidak tahu bagaimana ini bisa terjadi. Sebenarnya apa yang dilakukan halaman itu
  • Saya pernah mengalami siklus pengembangan aplikasi yang serupa, yang juga gagal diluncurkan. Saya mulai dengan React, lalu pindah ke React Native, Flutter, dan akhirnya juga beralih dari GraphQL ke SQLite
    Aplikasi saya juga punya tujuan serupa: menghubungkan motivasi kebiasaan, pengukuran kepatuhan terhadap target, serta penjadwalan dan penjadwalan ulang tugas. Saya mengerjakannya selama beberapa tahun, dan gagasan bahwa suatu hari itu akan menjadi perusahaan bootstrap sangat melekat pada identitas saya
    Keputusan untuk melepaskan proyek itu datang dalam beberapa tahap, tetapi salah satu pemicu penutup yang besar adalah menyadari bahwa dalam jangka panjang saya tidak ingin hidup sebagai developer aplikasi. Sulit untuk melepaskannya, tetapi sekarang saya puas dengan keputusan itu. Seperti pada tulisan asli, bisa saja nanti ia hidup kembali, jadi bisa dibilang “tidak ada yang benar-benar hilang”, tetapi saya rasa saya tidak akan kembali ke proyek khusus ini
    Salah satu ide inti untuk mengatasi “beban kognitif tinggi” yang dimiliki kebanyakan aplikasi produktivitas adalah marketplace modul kehidupan. Misalnya, seorang influencer kebugaran menjual paket berisi rutinitas olahraga, pola makan, dan template jurnal, lalu pengguna “menginstalnya” ke dalam hidup mereka
    Model bahasa besar akan membuat hal-hal seperti mendeteksi churn dan memperkirakan penyebabnya, atau merespons “tindakan yang tidak dilakukan”, jauh lebih memungkinkan. Menurut saya ini penting bagi orang yang bukan tipe A yang memakai aplikasi produktivitas secara konsisten setiap hari
  • Saya baru saja mencobanya, dan nama zona waktu yang terdeteksi muncul sebagai “Africa/Ceuta (Romance Standard Time) (UTC+01:00) Brussels, Copenhagen, Madrid, Paris”
    Selisihnya dengan GMT memang benar, tetapi Brussels, Copenhagen, Madrid, Paris bukan Afrika, jadi ini sangat membingungkan. Sebaiknya periksa informasi zona waktu yang digunakan
    Melihat komentar di bawah, ternyata ini bukan masalah
  • Tautan menu berwarna putih di atas latar putih tidak terlihat. Saya tinggalkan ini karena sepertinya bagus untuk diketahui: https://i.imgur.com/Yd1hniV.png
  • Kelihatannya bagus. Mungkin saya akan mencobanya. Namanya diambil dari teman ini https://en.wikipedia.org/wiki/Benji? Saya sangat menyukainya sekitar usia 6–8 tahun
    Dan maaf karena sebelumnya mengekspresikan rasa frustrasi dan kecurigaan karena tidak menyebutkan nama “pesaing” itu. Sekarang setelah aplikasi Anda sendiri diluncurkan, saya rasa kemungkinan Anda menyebutkan nama produk pesaing itu malah makin kecil, meskipun produk itu masih ada

• Menjadi pengguna nyata dari sistem Anda sendiri akan mengubah perspektif sepenuhnya. Saya juga pernah membuat sesuatu untuk diri sendiri, dan merasa itu belum siap serta sama sekali belum bisa dipakai
  Setelah menyerah pada proyek itu, saya memutuskan mencobanya seperti pengguna nyata, dan saya sadar bahwa pengguna terbiasa dengan banyak masalah kecil dan secara otomatis menemukan cara memutar. Orang yang membuat sesuatu sering lupa bahwa banyak kekurangan bukanlah alasan diskualifikasi, dan bahwa pengguna menghindari berbagai kekurangan tanpa usaha besar. Pada titik itu, mengejar kesempurnaan lebih dekat ke soal ego
  Mengabaikan sejenak fakta bahwa Anda adalah pembuatnya, lalu benar-benar memakainya selama beberapa waktu sambil melarang diri sendiri memperbaikinya, bisa mengubah segalanya

  • Karena itu, menurut saya “luncurkan lalu iterasi cepat” sering menjadi jalan terbaik. Proyek software apa pun bisa punya bug fatal. Kalau paket akuntansi tidak bisa melakukan akuntansi dengan benar, tentu jangan diluncurkan begitu saja, tetapi kalau satu laporan karena suatu alasan muncul dua kali, pengguna bisa menanggungnya sampai iterasi berikutnya. Asalkan iterasi berikutnya itu bukan beberapa bulan hingga beberapa tahun kemudian
    Secara realistis, sampai Anda membukanya untuk pengguna nyata, Anda tidak akan menemukan sebagian besar “bug” yang akan dihadapi pengguna. Kalau tidak meluncurkan, Anda juga tidak punya kesempatan memperbaiki bug yang benar-benar berdampak pada pengguna
  • Aplikasi yang baru saja saya pakai punya browser web iOS bawaan yang tidak bekerja dengan benar
    Saya tinggal membuka halaman webnya langsung, dan tentu saja nama pengguna serta kata sandinya sudah tersinkron lewat iCloud. Melanjutkan lagi alur pengguna di Safari hanya butuh 5 detik, dan menyelesaikannya hanya butuh 30 detik

• Sebagai contoh “just ship it”, ini bukan yang terbaik. Untuk kategori seperti aplikasi produktivitas, to-do, pelacak kebiasaan, pelacak pengeluaran, journaling, dan rencana olahraga, banyak orang secara independen memikirkan ide yang sama
  Kalian tidak tahu betapa pintarnya saya merasa ketika terpikir ide aplikasi yang memungkinkan pencatatan pengeluaran. Lalu saya mengecek Play Store. KRAZAM juga pernah meledek hal ini dalam video “The Hustle” 5 tahun lalu

  • Ini mungkin kategori yang paling berlebihan dibuat sepanjang sejarah kategori aplikasi yang sudah terlalu banyak dibuat
    Bukan berarti variasi baru tidak bisa berhasil. Sebagian besar yang sukses pun tidak sepenuhnya orisinal. Hanya saja, kalau khawatir seseorang akan lebih dulu merilis versinya sendiri dan menang, cukup lihat sekeliling
  • Bagian “mengecek Play Store” sepertinya melewatkan inti tulisannya. Intinya adalah tetap rilis meskipun ada pesaing. Justru pesaing adalah sinyal bagus yang memvalidasi ide, bukan sinyal buruk

• Secara pribadi, saya tidak tahan dengan gaya penulisan yang “berusaha keras untuk lucu”

  • Setuju. Cukup melelahkan dibaca. Satu-dua sindiran dengan timing tepat tidak apa-apa, tetapi kalau berlebihan jangan
  • Bukan hanya Anda, dan tidak apa-apa kalau tiap orang punya selera berbeda

• Saya menyerah saat membaca. Terlalu kekanak-kanakan dan cringe
  Pada akhirnya mereka hanya membuat proof of concept lalu puas berhenti di situ. Sayang, tapi begitulah hidup. Mereka bekerja dan mendapatkan imbalan
  Pelajarannya adalah ide tidak bisa dimiliki

• Saya sepenuhnya setuju dengan ini. Saat memulai Kviklet, kami bertiga, dan salah satunya jauh lebih perfeksionis daripada dua lainnya. Jujur, bahkan untuk mengunggah versi pertama situs web yang buruk pun perlu banyak meyakinkan, dan membuka repositori ke publik bahkan lebih sulit
  “Co-founder” itu pergi di awal, tetapi saya benar-benar bersyukur kami mencoba merilis lebih cepat dan menjualnya
  Hasilnya tidak bagus dan kami tidak menemukan pembeli, tetapi mengerikan membayangkan kami masih membuat produk dalam gelap sambil hanya berpegang pada harapan, tanpa tahu sama sekali apakah ada yang mau membayar
  Sekarang kami menjadikannya open source sebagai rencana cadangan, dan sudah ada beberapa pengguna yang cukup keren. Mungkin bisa dibilang komunitas kecil: https://github.com/kviklet/kviklet
  Ini bukan kisah sukses startup yang saya harapkan setahun lalu, tetapi jauh lebih baik daripada masih terus berharap tanpa rasa realitas. Lagi pula, open source bukan berarti tidak bisa menghasilkan sedikit uang dengan menjual dukungan atau versi premium, bukan? Sekarang ini hanya side project yang menyenangkan

  • Deskripsi “alur review/approval seperti Pull Request untuk kueri database” kurang bagus. Jangan sampai terasa bahwa kueri perlu persetujuan
    Harus memakai kata seperti mutation, edit, update, modification. Meski query secara teknis benar, nuansanya terasa salah dan membingungkan

• Kalau saya membuat sesuatu untuk diri sendiri, saya tidak akan sedih jika ada orang lain yang membuatnya lebih dulu. Itu hanya bukti bahwa idenya bagus
  Tentu saja, banyak proyek pribadi yang ada di kepala dan di atas kertas, bahkan yang benar-benar sudah sedikit dimulai, memang bukan untuk dirilis sebagai produk jualan. Itu adalah hal-hal yang saya inginkan, atau yang mungkin berguna bagi teman, keluarga, atau orang lain
  Jika setidaknya sudah mencapai kualitas alfa, mungkin saya ingin mempublikasikannya agar seseorang berpikir, “idenya berguna, tapi implementasinya kurang, saya harus membuat yang lebih baik”

  • Secara realistis, dalam hampir semua situasi Anda sudah keduluan oleh sesuatu. Bahkan ketika untuk pertama kalinya dalam sejarah Anda mengotomatiskan sesuatu, cara manual yang sudah ada adalah pesaing awal. Aplikasi dalam tulisan itu juga bersaing bukan hanya dengan aplikasi lain, tetapi dengan berbagai kombinasi solusi parsial yang sudah dipakai target pelanggan
    Selain itu, sekalipun menjadi first mover, pesaing akan segera muncul dan menggerogoti keunggulan, sehingga perlu usaha untuk terus tetap di depan
    Jadi karena bagaimanapun selalu sudah ada yang lebih dulu, dan persaingan pasti ada sekarang atau nanti, jangan khawatir soal keduluan; fokus saja pada keunggulan kompetitif. Penulis aslinya tampaknya pada akhirnya juga sampai pada kesadaran itu, dan saya berharap semuanya berjalan baik