Bus Number – Plugin GitHub yang Diminta Rekan Kerja agar Tidak Saya Tulis

 (scannedinavian.com)
1 poin oleh GN⁺ 2024-11-13 | 1 komentar | Bagikan ke WhatsApp
  • Seorang developer, setelah mengalami kejadian ketika pemecatan membuat satu-satunya kontributor kode penghasil pendapatan menghilang, ingin membuat plugin truck factor di GitHub Enterprise untuk menemukan “orang yang tidak boleh hilang”
  • Rekan-rekannya khawatir metrik ini akan segera terkena Goodhart’s Law, sehingga berubah menjadi alat manajemen untuk mencari “orang yang boleh dipecat” alih-alih orang yang harus dilindungi
  • Repositori dan data Truck-Factor asli masih bisa digunakan, tetapi tanggal pengumpulan datanya tidak jelas dan prosedur di README juga tidak bisa direproduksi apa adanya, sehingga perlu koreksi manual
  • Perhitungan ulang dilakukan dengan meng-clone beberapa repositori GitHub menggunakan gnu parallel, lalu menjalankan kode Java; Linux kernel menghasilkan truck factor 12 tanpa filter linguist, dan 8 setelah filter diterapkan
  • Hasilnya lebih rendah daripada angka makalah asli, yaitu 90 pada preprint 2015 dan 57 pada publikasi resmi, sehingga sulit mengatakan bus factor Linux kernel membaik

Bus Factor dan Ide Plugin yang Berbahaya

  • Bus Factor atau Truck Factor berarti jumlah minimum anggota tim yang harus tiba-tiba menghilang sebelum sebuah proyek berhenti karena kekurangan orang yang memiliki pengetahuan
  • Sekitar 2015, dalam proses PHK di perusahaan, ada kejadian ketika satu-satunya kontributor untuk sebagian codebase yang menghasilkan uang bagi perusahaan ikut dipecat; inilah titik awalnya
  • Setelah terpikir tentang Truck Number, muncul ide untuk membuat plugin GitHub Enterprise yang menghitung “orang yang tidak boleh dipecat”
  • Ketika plugin ini diperkenalkan selama 5 menit dalam lightning talk pada Kamis sore, rekan-rekannya menilai manajer bisa memakainya sebagai alat untuk mencari “orang yang bisa dipecat”
  • Inti dari reaksi ini adalah Goodhart’s Law

Riset Truck Factor yang Ada dan Upaya Mereproduksi

  • Riset asli menghitung berapa orang yang harus menghilang agar proyek berhenti pada berbagai proyek GitHub populer
  • Linux kernel juga termasuk dalam targetnya
  • Di awal tulisan disebutkan bahwa preprint pertama mengatakan Linux akan berhenti jika 80 orang pergi; kemudian dirangkum bahwa angka dalam preprint 2015 adalah 90, dan angka dalam publikasi lengkap adalah 57
  • Bersama mclare, penulis mencoba mereproduksi hasilnya untuk memeriksa apakah truck factor membaik sekitar 10 tahun kemudian
  • Repositori GitHub milik para penulis asli masih bisa digunakan

Keterbatasan Data dan Lingkungan Eksekusi

  • Data makalah disediakan dalam JSON, dan visualisasi aslinya berbasis CSV yang bisa di-scrape
  • Namun tanggal pengumpulan data tidak diketahui
  • Instruksi README tidak berjalan apa adanya, sehingga cara menjalankannya harus diperbaiki dengan merujuk ke issue GitHub
  • Daftar repositori GitHub diambil dari kolom pertama CSV asli, lalu seluruh repositori di-clone
  • Beberapa perintah git clone dijalankan bersamaan dengan gnu parallel

Bagian yang Mentok di gnu parallel, linguist, dan NixOS

  • Walau -j 8 ditentukan pada gnu parallel, muncul gejala bahwa semua 32 core laptop digunakan
  • Proses git clone yang terlihat bersamaan hanya 8, sementara banyak proses git index-pack memakai semua core
  • Kemungkinan penyebabnya diduga karena git index-pack adalah subprocess hasil fork, sehingga parallel mulai menjalankan git clone lain
  • Kode Truck Factor menggunakan linguist dari GitHub untuk mengecualikan file dokumentasi
  • Di lingkungan NixOS, karena tidak punya pengalaman Ruby, instalasi Ruby Gems tidak berhasil diselesaikan tepat waktu; penulis meminta cara memasang plugin linguist di Nix flake atau sebuah pull request

