6 poin oleh GN⁺ 2025-08-03 | 3 komentar | Bagikan ke WhatsApp
  • Selama lebih dari setahun, saya merasa terganggu karena tidak bisa menyelesaikan masalah race condition pada fitur pencarian Mintlify
  • Walaupun saya adalah pendiri Trieve, vendor penyedia mesin pencari Mintlify, saya tidak bisa mengakses kodenya secara langsung karena berstatus vendor, sehingga tidak dapat memperbaiki masalahnya sendiri
  • Akhirnya, setelah bergabung dengan Mintlify, saya langsung memperbaikinya dengan menggunakan AbortController untuk membatalkan kueri pencarian dan menyelesaikan sinkronisasi hasilnya
  • Dari situ saya menekankan bahwa, jika bersifat open source, masalah ini bisa langsung diperbaiki lewat PR, yang menyoroti keunggulan praktis open source
  • Saya pun merasakan lagi kepuasan memperbaiki langsung, sekalipun gangguan kecil, dan pentingnya peningkatan produk

Cerita Mengatasi karena Tidak Bisa Menyerahkan PR Lalu Memperbaiki secara Langsung

Bug Pencarian Mintlify yang Mengganggu Selama Lebih dari Satu Tahun

  • Pada fitur pencarian Mintlify, karena race condition, query diproses ganda dan hasil pencarian yang salah terus muncul saat pengguna sedang mengetik
  • Saya adalah pendiri Trieve, vendor (perusahaan eksternal) yang menyediakan mesin pencari untuk Mintlify, tetapi tidak memiliki akses ke codebase sehingga tidak bisa memperbaiki langsung
  • Masalah ini saya sampaikan berkali-kali di channel Slack berbagi, tetapi karena diprioritaskan rendah, masalahnya dibiarkan cukup lama
  • Setiap kali pengalaman pencarian Trieve di Mintlify tampak tidak baik, sebagai founder saya merasakan beban pada harga diri pribadi dan citra merek

Bergabung dengan tim untuk menyelesaikan langsung

  • Setelah bergabung dengan Mintlify, saya bisa mengakses codebase secara langsung
  • Saya mengimplementasikan AbortController dalam fungsi pencarian untuk menghentikan kueri pencarian sebelumnya secara langsung
  • Sekarang, tiap kali pengguna mengetik, hanya hasil pencarian terbaru yang diterapkan sehingga selalu muncul hasil yang akurat dan terbaru
  • Kepuasan karena akhirnya bisa memperbaiki masalah yang sudah lama mengganggu adalah sangat besar
  • Seperti George Hotz yang sempat bergabung di Twitter untuk memperbaiki pop-up login, saya memegang prinsip untuk menyelesaikan sendiri masalah dengan sikap hacker/entrepreneur
  • Pengalaman pemecahan masalah yang langsung dan nyata semacam ini mengarahkan karier ke arah yang lebih baik

Nilai praktis dari open source

  • Secara pribadi saya lebih menyukai pengembangan dan pemanfaatan perangkat lunak open source
  • Karena open source, ada struktur agar pengembang eksternal dapat langsung mengirim Pull Request (PR) untuk memperbaiki bug atau meningkatkan fitur
  • Seandainya fungsi pencarian Mintlify bersifat open source, masalah yang berlangsung selama setahun bisa diselesaikan langsung lewat PR
  • Pada model sumber tertutup, perbaikan hanya mungkin jika memiliki akses ke kode
  • Saya menghargai nilai 'pemberian akses langsung' di ekosistem open source, sambil memahami perbedaan model bisnis setiap perusahaan

Kepuasan dari perbaikan langsung

  • Penyebab fitur pencarian Mintlify jadi lebih mulus dan responsif sekarang adalah perbaikan ini
  • Dengan memperbaiki bug kecil yang selama ini mengganggu saya, saya merasa ada kepuasan karena berkontribusi pada kemajuan produk
  • Dari pengalaman ini, saya menyadari bahwa memperbaiki masalah kecil secara berulang membuat produk jadi lebih baik
  • Perubahan kecil yang diperbaiki langsung akhirnya terakumulasi dan menghasilkan peningkatan besar pada pengalaman pengguna
  • Ke depan, saya ingin terus membuat produk yang lebih baik melalui akumulasi peningkatan kecil

