Fatamorgana Produktivitas

 (frantic.im)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Insinyur legendaris Facebook, Bob, meluncurkan Facebook Groups dan berulang kali menghasilkan pencapaian di hackathon meski tanpa lingkungan pengembangan yang canggih
  • Ia hanya menggunakan Sublime Text standar dan log printf; penyorotan sintaksnya tidak akurat, serta tidak ada live reloading maupun debugger
  • Sebaliknya, para developer di sekitarnya menganggap konfigurasi tool yang kompleks—seperti penyorotan sintaks dan snippet Vim, tmux, mosh, shortcut hphpd, serta alias Git—sebagai inti produktivitas
  • Kemenangan Bob di hackathon lebih banyak ditentukan oleh naluri dan intuisi produk, yaitu kemampuan menilai apa yang perlu dibuat, ketimbang pengaturan editor
  • Cara kerja baru memang dapat menciptakan perubahan, tetapi hasil akhir pada akhirnya datang dari memecahkan masalah yang tepat

Perbedaan antara Tool yang Kompleks dan Hasil Nyata

  • Bob adalah insinyur produktif yang meluncurkan Facebook Groups sekaligus sosok legendaris yang berturut-turut menghasilkan karya di hackathon
  • Rekannya yang saat itu terobsesi pada produktivitas menggunakan penyorotan sintaks dan snippet Vim buatan sendiri untuk Hack, dialek PHP milik Facebook
    • Ia menjalankan tmux di atas mosh, serta menyiapkan shortcut hphpd kustom dan alias Git
  • Cara kerja Bob, sebaliknya, sangat sederhana
    • Ia menggunakan Sublime Text tanpa pengaturan khusus, sehingga sekitar separuh warna kodenya ditampilkan keliru
    • Alih-alih live reloading atau debugger, ia memasukkan printf ke dalam kode dan menunggu log muncul
  • Pada hackathon hari itu, Bob menang; karyanya diingat sebagai fitur yang mendukung posting jual-beli di Facebook Groups
    • Fitur ini kemudian berkembang menjadi Facebook Marketplace