Prosedur Perhitungan Ulang Sebenarnya

  • Repositori asli di-fork dan di-clone ke lokal, lalu cara menjalankannya disesuaikan sambil mengikuti README
  • Source Java dikompilasi menjadi jar dengan mvn package
  • Setiap langkah lebih dulu diuji memakai repositori GitHub numpy, lalu perhitungan ulang untuk seluruh repositori dijalankan
  • mclare mengunduh CSV dari visualisasi asli dan mengubah kolom pertamanya menjadi daftar repositori GitHub
  • Alur eksekusinya adalah sebagai berikut
    • Repositori di-clone dengan parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt)
    • Pindah ke direktori gittruckfactor/scripts untuk menghindari error awk
    • Informasi commit git setiap repositori diekstrak dengan commit_log_script.sh
    • gittruckfactor-1.0.jar dijalankan untuk memproses data commit yang diekstrak
  • Dengan koneksi internet gigabit cepat di rumah, meng-clone semua repositori secara berurutan memakan waktu 17,5 menit
  • Pemrosesan tiap repositori juga tampaknya memakan waktu sekitar 18 menit

Hasil Perhitungan Ulang Linux kernel

  • Contoh output Linux kernel adalah TF = 12, coverage = 49,98%
  • TF authors mencakup Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner, Krzysztof Kozlowski, dan lainnya
  • Linus Torvalds ditampilkan dengan 5.712 file, 6,59%
  • Tanpa plugin linguist untuk menyaring dokumentasi dan library pihak ketiga, hasil Linux kernel truck factor adalah 12
  • Setelah mclare memasang plugin linguist di sistemnya, Linux kernel truck factor yang didapat adalah 8

Faktor yang Terlewat dalam Perhitungan dan Hal yang Perlu Dicek Berikutnya

  • Perhitungan ini tidak mencerminkan proses review
  • Masalahnya, semakin senior seorang developer, semakin banyak review yang harus ia lakukan dibanding mengetik kode langsung dengan keyboard
  • Hal-hal tambahan yang perlu dicek adalah sebagai berikut
    • apakah perhitungan truck factor mencerminkan co-authored-by dan header reviewer di git
    • jika tidak, apakah itu bisa dimasukkan ke dalam perhitungan
    • apa alasan angka Linux berubah besar setelah 10 tahun
    • apakah tidak diterapkannya Levenshtein distance 1 untuk menggabungkan alias developer seperti dalam makalah asli memengaruhi hasil
    • jika repositori Linux kernel di-checkout ke titik waktu pertengahan 2015, apakah kode yang sama masih menghasilkan 80
    • karena algoritme diperbarui pada 2016, apakah angka setelah itu bisa dihitung ulang
  • Kita bisa melihat 156 citation dari makalah asli untuk mencari metode perhitungan yang lebih baik
  • Proyek besar yang lebih baru seperti Rust tidak termasuk dalam makalah 2015, sehingga proyek populer masa kini dan riwayat masa lalu bisa dibandingkan
  • Skrip untuk menemukan truck number per tahun pada repositori git mana pun juga bisa dibuat