3 komentar

 
yangeok 2025-08-05

Wkwkwk, saya hormat.

 
kimjoin2 2025-08-04

Pengembang top.

 
GN⁺ 2025-08-03
Komentar Hacker News
  • Dulu akun Amazon saya pernah ditangguhkan karena dicurigai sebagai penipuan; akunnya sudah sangat lama, dan email serta nomor teleponnya sempat saya hapus setelah beberapa kebocoran basis data. Setelah diterima bekerja, saya menghubungi penanggung jawab tim anti-penipuan Amazon secara internal dan masalah pembukaan blokir akun langsung cepat selesai. Waktu menghubungi dukungan pelanggan, sama sekali tidak membantu.

    • Ini bagian yang paling menjengkelkan dari Amazon. Kalau mencari produk lewat Reddit atau ulasan lain, biasanya saya berakhir di tautan amazon.com. Lalu saya diminta beralih ke akun dolar AS, dan untuk memesan saya harus mengubah lagi ke akun Jerman/euro. Proses ini terlalu merepotkan. Akan lebih baik kalau tiap wilayah bisa dilihat dengan bebas saja, lalu profil baru perlu diubah saat benar-benar hendak memesan. Saya juga berharap ada opsi membeli dari penjual di wilayah setempat.

    • Menarik. Saya masih menyimpan ponsel rusak dari masa onboarding saat masuk Google, dan sampai sekarang tidak ada seorang pun secara internal yang peduli. Ada alat internal yang bisa dipakai untuk memperbaikinya sendiri, tapi ada juga pesan yang mengatakan bahwa memakai alat itu tanpa izin bisa membuat saya dipecat.

    • Saya juga pernah gagal membuka blokir akun Facebook selama 9 bulan, lalu kebetulan mulai mengerjakan urusan internal dan akun itu langsung terbuka.

    • Saya juga ingin mengalami momen epik seperti ini dalam hidup.

    • Semoga saya juga punya keberuntungan seperti ini. Saya kehilangan akun Amazon hanya karena satu digit paling depan pada nomor telepon internasional saya tercatat salah. Akibatnya saya tidak bisa memakai verifikasi SMS, dan ponsel yang berisi aplikasi OTP juga baru saja rusak saat itu.

  • Kalau Google Maps mau mempekerjakan saya agar satuan jarak hanya tampil dalam km, kontak saya ada di profil HN saya. Rasanya selama 20 tahun saya sudah 500 kali mengganti dari mil ke km. Tidak masuk akal perusahaan yang menganalisis pengguna tidak bisa menangani hal dasar seperti ini.

    • Angka 500 kali itu memang gila. Saya jadi membayangkan ini gagal di A/B test karena keterlibatan pengguna rendah. Rasanya seperti sudah menjalani 7 wawancara lalu mengirim 1 PR, eh jadinya begini.

    • Saya ingin mencari orang yang membuat seluruh peta membesar ke “mode ukuran nyata 1cm=1cm” dan menerapkannya untuk seluruh perjalanan, lalu menamparnya sekali. Mungkin orang yang sama juga yang membiarkan mobil keluar dari layar saat zoom manual, lalu saat menekan “recenter” malah memaksa zoom kembali seperti semula. Navigasi tahun 2005 saja sudah menyelesaikan semua ini.

    • Saat bepergian di Meksiko, meski saya sudah login, Google Flights tetap mengubah mata uang dari dolar ke peso setiap kali membuka tab baru. Benar-benar seperti tidak peduli.

    • Waktu saya bekerja di Google 10 tahun lalu, saya melaporkan masalah ini lewat formulir umpan balik internal dan tidak pernah mendapat jawaban. Setelah itu, setiap tahun saya melaporkan bug ini lewat umpan balik Google Maps. Beberapa tahun bahkan saya kirim dua kali. Sekarang ini benar-benar sudah jadi bug yang memalukan.

    • Saya juga tertarik mengerjakan gmaps. Saya berharap perjalanan yang memakan waktu lebih dari 1 jam juga akan menyimpan rute pulang di cache lebih dulu. Sering merepotkan karena saya harus mengingat jalan saat sinyal layanan hilang.

  • Lucu melihat lelucon lama benar-benar menjadi kenyataan. Ada juga permintaan untuk menambahkan margin kiri lagi, karena membaca teks tepat di tepi layar terasa agak canggung.

    • Saat mengikuti tautan yang disebut di tulisan itu, saya melihat contoh seseorang di Apple yang menambahkan fitur penghapusan otomatis pass yang sudah kedaluwarsa lalu langsung keluar dari perusahaan sesudahnya. Sejak itu saya merasa harus berterima kasih dalam hati setiap kali memakai fitur tersebut. Itu masalah yang benar-benar menyebalkan.

    • Bercanda bahwa mungkin lebih baik langsung mempekerjakan OP untuk memperbaikinya.

    • Saya pribadi tidak suka situs yang membuang-buang ruang layar.

    • Saya suka rata kiri. Menurut saya memang di situlah teks seharusnya berada.

  • Dijelaskan bahwa ia menambahkan AbortController ke debounced search function agar kueri sebelumnya dibatalkan setiap kali pengguna memasukkan input baru. Hal yang paling menjengkelkan adalah saat filter atau pencarian sudah diterapkan padahal pengguna belum selesai mengetik. Saya ingin sistem menunggu sampai input benar-benar selesai.

    • Pencarian log Grafana saat ini akan menagih berdasarkan jumlah query setiap kali filter log yang sedang aktif diubah, bahkan kalau hanya mengganti satu karakter. Gara-gara ini saya sampai harus mengubah kebiasaan penggunaan UX saya. Biayanya dihitung per jumlah karakter yang memicu query, bukan berdasarkan seluruh string yang ingin dicari.

    • Saat saya membuat fitur pencarian-langsung di blog saya, saya membiarkan semua saran pencarian sebelumnya selesai dulu baru mengirim permintaan baru. Menurut saya itu cara yang masuk akal untuk mencegah beban server sambil tetap menjaga responsivitas.

    • Saya sangat membenci ini terutama di situs pemesanan. Filternya ada di sidebar kiri, tapi kalau tidak semuanya terlihat di layar, setiap kali saya mengubah sesuatu, halaman menggulir ke atas, memuat ulang, dan filternya menjadi read-only. Jadi saya harus menunggu semuanya selesai dulu sebelum akhirnya bisa menambahkan filter berikutnya.

    • Menurut saya kompromi yang baik adalah menunggu beberapa ratus milidetik setelah pengguna berhenti mengetik sebelum mengirim query. Atau query tetap dikirim, tetapi hasilnya tidak ditampilkan sampai input berhenti.

    • Saya sangat benci perilaku seperti ini. Rasanya seperti editor kode fancy yang berbunyi bip setiap kali kita mengetik satu huruf. Kalau saat mengetik 'i' dan 'f' langsung muncul “pernyataan if-then belum ditutup!”, itu terlalu reaktif padahal jelas saya masih mengetik. Lebih baik peringatannya muncul setelah saya selesai menulis. Di kebanyakan bahasa atau alat, saya biasanya mematikan notifikasi real-time seperti ini dan hanya melihat error saat build/jalankan. LSP (Language Server Protocol) perlu sedikit menenangkan diri.

  • Sekarang kualitas perangkat lunak sudah sedemikian rendah sampai kalau ada bug yang mengganggu, rasanya lebih mudah diterima kerja lalu memperbaikinya sendiri. Ini mengingatkan pada kisah programmer yang memperbaiki masalah loading GTA 5. Bahkan GTA 5 yang uangnya sebanyak itu pun ternyata tidak mudah meningkatkan kualitas.

    • Menurut saya ini bukan masalah kualitas, melainkan masalah prioritas. Perusahaan memilih mengerjakan apa yang diinginkan tim lebih dulu daripada apa yang diinginkan pengguna. Pengujian pengguna nyata dan eksperimen data juga kurang. Sebenarnya contoh ini bukan solusi atas masalah, melainkan potongan dari masalah yang sesungguhnya. Mungkin ada isu lain yang jauh lebih berguna, tetapi yang terjadi justru satu orang menambahkan fitur yang ia sendiri inginkan.

    • Orang-orang yang menghabiskan banyak uang untuk kartu di GTA:O tidak peduli pada waktu loading. Saya sendiri sampai marah dan mengukur waktunya, lalu sadar saya menghabiskan lebih lama menatap layar loading daripada memainkan misi sungguhan, dan akhirnya berhenti main sepenuhnya.

  • Bercanda menanyakan apakah kamu orang yang ada di meme internet itu.

  • Saya penasaran karena bagian perekrutannya sama sekali tidak disebut di artikel. Kesan yang muncul hanya seperti, “ada sesuatu yang mengganggu saya, lalu saya memperbaikinya karena kebetulan masuk perusahaan,” jadi rasanya inti ceritanya hilang.

    • Sepertinya perusahaan penulis diakuisisi oleh tempat ia bekerja sekarang, jadi saya menduga ini kasus acquihire.
  • Sebaliknya, saya dulu pernah bekerja di tempat yang membuat pengajuan PR ke kode open source mustahil dilakukan karena para pengacara IP. Meski begitu, kalau saya menjelaskan input yang tepat dan nomor baris bug secara rinci, saya masih bisa membujuk seseorang untuk memperbaikinya langsung. Rasanya seperti saya memberi laporan QA gratis alih-alih kode.

  • Ini mengingatkan pada kisah legendaris George Hotz yang sempat bergabung ke Twitter pada 2022 dan menyelesaikan masalah penghapusan popup login. Tapi ingatan saya agak berbeda. George Hotz mengklaim bisa “memperbaiki pencarian”, lalu hampir langsung pergi, dan pada akhirnya hanya menghapus popup itu sebagai hiburan.

    • Kali ini saya sempat tenggelam lagi sebentar menelusuri George Hotz, patent troll, dan comma.ai. Comma.AI milik George Hotz menawarkan “comma 3x” seharga $999, berupa smartphone dan konektor OBD-II, serta wiring harness seharga $99, yang bisa menambahkan kemampuan setingkat Autopilot ke sebagian besar mobil buatan dalam 10 tahun terakhir, bahkan Tesla. Totalnya $1098, bersifat open source di GitHub, dan bahkan mendukung akses ssh ke kendaraan. Langganan cloud opsionalnya $10/bulan (SIM sendiri) atau $24/bulan (termasuk data seluler dari penjual). Hanya saja belum ada fitur setara Tesla Sentry Mode, dan itu masih tercatat sebagai issue #29912. Tesla Sentry Mode asli memakai 250W — dengan baterai 80kWh, dalam 7 hari bisa turun dari 80% ke 30% — jadi kalau openpilot hanya memakai di bawah 5W, menurut saya itu akan jauh lebih efisien.

    • Saya ingat George Hotz membanggakan diri seolah masuk Twitter, lalu tidak melakukan apa-apa dan pergi diam-diam. Memalukan, dan menurut saya itu ulahnya sendiri.

    • Ia bilang sudah memperbaiki tulisan itu agar lebih akurat, sambil pada saat yang sama malah menurunkan blognya sendiri karena bug Github Pages.

    • Setahu saya, pada akhirnya ia mengusulkan kepada Elon agar membangun ulang seluruh Twitter.

  • Saya pribadi bahkan sempat melamar kerja ke Discord agar bisa mengirim PR untuk menjadikan emoji besar sebagai pengaturan toggle. Bukan cuma saya, satu server penuh juga sangat menginginkannya.

    • Entah berguna atau tidak, tapi saya sendiri mengakalinya sementara dengan menambahkan titik setelah emoji. Bagi pengguna baru ini tidak membantu, tapi bagi saya ini cukup sebagai solusi sementara.

    • Discord adalah aplikasi Electron, jadi secara teori ini mungkin bisa diubah dengan mod sisi klien. Hanya saja saya tidak tahu seberapa besar risiko akun diblokir.

    • Ada juga komentar yang menanyakan maksudnya, misalnya dijelaskan bahwa memang ada opsi untuk mematikan konversi otomatis emotikon seperti :).