Alat yang baik itu tidak terlihat
(gingerbill.org)- Alat yang baik adalah alat yang menghilang ke latar belakang saat pengguna tenggelam dalam pekerjaannya, dan tujuan pembuat alat juga adalah membuat pengguna tidak menyadari keberadaan alat itu sendiri
- Jika kekurangan alat dibungkus sebagai teka-teki yang menyenangkan, orang mudah mengira rasa terlihat cerdas sebagai produktivitas yang nyata
- Memilih editor seperti vim, emacs, atau Sublime bisa cocok dengan alur kerja pribadi, tetapi jika bahkan kekurangannya dibela sebagai semacam sinyal identitas, akan sulit melihat kelebihan dan kekurangannya secara jujur
- Dalam perdebatan TUI dan GUI juga, kekurangan implementasi saat ini tidak boleh dianggap sebagai keterbatasan hakiki dari kategorinya; banyak masalah muncul karena belum ada implementasi yang baik
- Default yang baik adalah desain yang menghemat waktu pengguna, dan tingkat kustomisasi yang tinggi atau kurva belajar yang curam hanya layak ditanggung jika benar-benar dibayar dengan produktivitas nyata
Standar alat yang baik
- Alat yang baik harus tidak terlihat
- Alat menghilang ke latar belakang ketika pengguna bisa terus bekerja tanpa menyadari alat itu sendiri
- Saat alat menghambat pekerjaan tertentu, pengguna kembali menyadari alat tersebut
- Sikap membungkus kekurangan sebagai “teka-teki yang menyenangkan” mengaburkan penilaian terhadap alat
- Kesenangan menemukan jalan memutar tidak membuktikan kualitas alat
- Menikmati kekurangan seperti hobi dan alat yang benar-benar baik adalah dua hal yang berbeda
Perdebatan editor teks
- vim hanyalah contoh, dan logika yang sama juga berlaku untuk editor lain seperti emacs atau Sublime
- Sebagian pengguna memuji proses mengatasi kekurangan vim sebagai teka-teki yang menyenangkan alih-alih keunggulannya
- Ada contoh orang yang merasa menyenangkan membuat makro untuk refaktorisasi teks sekali pakai
- Jika pekerjaan yang sama bisa diselesaikan dalam satu menit dengan multi-cursor di Sublime atau dengan skrip sederhana, maka pekerjaan membuat makro itu lemah dari sudut pandang produktivitas nyata
- Editor penting bagi alur kerja, tetapi sikap mengikuti editor tertentu hampir secara religius karena “nuansa hacker” itu berbahaya
- Nuansa seperti ini bisa terasa menarik bagi orang yang baru mengenal vim atau emacs
- Kebiasaan bisa menutupi kekurangan, lalu membuat orang membanggakannya seperti permainan
Alasan memakai Sublime dan keterbatasan yang diakui
- Sublime adalah editor yang sudah dipakai selama 15 tahun, dan alasan memilihnya bisa diringkas sebagai berikut
- Pintasan keyboard-nya mendekati superset dari lingkungan OS grafis, sehingga biaya perpindahan kognitif saat berpindah antaraplikasi kecil
- Multi-cursor dianggap lebih baik daripada makro dalam 99.999% kasus
- Multi-cursor memberi umpan balik visual yang langsung
- Dalam alur kerja penyuntingan teks, ia menyisakan paling sedikit “teka-teki” yang harus dipecahkan
- Sublime juga tetap punya kekurangan
- Ada saatnya alat yang dibutuhkan tidak ada, sehingga harus memakai plugin atau program terpisah untuk menangani transformasi teks
- Kekurangan seperti ini tidak dibungkus sebagai “teka-teki yang menyenangkan”, tetapi diterima begitu saja sebagai ketidaknyamanan
- vim mungkin lebih baik untuk penyuntingan dasar, tetapi dianggap lebih lemah dalam pekerjaan massal yang bukan jenis pekerjaan grep
- Tidak terasa bahwa vim motion jauh lebih produktif daripada alur kerja Sublime
- Karena hampir tidak pernah menulis kode di terminal, editor yang berorientasi terminal pada dasarnya tidak diperlukan
Ketika alat menjadi identitas
- Pilihan alat bisa berfungsi seperti bendera yang menunjukkan orang seperti apa diri kita
- “Nuansa hacker” kadang menjadi sinyal kesukuan, bukan sekadar estetika
- Saat identitas terikat pada alat, mengakui kekurangannya terasa seperti menyangkal diri sendiri
- Karena itu orang bukan hanya menoleransi kekurangan, tetapi juga membelanya dan membanggakannya
- Sulit berdiskusi jujur tentang alat dengan orang yang menjadikan alat sebagai bagian dari kepribadiannya
Rasa produktif dan produktivitas nyata
- Contoh makro editor menunjukkan perbedaan antara rasa produktif dan produktivitas yang sebenarnya
- Rasa cerdas yang muncul saat memecahkan masalah rumit mudah tertukar dengan hasil nyata
- Alat yang membuat pekerjaan sulit terasa heroik dan membuat kecerdikan terasa seperti pencapaian bisa tampak kuat
- Pada saat yang sama, kecepatan kerja yang sebenarnya bisa diam-diam lambat
- Standar yang jujur bukanlah rasa tenggelam atau rasa cerdas, melainkan waktu yang dihabiskan dan jumlah kesalahan
- Banyak alat yang direkomendasikan hampir seperti dakwah bisa kalah pada standar ini
- Jika produktivitas adalah tujuan, kita perlu benar-benar meragukan keyakinan sendiri dan memeriksa apa yang lebih produktif
Perdebatan TUI dan GUI
- Bagi pengguna yang memang berada di terminal sepanjang hari, keunggulan aplikasi terminal jelas
- Tetapi kebanyakan programmer tidak terkurung di terminal sepanjang hari
- Kritik bahwa aplikasi GUI tidak bisa dinavigasi hanya dengan keyboard tidak berarti GUI itu buruk secara hakiki
- Banyak GUI hanya tidak cukup mendukung navigasi keyboard
- Tidak ada hal yang secara hakiki mustahil untuk membuat GUI bisa dinavigasi dengan keyboard
- Banyak pembuat alat tidak menerapkannya, atau tidak menyadari bahwa navigasi keyboard sering kali lebih produktif daripada sering memakai mouse
- Perbandingan bahwa aplikasi TUI tertentu lebih baik daripada alternatif GUI tertentu bisa saja valid
- Namun, menilai bahwa TUI secara hakiki lebih baik daripada GUI mendekati kekeliruan yang mengira keterbatasan implementasi saat ini sebagai keterbatasan esensial
Desktop Linux dan kesenangan mengutak-atik konfigurasi
- Bahkan pada 2026, “tahun desktop Linux” belum juga datang
- Salah satu alasannya adalah banyak pengguna Linux menyukai mengubah sistem lewat file konfigurasi sebagai teka-teki yang menyenangkan
- Meski pernah melalui tahap seperti itu, seiring waktu orang hanya ingin alat yang bekerja dengan baik
- Menghabiskan berjam-jam atau berhari-hari untuk konfigurasi bukan lagi hal yang diinginkan
- Default harus bagus dan langsung bekerja
- Jika perlu penyesuaian kecil, itu harus selesai dalam hitungan detik
- Kustomisasi maksimum seharusnya bukan tujuan alat, melainkan opsi yang dipakai saat benar-benar perlu
- Desain alat yang ergonomis adalah menyediakan default yang baik sekaligus jalan keluar saat diperlukan
Default yang baik dan tanggung jawab pembuat alat
- Default yang baik adalah tanggung jawab pembuat alat
- Pembuat alat mudah melempar beban konfigurasi, penyesuaian, dan pembelajaran kepada pengguna
- Banyak beban semacam itu adalah hasil desainer yang menghindari pengambilan keputusan
- “Tingkat kustomisasi yang tinggi” bisa menjadi alasan untuk melempar masalah ke pengguna tanpa benar-benar punya pendapat desain
- Default yang baik adalah bentuk penghormatan terhadap waktu pengguna
- Jika pembuat alat memikirkannya sekali, banyak pengguna tidak perlu mengulang pemikiran yang sama
- Jalan keluar adalah mekanisme untuk minoritas kecil yang benar-benar punya kebutuhan tidak umum
- Itu tidak boleh menggantikan pekerjaan membuat kasus umum berjalan dengan baik
Kurva belajar yang curam bukanlah fitur
- Ada juga pembelaan bahwa justru kesulitan alat itulah intinya
- Logikanya, itu menyaring orang yang tidak cukup berkomitmen, dan setelah melewati rintangannya, imbalannya seumur hidup
- Kurva belajar adalah biaya, bukan kebajikan
- Biaya itu bisa saja layak, tetapi imbalannya harus berupa produktivitas nyata
- Kepuasan karena sudah membayar biaya itu sendiri tidak boleh dianggap sebagai imbalan
- Logika “saya sudah belajar berbulan-bulan jadi ini harus bernilai, dan orang lain juga harus mengikutinya” membungkus sunk cost seolah-olah kemampuan
- Pada titik ini, teka-tekinya bukan lagi pekerjaan yang dilakukan dengan alat, melainkan alat itu sendiri
Sikap yang lebih penting daripada pilihan alat
- Ini bukan argumen menentang alat tertentu, melainkan kritik terhadap cara berpikir dalam memandang alat
- Anda boleh memakai vim, emacs, atau Sublime
- Standarnya adalah apakah alat itu menghilang ke latar belakang dan memungkinkan pengguna terus bekerja
- Standar ini bersifat pribadi
- Masalahnya adalah cerita yang menempel di sekitar pilihan alat
- Keterbatasan dibungkus ulang sebagai fitur
- Upaya memutar jalan untuk menghindari kekurangan dijual sebagai imbalan
- Alat diangkat dari sesuatu yang “dipakai” menjadi “bagian dari diri”
- Tanda paling jelas bahwa alat benar-benar melayani dengan baik adalah ketika pengguna tidak lagi menyadari alat itu
- Alat terbaik bukanlah alat dengan cerita terbaik, melainkan alat yang membuat pengguna lupa bahwa mereka sedang memakainya
1 komentar
Komentar Hacker News
Setelah cukup banyak merancang alat internal untuk tim developer, saya sangat setuju
Dulu saya berpikir karena penggunanya adalah developer, lebih baik membuka “struktur internal”-nya, tetapi kenyataannya itu hanya menjadi hambatan bagi rekan tim dalam menjalankan pekerjaan utama mereka
Rekan tim memakai alat yang saya buat untuk mengerjakan hal yang dibutuhkan perusahaan, bukan karena mereka ingin mengutak-atik alat kecil yang mungkin tidak akan pernah mereka lihat di tempat lain, dan juga tidak ada alasan mereka harus melakukannya
Sampai sekarang saya tetap meninggalkan banyak jalan keluar, tetapi saya berusaha merancang alat internal agar pengguna secara alami jatuh ke pit of success
Dan pesan error, pesan error, pesan error serta saran otomatis untuk error yang umum itu penting
Agak mengecewakan juga karena banyak orang terpaku pada contoh di tulisan itu dan tidak melihat maksud utamanya
Jika alat itu membantu pengguna langsung mengerjakan hal yang mereka anggap penting, kemampuan konfigurasi bisa sangat bernilai, tetapi jika alat itu hanya membereskan masalah yang dianggap kurang penting, konfigurasi justru bisa menjadi gangguan
Misalnya, cara Gusto menangani payroll, pajak, dan pengajuan formulir itu sangat bagus. Karena hampir tidak perlu dipikirkan atau disentuh
Tetapi bagi orang yang memang bekerja di payroll, akuntansi, atau pajak, atau yang bekerja di departemen HR, legal, atau keuangan perusahaan besar, penyederhanaan seperti itu bisa merugikan. Karena mereka jadi harus “bertarung” dengan alatnya, atau kalau mau dibilang lebih halus, pekerjaan mereka jadi terlalu disederhanakan
Selain itu, siapa yang benar-benar membayar, apakah alat itu punya tujuan defensif seperti auditabilitas, keamanan, pembatasan perilaku yang tidak diinginkan, atau justru tujuan kreatif, juga sangat penting. Fitur kreatif memang lebih menarik, tetapi lebih sulit diukur, dan pengguna akhir juga tidak akan membayar sangat mahal hanya karena itu membantu peran mereka
Caranya adalah menyediakan default yang masuk akal dan memungkinkan kustomisasi bila diperlukan. Mulai dari kasus 80%, lalu biarkan orang mengubahnya jika mau, dan itu harus bersifat opsional
Khususnya pada developer tools, ada kecenderungan ragu untuk memasukkan opini yang kuat. Jika tidak yakin bahwa suatu pilihan “selalu benar”, rasanya lebih aman menanyakannya kepada pengguna, dan developer memang cukup cerewet dalam hal seperti ini
Kalau berpikir, “95% mungkin akan menginginkan cara ini, tetapi 5% juga punya alasan yang valid, jadi sebaiknya saya ratakan untuk semua,” hasilnya justru alat yang lebih buruk bagi mayoritas pengguna
Mendukung kustomisasi ternyata jauh lebih rumit daripada yang dibayangkan. Bukan cuma soal bug; setiap opsi membuat pemolesan pengalaman pengguna jadi lebih sulit. Cakupan pengujian juga membesar, dan abstraksi yang lebih fleksibel juga lebih sulit dirancang
Namun tetap ada bagian yang harus diseimbangkan, yaitu memaksa orang mengikuti cara yang benar
Selalu ada orang yang mengeluh karena merasa terhambat saat harus melakukannya dengan benar, dan mereka sering menganggapnya buang-buang waktu
Dari sudut pandang organisasi, tujuannya adalah membuat kurva kinerja tertinggi selama karyawan itu bekerja di sana, sedangkan dari sudut pandang karyawan, tujuannya adalah membuat kurva kinerja untuk seluruh kariernya
Banyak hal bergantung pada hubungan antarorang yang terlibat. Jika pekerja angkut barang berolahraga sehari sebelumnya lalu pegal, dari sudut pandang saya hasilnya lebih lambat dan lebih buruk, tetapi dari sudut pandang perusahaan pindahan itu bisa baik karena dalam jangka panjang dia jadi lebih kuat dan mampu bekerja lebih banyak. Namun jika hari itu dia berhenti atau dipecat, hasilnya kembali buruk
Penilaian yang sesungguhnya bukan apakah macro lebih baik daripada editing di Sublime, melainkan apakah proses berpikir saat membuat macro membantu pekerjaan lain juga, dan sebelum itu dia sebenarnya sedang melakukan apa
Menurut pengalaman saya, hampir tidak ada orang yang benar-benar akan memakai waktu yang mereka habiskan untuk macro atau belajar Vim untuk pekerjaan yang sungguh bermakna. Sering kali mereka bosan atau burnout, jadi mereka ingin memikirkan hal lain yang terasa menyenangkan saat itu
Masalahnya bukan karyawan memakai skrip acak, tetapi bahwa mereka tidak punya rasa urgensi atau ketertarikan pada pekerjaan saat ini
Efek antarmuka menjadi “tak terlihat” pada praktiknya adalah fungsi dari waktu yang dihabiskan di dalam antarmuka itu
Yang sedang ditanggapi penulis tampaknya lebih dekat ke friksi diskresioner, yaitu saat desainer atau product manager menambahkan fitur atau kompleksitas
Namun untuk mencapai tugas tertentu, friksi seperti itu bisa saja diperlukan. Coba pikirkan situasi saat menyelesaikan merge conflict. Dan jika dipakai cukup lama, bahkan langkah-langkah yang “mengganggu” itu pun akan memudar ke latar belakang
Secara konkret, kokpit 737 penuh sekali dengan kontrol. Pesawatnya sendiri juga punya banyak mode, dan ada banyak friksi yang memang disengaja
Tetapi kalau Anda bertanya pada pilot yang sudah lebih dari 10 tahun menangani 737, mereka akan bilang bahwa antarmuka itu sudah menjadi tak terlihat
Bloomberg Terminal, yang sering dianggap “buruk”, juga sama. Di bidang medis pun, bagi orang yang memakai software pemindaian MR lebih dari 8 jam sehari dan ingin akses instan ke semua kontrol, antarmuka penuh tombol bisa jadi justru solusi yang tepat
Programmer cenderung terlalu cepat menggeneralisasi pengalaman dan preferensi mereka sendiri lalu menerapkannya ke orang lain
Sumber: pernah merancang software konsumen dan profesional di IDEO selama 10 tahun
Tulisan itu membahasnya dari sisi pengguna, dan menganggap ada jenis pengguna yang menikmati mempelajari fitur “tambahan” yang nilai akhirnya lebih rendah daripada fungsi inti
Bagian intinya adalah: “Kalau orang memakai vim, emacs, dan sebagainya karena mereka benar-benar merasa itu bagus dan produktif, saya tidak akan mengkritiknya. Orang paling nyaman dengan hal yang sudah akrab bagi mereka. Tetapi orang yang saya bicarakan tidak melihat kekurangan alat itu justru karena keakraban tersebut, lalu memamerkan dan memujinya seperti sebuah permainan”
Dari sudut pandang orang yang sudah lama memakai terminal, tidak terlalu mengejutkan bahwa banyak orang tidak memahaminya. Percakapannya biasanya mengalir seperti ini
“Di terminal, kamu bisa melakukan ini-itu dengan perintah sederhana”
“Di FrobnicatorStudio saya ada shortcut Ctrl+Alt+So untuk itu”
Lalu berlanjut tanpa akhir seperti itu dan berubah menjadi perbandingan yang nyaris tak bermakna seperti “Di Vim, dengan menekan empat kali kamu bisa menghapus 24 baris” versus “Sublime punya multi-cursor”
Mungkin pokok persoalan yang sebenarnya adalah bahwa terminal bisa mencakup jumlah kasus penggunaan yang nyaris tak terbatas berkat cara ia menggabungkan alat baris perintah kecil ke dalam pipeline, tetapi ada kurva belajar yang butuh kira-kira setahun sebelum terasa nyaman
Setelah sampai di titik itu, kamu bisa jauh lebih produktif daripada pengguna GUI rata-rata, tetapi untuk mencapainya dibutuhkan dedikasi dan penderitaan, dan banyak orang menjalaninya bukan karena mau, melainkan karena terpaksa
Dalam kasus saya, pekerjaan pertama saya mengharuskan mengelola server pelanggan lewat ssh, dan server-server itu hanya dipasangi hal minimum. Sering kali bahkan bukan vim, melainkan hanya vi, dan di lingkungan seperti itu tidak ada pilihan selain mencari cara bekerja secara efektif
Kalau tidak mengalami hal itu, saya tidak yakin saya akan mau menanggung rasa sakit untuk mulai bekerja di terminal
Tetapi pada suatu titik saya merasa terlalu banyak membuang waktu di sana. Saya kembali ke baris perintah dengan tshark dan jq, bash/awk/grep lama yang setia, dan gnuplot; setelah itu saya memakai Python, tetapi tetap menggunakan output tshark
Akhirnya saya sampai membuat parser pcap dan pcapng, penanganan ethernet-ip-udp/tcp, bahkan IDE Java lengkap, dan tidak pernah kembali lagi
Saya menempuh jalan berliku yang sama pada semua alat capture dan eksplorasi data yang harus dipakai berulang kali
Sepertinya saya bukan satu-satunya yang mengalami tahap iteratif dalam peningkatan alat seperti ini, dan akan bagus kalau ada istilah atau skala yang pas untuk menjelaskannya
Terminal memang memberi kemampuan yang jauh lebih luas, tetapi pekerjaan yang benar-benar dilakukan secara rutin kemungkinan hanya sekitar 20 hal. Kalau memang hanya 20 hal itu, kurva belajarnya jadi sulit dibenarkan
Misalnya, kalau sedang di terminal dan ingin mencari build script, kamu bisa melakukan sesuatu seperti
cat packages.json | jq .scriptsItu berguna di dalam terminal, tetapi kalau sudah berada di VSCode, cukup
ctrl-p -> packages.json -> ctrl-f -> scr, dan secara nyata jumlah penekanan tombolnya juga lebih sedikitAlur kerja tiap orang benar-benar sangat pribadi, jadi saya tidak akan menyuruh orang lain untuk berubah, tetapi untuk saya sendiri, saya lebih suka alat yang memahami struktur proyek daripada alat yang sekadar memperlakukan proyek sebagai teks, jadi IDE lebih cocok
Aplikasi baris perintah berarti alat seperti grep, sort, cp, git, ls, tar, yang dioperasikan dengan mengetik perintah di shell. Kalau tahu cara pakai umumnya, alat-alat ini juga bisa dipakai di skrip, dan karena itu bisa digabungkan dalam pipeline
Aplikasi antarmuka pengguna teks berarti aplikasi interaktif seperti Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code, yang mengambil alih terminal selama digunakan
Hal-hal seperti ini tidak digabungkan dalam pipeline. Lebih tepatnya, tidak dipakai dalam pipeline dengan cara pemakaian biasanya. Kalau bisa, kemungkinan karena aplikasi tersebut menyediakan antarmuka baris perintah terpisah dari TUI-nya
Memang butuh waktu sampai bisa memakai kotak alat yang sama untuk menyelesaikan semua masalah, tetapi pada akhirnya itu lebih efisien
Hanya saja sulit meyakinkan orang. Sebelum mereka pernah menyelesaikan masalah yang sulit atau nyaris mustahil diselesaikan tanpa alat baris perintah, kesederhanaannya tidak mudah dipahami
Meski begitu, saya tetap sangat sering memakai baris perintah untuk segala hal. Biasanya saya membiarkan jendela konsole tetap terbuka, dan ketika perlu build atau test, saya alt+tab ke sana alih-alih memakai dukungan “build system” milik Sublime
Saya hanya memakai Vim ketika perlu ssh atau saat menggunakan Termux di ponsel
Alat GUI yang dapat diperluas seperti Sublime, VSCode, dan lainnya juga mencakup jumlah kasus penggunaan yang nyaris tak terbatas, bahkan menyediakan lingkungan eksekusi yang lebih stabil dan dapat direproduksi
Menurut saya, alasan perdebatan seperti ini tidak pernah selesai adalah karena orang pada umumnya berpikiran tertutup. Sulit menempatkan diri pada sudut pandang orang lain, dan lebih sulit lagi menerima dengan serius kemungkinan bahwa diri sendiri bisa saja salah
Pada akhirnya, masalah ini hanya penting bagi pemula. Begitu sudah cukup terbiasa, apa pun yang dipakai, bottleneck produktivitas bukan lagi alatnya. Tentu saja, mungkin ada pengecualian kalau yang dipakai adalah ed
Terkait klaim bahwa “navigasi dengan keyboard jauh lebih produktif daripada sering meraih mouse”, cukup banyak orang yang mengatakan dirinya lebih produktif sebenarnya belum pernah benar-benar mengukurnya
Selama bertahun-tahun sudah banyak kompetisi navigasi keyboard versus mouse, dan tergantung detail perancangan tesnya, kadang satu sisi menang, kadang sisi lain menang, bahkan selisihnya kadang cukup besar
Sebelum melihat hasil nyata, tidak jarang metode yang diklaim pengguna lebih produktif justru berakhir kalah
Yang ingin saya kejar bukan metrik produktivitas absolut, melainkan lingkungan yang tidak memutus alur
Bagi banyak orang, tindakan meraih mouse memutus alur dan terasa canggung, dan itu sering kali lebih buruk daripada sekadar terlambat 1 detik, karena membuat mereka keluar dari konteks yang sedang ada di kepala
Dalam kasus saya, menggunakan mouse saat bekerja terasa alami, jadi mengubah alur kerja agar semua navigasi dilakukan lewat keyboard adalah upaya tambahan yang sangat besar hanya demi kemungkinan menghemat sedikit waktu dalam situasi tertentu
Pada alat seperti word processor, IDE, dan file manager, yang intinya adalah membaca, mengetik, lalu memproses apa yang dibaca dan diketik, kita bisa menunjukkan bahwa navigasi keyboard lebih cepat dan lebih alami ketika pengguna sudah mempelajari shortcut-nya
Sebaliknya, pada alat yang berfokus pada informasi visual non-teks, perdebatan keyboard versus mouse jauh lebih condong ke pihak mouse
Meski begitu, tetap ada saat-saat ketika shortcut yang efektif jauh lebih berguna daripada menu dan ikon. Lihat saja software CAD atau pemodelan 3D: 90% pekerjaan pengguna memang menangani data spasial yang ditampilkan secara visual, tetapi mengetahui shortcut untuk mengganti alat atau mengubah pengaturan alat bisa membuat pekerjaan jauh lebih cepat dan mengurangi kebutuhan membongkar menu bertingkat terus-menerus
Saya khawatir penulis tampaknya mencampuradukkan fakta bahwa ia sudah terbiasa dengan alatnya sendiri dengan bukti bahwa alat itu lebih baik
Secara realistis, semua alat memiliki trade-off, dan jika pengguna lebih menyukai alat X daripada alat Y, kemungkinan besar itu bukan karena mereka bodoh, melainkan karena mereka lebih mampu memanfaatkan affordance dari alat tersebut yang hanya benar-benar dipahami oleh pengguna mahir
Jika seorang developer diminta memakai vim, emacs, dan Sublime Text masing-masing selama 10 tahun, saya rasa ia tidak akan bisa yakin mana yang lebih baik. Mungkin ia punya preferensi pribadi, tetapi juga akan bisa menjelaskan mengapa orang lain lebih menyukai alat yang berbeda
Ini terlihat seperti perdebatan yang lahir dari belum pernah benar-benar memberi kesempatan yang layak pada perangkat lunak yang belum akrab
Menurut saya, tanda seorang veteran yang sudah lama berkecimpung adalah semacam ketidakpercayaan samar terhadap semua perangkat lunak dan terhadap janji untuk memperbaiki perangkat lunak itu. Dalam jangka panjang, semua perangkat lunak akan berkonvergensi menuju keserbabiasaan
Yang hanya dikatakan adalah bahwa saya tidak setuju dengan gagasan yang menganggap gesekan alat sebagai sebuah fitur
Dengan mengambil argumennya apa adanya, saya juga bisa menunjukkan bahwa Vim adalah editor yang sempurna bagi saya. Saat saya memakai Vim, ia menjadi tidak terlihat, dan sampai batas tertentu itu karena saya telah mengubah Vim menjadi alat yang saya inginkan
Ia telah mengubah Sublime menjadi alat yang ia inginkan. Meski begitu, pokok intinya tetap sama. Jika Anda membuat sesuatu untuk dipakai orang lain, membuat alat itu tidak terlihat bagi penggunanya adalah sifat yang sangat kuat
Biasa berarti “berkualitas normal atau umum”
Saat membuat aplikasi CRUD berikutnya, Anda mungkin tidak benar-benar membutuhkan teknologi luar biasa yang paling mutakhir dan terbaik
Jika mengutip kalimat yang saya tulis, bunyinya begini: “Yang membuat saya heran adalah banyak orang memperlakukan gesekan itu, yakni upaya untuk mengakali keterbatasan alat, sebagai bagian yang ‘menyenangkan’, lalu mempromosikannya seolah itu bukti bahwa alat tersebut hebat.”
Ini tidak ada hubungannya dengan mengapa saya atau orang lain memilih alat tertentu, melainkan tentang sikap yang memperlakukan kekurangan sebagai sesuatu yang harus diakali seperti permainan puzzle
Pengelola alat yang baik sering kali menerima situasi itu dengan jauh lebih negatif daripada cara pengguna sebenarnya memandang alat tersebut
Sulit membedakan antara “hari ini 10 orang mengeluh soal bug atau fitur yang hilang dan 9990 orang memakainya tanpa masalah” dengan “hari ini 10 orang mengeluh dan hanya 90 orang yang memakainya tanpa masalah”. Namun upaya yang dibutuhkan untuk naik dari kepuasan pengguna 90% ke 99,9% sangatlah berbeda
Saya sangat curiga bahwa ini adalah faktor besar dalam banyak kasus burnout maintainer open source
Pengguna yang tidak puas jauh lebih terlihat daripada yang puas, dan dibanding laju bertambahnya pengguna baru, proporsi pengguna tidak puas yang menghasilkan jumlah laporan bug/permintaan fitur yang sama justru mengecil
Pada akhirnya, bagi maintainer muncul ilusi bahwa seberapa pun mereka memperbaiki sesuatu, persepsi kualitas keseluruhan tetap tidak berubah, dan motivasi untuk melanjutkan pun terkikis
Saya tidak tahu solusi yang bagus untuk masalah ini. Jawaban yang paling jelas adalah lebih sering memberi pujian saat sesuatu bekerja dengan baik, tetapi dalam praktiknya ini lebih mirip masalah aksi kolektif yang jarang terjadi
Secara pribadi, jika sesuatu bekerja dengan baik, saya sengaja berusaha sering memberi umpan balik positif dengan antusias, tetapi sulit membuat perbedaan besar kecuali semua orang juga melakukannya
Kutipan ini teringat di benak saya
“Kita selalu memperhatikan orang yang bungkuk, sibuk, dan rendah diri, lalu mungkin berkata, ‘Betapa rendah hatinya!’ Namun orang yang sungguh rendah hati tidak terlihat. Dunia tidak mengenalnya.”
~ Tito Colliander
Bagian “tanda paling jelas bahwa sebuah alat melayani Anda dengan baik adalah ketika Anda tidak lagi menyadarinya, ketika ia menjadi tidak terlihat. Anda tidak memuja kekurangannya karena tidak menjadikannya hobi, Anda hanya sedikit kesal lalu mengakalinya” tampaknya lebih banyak bergantung pada ketergantungan pengguna daripada pada alat itu sendiri
Tentu saja alat yang berbeda akan menarik pengguna yang berbeda, dan mungkin saja korelasi yang kuat bisa diukur
Selain itu, posisi ini kurang seimbang. Alat tidak pernah sempurna, dan kadang Anda menyadari bahwa alat itu bisa diperbaiki, lalu harus menimbang antara menerapkan perubahan itu dan dampaknya pada kebiasaan Anda
Semakin lama dipakai, perubahan seperti itu mungkin akan semakin kecil, tetapi cara orang memakai alat berevolusi sepanjang hidup, dan wajar jika alat juga berubah demikian
Ini tafsiran yang cukup aneh
Aneh bahwa penulis terobsesi mengatakan Vim itu “terlihat”, sambil mengisyaratkan bahwa multi-cursor dan fitur-fitur Sublime tidak demikian. Hanya karena otak sudah terlatih agar tidak perlu berpikir lagi, bukan berarti itu jadi kurang terlihat
Multi-cursor bukan fitur bawaan di banyak alat, dan untuk memakainya secara efektif pun tetap perlu dipelajari. Sama seperti keybinding Vim
Selain itu, Vim lebih dari sekadar opsi TUI untuk pengguna terminal murni. Ia juga merupakan keybinding yang dipakai orang-orang yang sudah belajar menjadikan keyboard sebagai perpanjangan alami tubuh mereka, agar tidak perlu bolak-balik terus ke mouse. Sama seperti multi-cursor bisa menjadi hal semacam itu bagi pengguna Sublime selama 15 tahun
“Saya pernah melihat orang berbicara tentang betapa ‘menyenangkan’-nya membuat makro untuk menangani masalah refaktorisasi teks sekali pakai. Tapi ketika saya melihat apa yang mereka lakukan dan berapa lama waktu yang dibutuhkan, reaksi jujur saya adalah begini: saya akan menyelesaikannya dalam 1 menit dengan multi-cursor di Sublime, atau cukup menulis skrip pendek.”
Dan, “Yang membuat saya heran adalah banyak orang menganggap gesekan itu, yaitu upaya untuk mengakali keterbatasan alat, sebagai bagian yang ‘menyenangkan’, lalu mempromosikannya seolah itu bukti bahwa alat tersebut hebat.”
Kalau bisa memakai makro Vim secara efektif, bagus. Tapi kalau setelah puluhan tahun memakai Vim pun masih tidak bisa, jangan promosikan itu sebagai bagian yang “menyenangkan”
Sentimen yang paling umum justru bahwa ada kurva belajar, tetapi pada akhirnya itu sepadan
Saya tidak mengerti maksudnya. Makro Vim juga memberi umpan balik visual langsung saat dibuat. Anda merekam sambil mengedit seperti biasa, lalu memutar ulang editan itu nanti
Saya tidak tahu apakah secara teknis mungkin memakai makro tanpa melihat efek langsungnya pada teks saat membuatnya, tapi saya sendiri belum pernah melakukannya
Karena penasaran saya mencari tahu soal multi-cursor, dan tampaknya kelebihannya adalah satu antarmuka yang mudah dijelaskan. Dalam praktiknya, untuk menggantikan itu saya akan memakai beberapa perintah Vim
Saya setuju bahwa untuk sebagian besar pekerjaan yang cocok memakai multi-cursor, multi-cursor bisa lebih baik daripada makro. Tapi biasanya saya memang tidak memakai makro untuk hal-hal seperti itu
Sebagian besar hal yang saya lakukan dengan makro tampaknya tidak bisa dilakukan dengan multi-cursor
Kalau ada contoh “dalam situasi ini multi-cursor hebat dan Vim tidak punya alternatif yang bagus”, saya ingin dibuktikan salah
Namun itu bukan berarti multi-cursor tidak punya kurva belajar. Anda tetap harus memikirkan cara menempatkan cursor di posisi yang benar
Ungkapan “tidak terlihat” dulu saya pakai saat menjelaskan emacs magit
Ia seperti lapisan tipis di atas output git, muncul lalu menghilang, menyimpulkan parameter dari status UI lalu memanggil perintah git yang biasa
Ringan dan cepat. Mungkin tidak begitu untuk proyek besar, tapi katanya begitu