Bus Factor yang Makin Rendah

  • Pertanyaan yang ingin diperiksa adalah apakah truck factor membaik seiring waktu
  • Hasilnya lebih dekat ke tidak membaik, malah memburuk
  • Linux kernel menghasilkan angka yang jauh lebih rendah dalam eksekusi kali ini dibanding angka makalah asli
  • Tergantung apakah dokumentasi dan library pihak ketiga difilter, hasil Linux kernel turun lagi dari 12 menjadi 8
  • Visualisasi dan detail lebih lanjut bisa dilihat di tulisan mclare

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-13
Komentar Hacker News

  • Ini persis salah satu fitur dari https://codescene.com/
    Fitur ini menemukan pulau pengetahuan dan menghubungkannya dengan kode yang sering berubah, lalu mengidentifikasi hotspot berisiko tinggi yang sering berubah tetapi sebaran pengetahuannya rendah
    Jika seseorang memberi tahu bahwa mereka akan resign, kita bisa dengan mudah melihat kode yang hanya diketahui orang itu sehingga rencana serah terima juga lebih mudah disusun
    Saya tidak pernah memikirkan bahwa ini bisa disalahgunakan; pada dasarnya ini alat untuk visibilitas. Manajer yang memakainya seperti itu adalah manajer yang buruk, dan kalau memang sudah seperti itu, alat ini tidak akan mengubahnya

    • Jangan terlalu naif soal “penyalahgunaan”. Misalnya Anda bekerja di badan intelijen suatu negara. Katakanlah negara Tussia, yang diblokir aksesnya ke kernel utama Kinux yang dipakai di peralatan militer dunia, lalu Anda mengetahui bahwa orang di kantor sebelah memulai proyek untuk mem-fork kernel itu untuk penggunaan internal negaranya
      Kalau Anda ambisius mengejar promosi, Anda bisa meminta ke divisi akuisisi “8 agen perempuan yang mendapat pelatihan khusus untuk membangun kedekatan dengan para nerd”, dan untuk berjaga-jaga kalau gagal, minta juga cadangan 8 dosis polonium
      Kedengarannya seperti fiksi total, tetapi saya tahu CEO sebuah startup unicorn yang sedang mencari pendanaan seed benar-benar mengalami bagian awal dari hal itu
    • Saya sudah tiga kali bekerja di tempat yang menerapkan Pluralsight Flow, dan di dua di antaranya para manajer langsung mulai memakai metrik itu untuk umpan balik, evaluasi kinerja, dan keputusan perekrutan
      Di tempat kerja ketiga, para developer sudah bisa mengenali pola ini dari jauh dan menolak penggunaan alat maupun evaluasinya sejak awal
      Alat seperti ini mahalnya tidak masuk akal, jadi pihak yang menyetujuinya pasti merasa harus memeras ROI darinya. Karena tidak ada cara yang baik untuk mengukur produktivitas, output, atau silo pengetahuan, akhirnya jatuh ke hal seperti “PR Jose minggu ini sedikit ya”
    • Tujuan berupa visibilitas itu sendiri bagus, tetapi hanya jika bisa tetap berada dalam batas wilayah itu
      Masalahnya, developer juga bisa melihatnya dan mencoba pindah ke proyek atau komponen tertentu supaya masuk ke daftar karyawan yang tidak bisa dipecat. Idealnya, para pekerja bisa bergerak bersama dan membuat truck factor menjadi 0 sehingga sulit memecat siapa pun
      Tentu saja, kalau begini jadinya hampir sepenuhnya buang-buang waktu, dan ini membuktikan poin awal rekan blogger tersebut bahwa “ini akan langsung kena Hukum Goodhart”
    • Firma konsultan eksternal juga bisa memakainya untuk membantu PHK massal perusahaan. Ini tetap mungkin terjadi meskipun manajernya sangat baik

  • Di Amazon, angka seperti ini bisa dengan mudah dilihat siapa saja manajer lewat laporan yang bisa dijalankan dari sistem kode, dan ada banyak cara lain juga untuk melihat apa yang dikerjakan tim serta risiko yang ada. Menurut saya pribadi ini berguna
    Bus factor hanyalah satu sudut pandang; dari sudut lain, ini bisa membantu menemukan silo, engineer yang tidak berkolaborasi dengan orang lain, dan area yang membuat engineer sulit dipindahkan lalu memperbaikinya
    Sebagian developer takut pada kemungkinan bisa digantikan dan mengira sistem yang hanya mereka sendiri pahami adalah jaminan kerja, tetapi sebaliknya itu adalah risiko teknis dan bisa menjadi faktor yang menghalangi engineer hebat pindah ke proyek yang lebih penting. Ini juga bisa menjadi jalan untuk mengerjakan hal lain saat mereka sudah jenuh dengan sistem yang mereka benci

    • Saya tidak takut bisa digantikan. Kalau suatu tempat tidak menginginkan saya, saya juga tidak ingin berada di sana
      Hanya saja, gagasan tentang kemampuan untuk saling menggantikan ini menciptakan overhead besar dan membuat orang-orang berbakat tidak bisa dipakai pada kapasitas terbaik mereka. Karena pada praktiknya mereka memang tidak bisa begitu saja digantikan
      Di beberapa tempat ini perlu, tetapi di tempat lain overhead proses justru menjadi risiko yang jauh lebih besar bagi keberhasilan proyek dibanding bus factor
    • Saya kenal developer yang ditolak mutasi dan promosi karena dianggap tidak mudah mencari penggantinya
      Akhirnya dia resign dalam waktu 3 bulan
    • “Kalau tidak tergantikan, kamu tidak bisa dipromosikan”
    • Dari sudut pandang karyawan, yang tujuan utamanya bukan mengoptimalkan laba perusahaan, menganggap sistem yang hanya diketahui sendiri sebagai jaminan kerja juga merupakan strategi yang realistis
    • Sepanjang karier saya, saya selalu berusaha membuat diri saya dan developer lain semaksimal mungkin dapat saling menggantikan. Sebagian besar pekerjaan digitalisasi memang pada dasarnya seperti itu, dan juga karena menghadapi silo pengetahuan itu menjengkelkan
      Salah satu alasan kami banyak memakai TypeScript di backend juga karena itu mengurangi jumlah bahasa yang perlu diketahui tim kecil menjadi satu. Jadi saat developer frontend libur, mereka benar-benar bisa lepas, dan orang lain bisa meng-cover. Kalau seseorang pindah kerja pun dampaknya tidak terlalu menyakitkan
      Tidak pernah sekali pun ini jadi masalah, dan menurut saya kemampuan untuk saling menggantikan adalah bagian dari sistem yang sehat. Setelah beberapa tahun di sisi manajemen, pelajaran pertama yang paling cepat dipahami adalah “semua orang bisa digantikan, itu hanya soal biaya”. Jadi kalau tingkat pengetahuan seseorang terlalu tinggi, justru bisa merugikan karena manajemen akan mencoba mengurangi risiko itu. Terutama PHK karena alasan ekonomi sering kali cukup acak
      Meski begitu, saya tetap tidak ingin bekerja di tempat yang memakai metrik konyol seperti ini. Makin banyak pita merah yang dipasang untuk melakukan pekerjaan dengan baik, makin kecil kemungkinan saya ingin bekerja bersama mereka. Hal seperti ini mudah menciptakan budaya yang membuat orang memainkan metrik alih-alih melakukan pekerjaan yang baik, dan itu buruk bagi produktivitas maupun kualitas

  • gnu parallel sedang menjalankan 8 tugas git clone sekaligus seperti yang diminta, dan setiap git clone sembarangan memulai banyak thread index-pack
    Di sini akan membantu jika pack.threads sementara diatur ke 1 lewat git config

    • Ini masalah yang makin umum. Kedua lapisan sama-sama mencoba memparalelkan pekerjaan sebanyak jumlah CPU atau core untuk memakai seluruh mesin, dan pada lapisan dalam muncul N² thread/proses
      Karena pertumbuhannya kuadrat, makin banyak CPU makin parah masalahnya. Dengan 32 core, 32² = 1024, dan dalam praktiknya karena Anda menetapkan 8 untuk Parallel, kemungkinan berhenti di sekitar maksimal 256 proses index-pack. Meski begitu, itu tetap membutuhkan banyak memori untuk ditangani, dan sebenarnya tidak memberi manfaat apa pun
      Solusinya adalah memparalelkan hanya salah satu dari dua lapisan tersebut
      Terkait pack.threads, penjelasan di man git-config adalah sebagai berikut: menetapkan jumlah thread yang akan dibuat saat mencari kecocokan delta yang optimal, dan git-pack-objects(1) harus dikompilasi dengan pthreads. Jika tidak, pengaturan ini akan diabaikan dengan peringatan. Ini adalah opsi untuk mengurangi waktu packing pada mesin multiprosesor, tetapi memori yang dibutuhkan untuk jendela pencarian delta akan dikalikan dengan jumlah thread. Jika diatur ke 0, Git akan mendeteksi jumlah CPU secara otomatis dan mengatur jumlah thread sesuai itu
    • Alih-alih membuat pengaturan sementara lewat git config, Anda bisa langsung memakai git -c pack.threads=1 clone: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

  • Saya kurang setuju dengan penafsiran ini. Menurut saya, tulisan ini relevan untuk semua engineering leader
    Bus factor berarti seberapa menderita tim jika seseorang di tim, atau diri Anda sendiri, tertabrak bus
    Bus factor ideal untuk setiap anggota tim adalah 0. Awalnya ini mungkin terdengar seperti “jadikan semua orang barang habis pakai”, tetapi sebenarnya justru hampir kebalikannya, dan itulah poinnya
    Tim harus cukup baik sehingga a) otonom dan b) tidak menyisakan misteri. Dalam keadaan ideal, semua orang memahami bagaimana semuanya bekerja. Karyawan baru harus bisa langsung mulai menghasilkan nilai, dan karyawan yang pergi harus bisa tenang karena tidak ada wilayah tak dikenal yang tertinggal
    Tim ideal dengan BF 0 untuk semua orang adalah sesuatu yang diinginkan. Artinya anggota tim bisa saling menggantikan, dan jika seseorang sakit, cuti, benar-benar pergi, atau disingkirkan, semua anggota tim lain bisa menutup kekosongan itu
    Yang lebih penting, BF 0 adalah cerminan dari kesederhanaan. Perangkat lunak, pipeline build·test·deploy, dokumentasi, dan sistem pendukung semuanya harus kohesif dan konsisten. Menyilo informasi di dalam individu anggota tim itu buruk, dan semua orang harus bisa melakukan build dan deploy
    BF 0 adalah indikator yang sehat, tetapi sama sekali tidak diukur lewat jumlah email, jumlah commit, jumlah PR, jumlah baris kode, kecepatan respons, atau heatmap GitHub. Metrik seperti itu tidak menunjukkan apa-apa, malah merupakan metrik yang merugikan dan mengerikan
    Menilai orang dengan metrik seperti ini tidak ada bedanya dengan monyet di depan mesin tik. Lebih banyak startup perlu mendengar ini

    • Saya selalu mendengar bus factor dijelaskan sebaliknya. Semacam “berapa orang yang harus tertabrak bus agar proyek tak bisa dilanjutkan,” dan saya paham nilai optimalnya adalah sama dengan jumlah anggota tim
      Sepertinya ini membicarakan konsep yang sama, tetapi mengejutkan bahwa angka itu tidak selalu dipakai dengan arah yang sama
    • Saya pernah bekerja pada proyek yang jumlah orang di dunia dengan keterampilan teknis tertentu bisa dihitung dengan jari. Bus factor saat itu jelas 1
      Dalam proyek yang mendorong batas kemungkinan, kesederhanaan kadang bukan pilihan. Tentu saja ini hanya sebagian kecil dari seluruh proyek perangkat lunak, tetapi saat melakukan sesuatu yang belum pernah dilakukan sebelumnya, kekhawatiran yang lebih besar adalah “bagaimana caranya ini bisa berhasil” daripada menjaga kode sesederhana mungkin
      Ini bukan berarti kualitas kode boleh buruk. Hanya saja saat mengerjakan hal yang sulit, kadang diperlukan kode yang kompleks, dan baru setelah beberapa generasi pola desain menjadi lebih mapan sehingga hal sulit itu bisa diwujudkan dengan kode yang tidak serumit sebelumnya. Mungkin itu baru terjadi 10 tahun kemudian
    • Jika sejak hari pertama semua orang bisa memahami kodenya dan bahkan tidak membutuhkan pengetahuan domain, lalu apa proposisi nilai dari produk atau tim itu?
      Jika hal paling rumit yang bisa dibuat hanyalah aplikasi daftar tugas, menurut saya itu tidak menciptakan banyak nilai bagi masyarakat
    • Orang yang kompeten dan percaya diri dalam pekerjaannya akan secara aktif menurunkan bus factor dirinya
      Bus factor yang tinggi berarti pemberi kerja menahan Anda karena apa yang sudah Anda lakukan di masa lalu, bukan karena potensi masa depan Anda
    • Militer berpikir seperti itu. Mereka berasumsi harus tetap berjalan meski kehilangan personel

  • Argumen inti dari makalah aslinya ada di bagian ini
    “Estimasi kami bergantung pada asumsi cakupan. Jika himpunan penulis saat ini mencakup kurang dari 50% dari himpunan file sistem saat ini, sistem tersebut kemungkinan besar akan mengalami keterlambatan serius atau terhenti”
    Di sini, penulis file didefinisikan sebagai pengguna yang memberi kontribusi bermakna pada file tersebut berdasarkan bobot yang telah dihitung sebelumnya

  • Di satu sisi, saya justru akan heran jika metrik dashboard seperti ini belum ada di semacam perangkat lunak enterprise. Di perusahaan lama, manajemen benar-benar pernah bertanya apakah kami bisa membuat laporan harian tentang siapa yang paling banyak mengirim dan menerima email di departemen
    Saya menolak karena tidak suka ke mana arahnya akan mengarah, tetapi rekan lain membuatnya. Sesuai dugaan, orang yang paling banyak menerima dan mengirim email adalah sysadmin, karena akunnya disetel sebagai pengirim otomatis untuk berbagai email dari server. Ia mengirim ratusan email notifikasi ke dirinya sendiri setiap hari, ditambah newsletter dan email ringkasan yang ia langgani
    Di sisi lain, jika rekan-rekan sudah meminta Anda untuk tidak melakukan sesuatu yang bisa memengaruhi pekerjaan mereka, tetapi Anda tetap mendorongnya sebagai proyek hobi, itu terdengar seperti tindakan yang cukup jahat

    • Pada 2015, saat rekan-rekan meminta saya untuk tidak melakukannya, saya memang tidak membuatnya
      Saya hanya ingin melihat apakah perangkat lunak open source yang saya pakai sudah menyebarkan pengetahuan dengan cukup baik untuk meningkatkan daya tahannya
      Tindakan jahat itu saya tolak
    • Metrik yang konyol

  • Menurut saya, “semakin naik tangga karier, developer seharusnya makin sedikit mengetik langsung di keyboard dan lebih banyak melakukan review” adalah salah paham yang umum di perusahaan teknologi
    Kita tidak ingin mengubah developer hebat menjadi manajer biasa-biasa saja

    • Betul. Ada tech lead yang sangat hebat dalam menulis kode, tetapi kemampuan seperti kepemimpinan atau memberi umpan balik sangat buruk
      Ia akan jauh lebih baik tetap sebagai senior developer daripada menjadi tech lead. Sulit membayangkan betapa menderitanya tim jika ia menjadi manajer
    • Jika Anda menganggap code review sebagai “manajemen”, itu cukup mengkhawatirkan

  • Ironi menyedihkan dari semua ini adalah pertanyaannya masih tetap salah
    Saat startup harus melakukan PHK, pertanyaannya bukan “siapa yang bisa dipecat tanpa mengganggu bisnis yang ada”, melainkan “tim mana yang bisa membuat versi produk berikutnya cukup cepat agar perusahaan tidak bangkrut”
    Pada akhirnya setiap persimpangan tetaplah persimpangan, dan banyak perusahaan mati karena tidak memilih jalan dengan cukup cepat

  • CPAN sudah lama melacak bus factor. Sebagai contoh, https://metacpan.org/pod/Moose menampilkan Bus Factor 5 di kolom informasi sebelah kiri

  • Kami suka menyebut ini lottery factor
    Maksudnya, apakah proyek tetap bisa berjalan jika seseorang menang lotre lalu pindah ke pulau tropis tanpa jaringan listrik maupun telekomunikasi
    Penyebutan ini terasa tidak terlalu mengerikan

    • Pemenang lotre akan memberi pemberitahuan resign dua minggu sebelumnya, dan kalau benar-benar perlu masih bisa ditelepon nanti
      Orang yang tertabrak bus langsung hilang seketika. Itu bukan hal yang sama
    • Karyawan yang baik akan berusaha melakukan serah terima proyeknya dan tetap menjawab pertanyaan, tetapi kita juga harus siap untuk kasus saat itu tidak memungkinkan
    • Menghaluskan pindah kerja sebagai sudden death terasa kurang enak
      Ada juga orang yang tidak suka metafora olahraga, tetapi setidaknya ini lebih baik daripada metafora militer
      Lagi pula, sering kali memang tidak ada serah terima sama sekali, jadi unsur mendadaknya sendiri mungkin bukan faktor yang terlalu penting
    • Karena tertabrak bus mungkin justru lebih mudah terjadi, kemungkinan itu juga harus diperhitungkan
    • Saya tidak tahu orang yang menang lotre besar atau tertabrak bus, tetapi saya kenal beberapa orang yang resign setelah menjadi orang kaya kripto