Bukan Bagaimana, tetapi Apa yang Akan Dibuat

  • Jika terlalu fokus pada tool yang kompleks, kita bisa tenggelam dalam bagaimana cara bekerja dan kehilangan pandangan tentang apa yang dikerjakan
  • Inti dari produktivitas tinggi Bob bukanlah pengaturan editor, melainkan naluri dan intuisi produk
  • Di X, setiap hari muncul cara kerja baru yang seolah-olah akan mengubah segalanya, dan sebagian di antaranya memang mungkin menciptakan perubahan nyata
  • Namun yang paling penting bukanlah tool atau cara kerja itu sendiri, melainkan memecahkan masalah yang tepat

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Membelah orang menjadi perajin yang menyayangi alat dan orang yang terobsesi pada alat itu keliru. Alat yang baik bukan mainan, melainkan sarana untuk mencapai tujuan; saya sendiri pernah menghabiskan beberapa hari membuat skrip shell, fungsi Emacs, alat penataan jendela, dan sebagainya yang disesuaikan dengan alur kerja saya.
    Hasilnya, penyorotan sintaks, navigasi dan analisis kode, tata letak layar, serta operasi Git bisa dilakukan hanya dengan beberapa ketukan tombol, dan hal-hal yang memecah konsentrasi pun hilang. Berinvestasilah pada lingkungan kerja seperti kursi, prompt shell, atau editor, tetapi setelah nyaman, lupakan itu dan fokuslah pada masalah sebenarnya.
    Namun, penyesuaian alat tanpa henti bisa menjadi tanda bahwa kita menghindari tugas yang berat dan tidak menyenangkan, dan ini bukan persoalan sederhana yang bisa disalahkan pada alat itu sendiri.

    • Apa yang akan dilakukan kalau di tempat kerja baru diberi stack teknologi baru dan laptop Windows? Di awal karier, saya belajar bekerja efisien hanya dengan alat bawaan dari lingkungan yang diberikan, dan dalam praktiknya jarang sekali kita benar-benar bisa memilih alat sendiri. Alat lintas platform pun, kecuali lini produk JetBrains, cenderung kurang konsisten.
    • Ini terlihat seperti perbedaan antara samurai dan ninja. Samurai menganggap pedang sebagai perpanjangan jiwa, tetapi ninja akan memakai pedang untuk mencongkel benda jika perlu. Dalam ekonomi saat ini, pandangan ala samurai terhadap alat tidak cocok.
    • Penting untuk menikmati penggunaan alat. Meski produktivitas tidak meningkat 10 kali lipat, intinya adalah bisa fokus pada pekerjaan dan menikmati prosesnya.
      Terutama di era LLM, alat membuat kita terus berpindah-pindah antara berbagai agen dan terminal. Pergantian konteks yang sering seperti ini merampas kesenangan dan kondisi fokus mendalam, jadi saya berharap ada yang menemukan solusinya.
    • Sepertinya banyak pemula melewati langkah-langkah yang diperlukan karena ingin diakui dan dianggap serius. Terlihat seperti itu berbeda dengan benar-benar menjadi seperti itu, dan selama membangun kemampuan mereka juga harus menanggung kebutuhan hidup.
    • Setelah menguasai suatu keterampilan, alat yang baik itu sendiri menjadi sumber kesenangan besar. Sebaliknya, orang yang mahir kadang bisa menghasilkan sesuatu yang mengejutkan bagus bahkan dengan alat yang tidak cocok.

  • Saya melihat banyak teknisi menghabiskan lebih banyak waktu untuk mengoptimalkan konfigurasi lingkungan daripada benar-benar membuat sesuatu, dan saya sendiri juga pernah begitu. Gagasan bahwa 90% waktu coding adalah mengetik sehingga kita harus meningkatkan kecepatan input itu keliru; 90% waktu seharusnya dipakai untuk berpikir, dan sebagian besar dari itu untuk membaca.

    • Perangkat lunak adalah perwujudan solusi atas suatu masalah, jadi pertama-tama kita harus mendefinisikan masalah yang akan dipecahkan. Kode adalah snapshot yang menunjukkan tingkat pemahaman kita saat ini atas masalah serta kejelasan dan kesesuaian solusi, kepada semua orang termasuk diri kita di masa depan.
      Coding pada saat yang tepat adalah mengonkretkan solusi yang sudah dipahami, nyaris seperti pekerjaan mengetik.
    • Dulu saya terobsesi pada konfigurasi, tetapi sejak menggunakan AI saya membuat hal-hal keren yang sebelumnya tidak bisa saya buat. Di sisi lain, pemahaman terhadap kode dasar dan kemampuan lama saya perlahan melemah; saya kagum pada teknik-teknik baru tetapi rasanya tidak benar-benar mempelajarinya secara mendalam.
      Dalam arti AI menurunkan ambang yang harus dilewati saat memulai, itu juga bentuk lain dari perbaikan lingkungan. Dulu, ketika bepergian di Eropa sambil belajar InterviewCake untuk pindah dari peran QA ke developer, saya juga membuang waktu menyempurnakan konfigurasi editor alih-alih memecahkan soal.
      Ini mungkin gejala ADHD. Setelah baru-baru ini menjalani pengobatan, produktivitas saya berubah drastis, sampai-sampai saya ingin menangis karena merasa telah menyia-nyiakan separuh hidup untuk menyempurnakan konfigurasi alih-alih melakukan pekerjaan nyata.
    • Ada jurang antara produktivitas nyata dan produktivitas yang dirasakan. Menekan tombol untuk mengedit kode dengan mahir di Vim atau Emacs memang membuat kita merasa seperti hacker, tetapi itu tidak berarti produktif. Mengarahkan puluhan agen AI dengan token dalam jumlah besar pun tidak menjamin hasilnya akan berjalan atau memecahkan masalah.
    • Saya tidak yakin rasio bahwa sebagian besar developer aplikasi CRUD biasa harus memakai 90% waktunya untuk berpikir dan membaca itu akurat.
    • Berpikir dan mengetik sering terjadi bersamaan. Banyak orang lebih mudah menalar masalah sambil menulis dan memperbaiki kode; ini juga salah satu alasan mengapa, meski membaca semua kode yang dibuat LLM, pemahaman terhadap kode bisa turun drastis.

  • Ada perusahaan yang didanai VC tetapi tidak bisa membuat produk yang benar-benar digunakan orang atau dibayar. Mereka menunjukkan betapa sibuk dan produktifnya mereka untuk membenarkan valuasi, dan demam AI mungkin berada dalam konteks yang sama karena lebih fokus pada produktivitas dan metode daripada pada apa yang akan dibuat.
    https://components.news/the-gamer-and-the-nihilist/ membandingkan startup nihilistis seperti ini dengan studio game yang membuat produk yang dipakai dan dibayar orang. Dalam ekonomi di mana aplikasi produktivitas mencakup hampir 40% hasil Product Hunt, tenaga kerja kadang dicurahkan bukan untuk benar-benar membuat sesuatu, melainkan untuk terlihat seolah-olah sedang membuat.

    • Developer game juga mencurahkan upaya besar untuk membuat alat, hanya saja sasaran utamanya bukan editor teks.
    • Saya penasaran di mana posisi orang yang menghabiskan tak terhitung banyaknya waktu membuat lingkungan game yang sempurna ketimbang bermain game, atau audiophile yang seumur hidup mencari perangkat sempurna ketimbang menikmati musik, dalam analogi ini.
    • Ini lebih mirip manipulasi sinyal yang sudah berulang sejak lama daripada gelembung. Hal itu selalu ada dan akan terus ada.

  • Buat atau gunakan alat produktivitas hanya sejauh agar tidak tertinggal, dan selebihnya anggap sebagai jebakan. Dulu saya meninjaunya sekali per kuartal, tetapi setelah AI saya memakai 1–2 hari per minggu untuk kerja meta berupa perbaikan alat, dan saya memperkirakan itu akan berkurang ketika alat terkait makin terstandar.
    Jika citra sebagai ahli alat menjadi terlalu kuat, kita bukan hanya melewatkan pekerjaan yang benar-benar bernilai, tetapi juga dinilai sebagai orang yang punya resep rahasia produktivitas. Jika perbedaannya tidak sebesar yang diharapkan, penilaian lain dari kita pun bisa ikut tidak dipercaya.

  • Semakin sedikit waktu yang saya habiskan di depan komputer, semakin banyak pekerjaan yang saya selesaikan, dan ketika saya mengurangi monitor dari 3 menjadi 1, produktivitas saya meningkat besar. Saya menyelesaikan sebagian besar masalah saat memotong sayur atau memotong rumput; duduk di depan teknologi yang berkilau tidak membuat penilaian menjadi lebih cepat dan lebih baik.
    Alasan saya menghasilkan kinerja lebih baik daripada tim developer di perusahaan klien juga karena saya bukan karyawan tetap, sehingga bisa benar-benar berhenti sejenak dan berpikir pelan-pelan. Teater produktivitas seperti tekanan untuk menjaga status Teams tetap hijau menciptakan banyak keputusan bodoh di banyak organisasi.

    • Selama 15 tahun saya bekerja di dua perusahaan yang kantornya berada di tebing menghadap laut di La Jolla, California. Saya berjalan di tebing dan taman sambil memikirkan pekerjaan, dan jika diskusi serius tidak membutuhkan papan tulis, saya mengajak rekan kerja berjalan bersama. Hammock talk dari Rich Hickey layak didengarkan kembali.
    • Melihat nama pengguna Anda, saya penasaran apakah Anda Bob yang muncul dalam tulisan itu.

  • Saat memikirkan alasan keberadaan produktivitas, saya sampai pada hipotesis bahwa itu adalah upaya mengurangi rasa sakit. Berbagai optimasi kinerja, termasuk produktivitas programmer, sering menjadi tempat pelarian engineer dari rasa sakit seperti ambiguitas domain masalah, politik organisasi, ketidakjelasan, dan risiko kegagalan.
    Namun untuk memecahkan masalah nyata, kita harus berhadapan dengan realitas: meninjau alur kerja pengguna dengan detail yang membosankan, mengusulkan strategi bersama dengan jelas agar mendapat kerja sama orang lain, dan sebagainya. Tidak perlu mengagungkan rasa sakit itu sendiri, tetapi hasil yang baik mengandung latihan seperti atlet, dan kita perlu membangun kemampuan untuk mengelola rasa sakit yang diperlukan di arena pertandingan.

  • Intinya ada pada apakah mudah mendapat pengakuan. Alat yang berkilau bisa dilihat dan dikagumi siapa pun, tetapi sedikit orang yang bisa mengenali produk atau fitur baru yang hebat dari editor kosong atau kode kerangka. Karena itu, perhatian terkumpul pada alat yang mudah terlihat, sementara pertanyaan sulit dan kabur tentang apa yang harus dibuat diabaikan.
    Untuk alat, saya memakai standar ala Marie Kondo. Jika tidak menyenangkan digunakan dan tidak membuat hidup lebih mudah, buang; jika iya, pertahankan.

  • Pada 2004, sebuah tim kecil yang sebagian besar terdiri dari developer junior mendapat pelatihan Java yang sangat bagus dan luas. Sebelum pelatihan, kami terobsesi pada konfigurasi IntelliJ dan Eclipse serta berdebat sengit, tetapi secara mengejutkan instruktur menyarankan kami hanya memakai alat JDK dan Notepad bawaan.
    Tujuannya adalah agar kami belajar apa yang terjadi di dalam, dan katanya produktivitas pun kemungkinan tidak akan jauh berbeda.

  • Alasan orang terobsesi mengoptimalkan lingkungan adalah karena hubungan antara upaya terfokus dan imbalannya terlihat, konkret, dan fisik. Sebaliknya, pembelajaran abstrak tidak begitu. Tugas belajar jauh lebih banyak daripada hal-hal seperti mengoptimalkan kursi, jadi akan bagus kalau ada cara untuk membuat pembelajaran abstrak terasa lebih konkret.

  • Ini bukan tentang produktivitas, melainkan tentang kesenangan bermain dengan mainan.