Bus Number – İş Arkadaşlarımın Yazmamamı İstediği GitHub Eklentisi

 (scannedinavian.com)
1 puan yazan GN⁺ 2024-11-13 | 1 yorum | WhatsApp'ta paylaş
  • Bir geliştirici, işten çıkarmalar sonucunda gelir getiren bir kodun tek katkıcısının ortadan kaybolmasını yaşadıktan sonra, GitHub Enterprise üzerinde “kaybedilmemesi gereken kişileri” bulacak bir truck factor eklentisi yapmak istedi
  • İş arkadaşları, bu metriğin kısa sürede Goodhart Yasasına takılıp korunması gereken kişilerden çok “işten çıkarılabilecek kişileri” bulan bir yönetim aracına dönüşebileceğinden endişe etti
  • Orijinal Truck-Factor deposu ve verileri hâlâ kullanılabiliyordu, ancak verilerin hangi tarihte toplandığı belirsizdi ve README’deki adımlar da olduğu gibi yeniden üretilemediği için elle düzeltme gerekti
  • Yeniden hesaplama, birden çok GitHub deposunu gnu parallel ile klonlayıp ardından Java kodunu çalıştırma şeklinde yapıldı; Linux kernel için linguist filtresi olmadan truck factor 12, filtre uygulandıktan sonra 8 çıktı
  • Sonuçlar, makaledeki 2015 tarihli preprint’teki 90 ve resmi yayındaki 57 değerlerinden de düşük kaldı; bu da Linux kernel’in bus factor’ünün iyileştiğini söylemeyi zorlaştırıyor

Bus Factor ve riskli eklenti fikri

  • Bus Factor ya da Truck Factor, bir projenin bilgili insan eksikliği nedeniyle durmadan önce aniden ortadan kaybolması gereken asgari ekip üyesi sayısını ifade eder
  • Çıkış noktası, 2015 civarında şirketteki işten çıkarma sürecinde şirketin para kazandığı kod tabanlarından birinin tek katkıcısının işten çıkarılması oldu
  • Truck Number fikri akla geldikten sonra, GitHub Enterprise eklentisi olarak “işten çıkarılmaması gereken kişileri” hesaplama fikri ortaya çıktı
  • Perşembe öğleden sonra yapılan 5 dakikalık lightning talk’ta bu eklenti tanıtılınca, iş arkadaşları yöneticilerin bunu “işten çıkarılabilecek kişileri” bulmak için kullanabileceğini düşündü
  • Bu tepkinin merkezinde Goodhart Yasası vardı

Mevcut Truck Factor araştırması ve yeniden üretme denemesi

  • Orijinal araştırma, çeşitli popüler GitHub projelerinde projenin durması için kaç kişinin ortadan kaybolması gerektiğini hesaplıyordu
  • Buna Linux kernel de dahildi
  • Yazının başında ilk preprint’in Linux için sistemin durması adına 80 kişinin ayrılması gerektiğini söylediği belirtiliyor; ileride ise 2015 tarihli preprint için 90, tam yayın için 57 değeri veriliyor
  • mclare ile birlikte, yaklaşık 10 yıl sonra truck factor’ün iyileşip iyileşmediğini görmek için sonuçlar yeniden üretilmeye çalışıldı
  • Yazarların orijinal GitHub deposu hâlâ kullanılabiliyordu

Veri ve çalışma ortamının kısıtları

  • Makalenin verileri JSON olarak sunuluyordu, orijinal görselleştirme ise scrape edilebilen CSV’ye dayanıyordu
  • Ancak veri toplama tarihi bilinmiyordu
  • README’deki yönergeler olduğu gibi çalışmadığı için GitHub issue’larına bakarak çalıştırma yöntemini düzeltmek gerekti
  • Orijinal CSV’nin ilk sütunundan GitHub depo listesi çıkarılıp tüm depolar klonlandı
  • gnu parallel ile birden çok git clone komutu aynı anda çalıştırıldı

gnu parallel, linguist ve NixOS’ta takılan noktalar

  • gnu parallel için -j 8 verilmesine rağmen dizüstü bilgisayardaki 32 çekirdeğin tamamının kullanıldığı görüldü
  • Aynı anda görünen git clone süreçlerinin sayısı 8’di, ancak çok sayıdaki git index-pack süreci tüm çekirdekleri kullanıyordu
  • Muhtemel neden olarak, git index-pack’in fork edilen alt süreç olması ve bu yüzden parallel’in başka git clone işlemleri başlatması tahmin edildi
  • Truck Factor kodu, dokümantasyon dosyalarını dışlamak için GitHub’ın linguist aracını kullanıyor
  • NixOS ortamında Ruby deneyimi olmadığı için Ruby Gems kurulumunu zamanında çözemedi; Nix flake içinde linguist eklentisinin nasıl kurulacağına dair bilgi ya da pull request istiyor

Gerçek yeniden hesaplama süreci

  • Orijinal depo fork edilip yerelde klonlandıktan sonra README izlenerek çalıştırma yöntemi uyarlandı
  • Java kaynak kodu mvn package ile jar dosyasına derlendi
  • Önce numpy GitHub deposunda her adım test edildi, ardından tüm depolar için yeniden hesaplama yapıldı
  • mclare, orijinal görselleştirmenin CSV’sini indirip ilk sütunu GitHub depo listesine dönüştürdü
  • Çalışma akışı şu şekildeydi
    • parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt) ile depolar klonlandı
    • awk hatasını önlemek için gittruckfactor/scripts dizinine geçildi
    • commit_log_script.sh ile her depo için git commit bilgileri çıkarıldı
    • Çıkarılan commit verilerini işlemek için gittruckfactor-1.0.jar çalıştırıldı
  • Evdeki hızlı gigabit internet bağlantısında tüm depoları sıralı biçimde klonlamak 17,5 dakika sürdü
  • Her deponun işlenmesi de kabaca 18 dakika sürmüş görünüyor

Linux kernel yeniden hesaplama sonuçları

  • Linux kernel için örnek çıktı TF = 12, coverage = 49.98% oldu
  • TF authors arasında Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner ve Krzysztof Kozlowski gibi isimler yer aldı
  • Linus Torvalds için 5.712 dosya ve %6,59 değeri gösterildi
  • Dokümantasyon ve üçüncü taraf kütüphaneleri filtreleyen linguist eklentisi olmadan elde edilen Linux kernel truck factor değeri 12 idi
  • mclare, kendi sistemine linguist eklentisini kurduktan sonra Linux kernel için 8 truck factor sonucu aldı

Hesaplamada eksik kalan unsurlar ve sonraki inceleme başlıkları

  • Bu hesaplama review sürecini yansıtmıyor
  • Kıdem arttıkça geliştiricilerin doğrudan klavyede kod yazmaktan çok daha fazla review yapması gerekmesi ayrı bir sorun
  • Ayrıca bakılabilecek başlıklar şunlar
    • Truck factor hesabının git’teki co-authored-by ve reviewer başlıklarını dikkate alıp almadığı
    • Almıyorsa bunun hesaba katılıp katılamayacağı
    • Linux değerlerinin 10 yıl sonra neden büyük ölçüde değiştiği
    • Orijinal makalede geliştirici alias’larını birleştirmek için kullanılan Levenshtein distance 1 yaklaşımının bu sonuçları etkileyip etkilemediği
    • Linux kernel deposu 2015 ortasındaki duruma checkout edilirse aynı kodun hâlâ 80 verip vermeyeceği
    • Algoritma 2016’da güncellendiği için sonraki değerlerin yeniden üretilip üretilemeyeceği
  • Orijinal makalenin 156 atfına bakılarak daha iyi bir hesaplama yöntemi olup olmadığı görülebilir
  • Rust gibi daha yeni büyük projeler 2015 tarihli makaleye dahil edilmediğinden, bugünün popüler projeleri geçmiş verilerle karşılaştırılabilir
  • Rastgele bir git deposu için yıllara göre truck number bulan bir script de yazılabilir

Daha da düşen Bus Factor

  • Yanıtı aranmak istenen soru, truck factor’ün zaman içinde iyileşip iyileşmediğiydi
  • Sonuç, iyileşmediği ve hatta kötüleştiği yönüne daha yakın
  • Linux kernel, orijinal makaledeki değerden çok daha düşük bir sonuç verdi
  • Dokümantasyon ve üçüncü taraf kütüphane filtrelemesine bağlı olarak Linux kernel sonucu 12’den 8’e daha da düştü
  • Daha fazla görselleştirme ve ayrıntı için mclare’in yazısına bakılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-11-13
Hacker News yorumları

  • https://codescene.com/ özelliklerinden biri tam olarak bu
    bilgi adalarını bulup bunları sık değişen kodla ilişkilendirerek, değişimin fazla ama bilginin yayılımının düşük olduğu riskli hotspot'ları tespit ediyor
    Biri ayrılacağını söylediğinde sadece onun bildiği kodu kolayca görebildiğiniz için devir planını çıkarmak da kolaylaşıyor
    Bunun kötüye kullanılabileceğini hiç düşünmemiştim; aslında görünürlük için yapılmış bir araç. Bunu o şekilde kullanan yönetici kötü bir yöneticidir ve zaten öyle biriyse bu araç onu değiştirmez

    • “Kötüye kullanım” konusunda fazla saf olmamak gerek. Diyelim bir ülkenin istihbarat teşkilatındasın. Dünya çapındaki askeri ekipmanlarda kullanılan ana çekirdek Kinux'a erişimi engellenmiş bir ülke olan Tussia olduğunu varsayalım; yan ofisteki birinin o çekirdeği ülke içi kullanım için fork'layan bir proje başlattığını öğreniyorsun
      Terfi hırsın varsa, devralma işlerinden sorumlu birime “ineklerle yakınlaşma özel eğitimi almış 8 kadın ajan” talep edebilir, başarısızlık ihtimaline karşı da yedekte 8 doz polonyum isteyebilirsin
      Tam bir kurgu gibi gelebilir ama tohum yatırımı arayan bir unicorn startup CEO'sunun gerçekten bunun ilk kısmına denk gelen bir şey yaşadığını biliyorum
    • Pluralsight Flow'un kullanıma alındığı üç iş yeri gördüm; bunların ikisinde yöneticiler metrikleri hemen geri bildirim, performans değerlendirmesi ve işe alım kararlarında kullanmaya başladı
      Üçüncü iş yerinde ise geliştiriciler bunun nereye gittiğini uzaktan fark edip aracı kullanmayı da değerlendirmeyi de reddetti
      Bu tür araçlar o kadar pahalı ki onay veren taraf bir şekilde yatırım getirisini çıkarmak zorunda kalıyor. Verimliliği, çıktıyı ve bilgi silo'larını düzgün ölçmenin bir yolu olmayınca iş sonunda “bu hafta Jose'nin PR sayısı azmış” noktasına geliyor
    • Görünürlük amacı kendi başına harika, ama ancak o sınırlar içinde kaldığı sürece
      Sorun şu ki geliştiriciler de buna bakıp işten çıkarılması imkânsız çalışanlar listesine girmek için hedef projelere ya da bileşenlere geçmeye çalışabilir. İdeal durumda çalışanlar birlikte hareket edip truck factor'u 0'a indirerek kimsenin kolay kolay işten çıkarılamayacağı bir ortam yaratabilir
      Elbette bu durumda neredeyse tamamen zaman kaybına dönüşür ve blog yazarının iş arkadaşlarının söylediği “hemen Goodhart Yasası'na kurban gider” tespiti doğrulanmış olur
    • Harici bir danışmanlık şirketi bunu şirketin toplu işten çıkarma sürecine yardım etmek için de kullanabilir. Yönetici ne kadar iyi olursa olsun bu mümkün

  • Amazon'da bu tür sayıları kod sistemlerinden herkesin çalıştırabildiği raporlarla kolayca görebiliyorsunuz; ayrıca ekibin ne yaptığına ve ne tür riskler olduğuna bakmanın başka yolları da var. Bana kişisel olarak faydalı geliyor
    Bus factor sadece bir bakış açısı; başka bir açıdan bakınca silo'ları, başkalarıyla işbirliği yapmayan mühendisleri ve mühendislerin kolayca taşınamadığı alanları bulup düzeltmeyi sağlıyor
    Bazı geliştiriciler yerlerinin doldurulmasından korkup sadece kendilerinin bildiği sistemlerin iş güvencesi olduğunu düşünüyor ama tersine bu teknik bir risk ve iyi mühendislerin daha önemli projelere geçmesini engelleyen bir unsur da olabilir. Nefret ettikleri bir sistemden bıktıklarında başka bir işe geçebilmenin yolu da budur

    • Yerimin doldurulmasından korkmuyorum. Beni istemeyen bir yerde ben de olmak istemem
      Ama yerine başkasının konulabilir olması fikri büyük bir ek yük yaratıyor ve yetenekli insanları tam kapasiteleriyle kullanmayı engelliyor. Çünkü onlar aslında gerçekten yerine kolayca başkası konulabilecek kişiler değil
      Bazı yerlerde bu gerekli olabilir ama başka yerlerde süreçten doğan ek yük, bus factor'dan çok projenin başarısı için daha büyük bir risk haline geliyor
    • Kolayca yedek bulunamayacağı gerekçesiyle yer değiştirme ve terfi talepleri reddedilen bir geliştirici tanıyorum
      Sonuç, 3 ay içinde istifa etmesi oldu
    • “Yerine başkası konulamıyorsa terfi edemezsin”
    • Şirket kârını optimize etmek ana hedefi olmayan çalışan açısından bakıldığında, sadece kendi bildiğin bir sistemin iş güvencesi olduğu düşüncesi de gerçekçi bir strateji
    • Kariyerim boyunca hem kendimi hem de diğer geliştiricileri olabildiğince ikame edilebilir hale getirmeye çalıştım. Dijitalleştirme işinin önemli bir kısmı zaten doğası gereği böyle ve bilgi silo'larıyla uğraşmak da can sıkıcı
      Backend'de de bol bol TypeScript kullanmamızın nedenlerinden biri, küçük bir ekibin bilmesi gereken dil sayısını bire indirmesi. Böylece frontend geliştiricisi tatile çıktığında gerçekten bağlantıyı kesebiliyor ve başkası devralabiliyor. Biri iş değiştirirse de daha az sancılı oluyor
      Bu hiçbir zaman sorun olmadı; ikame edilebilirliğin sağlıklı sistemlerin bir parçası olduğunu düşünüyorum. Birkaç yıl yönetim tarafında kalınca ilk öğrenilen şeylerden biri “herkesin yeri doldurulabilir, mesele sadece maliyet” oluyor. Bu yüzden bilgi seviyesi fazla yükselirse, yönetim bu riski azaltmaya çalışırken bu durum senin aleyhine bile işleyebilir. Özellikle ekonomik gerekçelerle yapılan toplu işten çıkarmalar oldukça rastgele de olabiliyor
      Yine de bu kadar saçma metrikler kullanan bir yerde çalışmak istemem. İyi iş yapmanın etrafına ne kadar çok kırmızı bant çekilirse, orada birlikte çalışmak isteme olasılığım o kadar düşer. Böyle şeyler insanların iyi iş yapmasındansa metriklerle oynamasına yol açar ve verimlilikle kalite açısından kötü bir kültür üretmeye çok yatkındır

  • gnu parallel, istendiği gibi aynı anda 8 git clone işi çalıştırıyor ve her git clone da kendi kendine çok sayıda index-pack thread’i başlatıyor.
    Burada git config ile pack.threads değerini geçici olarak 1’e ayarlamak yardımcı olur.

    • Giderek daha yaygın görülen bir sorun. Her iki katman da CPU ya da çekirdek sayısı kadar paralelleşip tüm makineyi kullanmaya çalışıyor ve iç katmanda N² thread/process oluşuyor.
      Kare şeklinde büyüdüğü için CPU arttıkça sorun daha da kötüleşiyor. 32 çekirdekte 32² = 1024 eder; gerçekte Parallel’e 8 verdiğiniz için muhtemelen en fazla 256 kadar index-pack sürecinde durmuş olurdu. Yine de bunu kaldırmak için çok bellek gerekir ve pratikte hiçbir fayda sağlamaz.
      Çözüm, iki katmandan yalnızca birini paralelleştirmektir.
      pack.threads hakkında man git-config açıklaması şöyle: en iyi delta eşleşmelerini ararken oluşturulacak thread sayısını belirtir ve git-pack-objects(1) komutunun pthreads ile derlenmiş olması gerekir. Aksi halde bir uyarıyla yok sayılır. Çok işlemcili makinelerde paketleme süresini azaltmak için tasarlanmıştır, ancak delta arama penceresi için gereken bellek thread sayısıyla çarpılır. 0 verilirse Git CPU sayısını otomatik algılar ve buna göre uygun sayıda thread kullanır.
    • git config ile geçici ayar yapmak yerine doğrudan git -c pack.threads=1 clone kullanabilirsiniz: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

  • Bu yorum pek iyi değil. Bence bu yazı tüm mühendislik liderleri için yazılmış.
    Otobüs faktörü, ekipten birinin ya da sizin otobüs çarpması sonucu devre dışı kalmanız halinde ekibin ne kadar acı çekeceğini ifade eder.
    Her ekip üyesi için ideal otobüs faktörü 0’dır. İlk bakışta “herkesi sarf malzemesine çevirin” gibi gelebilir, ama aslında neredeyse tam tersidir ve mesele de budur.
    Ekip, a) özerk ve b) gizem barındırmayacak kadar iyi olmalıdır. İdeal durumda herkes her şeyin nasıl çalıştığını anlar. Yeni çalışanlar hemen değer üretmeye başlayabilmeli, ayrılan çalışanlar da geride bilinmeyen alan bırakmadıkları için içleri rahat ayrılabilmelidir.
    Herkesin BF’sinin 0 olduğu ideal ekip arzu edilendir. Bu, ekip üyelerinin birbirinin yerini alabileceği ve biri hastalansa, izne çıksa, gerçekten ayrılsa ya da çıkarılsa bile diğerlerinin boşluğu doldurabileceği anlamına gelir.
    Daha da önemlisi, 0 BF’nin basitliğin bir yansıması olmasıdır. Yazılımın, build·test·deploy hattının, dokümantasyonun ve destek yapısının hepsi tutarlı ve bütünlüklü olmalıdır. Bilgiyi ekip üyelerinin içinde silo halinde tutmak kötüdür; herkes build alıp deploy yapabilmelidir.
    0 BF sağlıklı bir göstergedir, ama asla e-posta sayısı, commit sayısı, PR sayısı, kod satırı sayısı, yanıt hızı ya da GitHub heatmap’i gibi şeylerle ölçülmez. Bu tür metrikler hiçbir şey göstermez; hatta zararlı ve korkunç metriklerdir.
    İnsanları bu metriklerle değerlendirmek daktilo başındaki maymunlardan farksızdır. Daha fazla girişimin bunu duyması gerekiyor.

    • Otobüs faktörünü hep ters yönde duydum. “Projenin ilerlemeye devam edemeyecek hale gelmesi için kaç kişinin otobüs çarpması gerekir?” şeklindeydi ve optimum değerin ekip üyesi sayısına eşit olduğunu sanıyordum.
      Aynı kavramdan söz ediyor gibi görünsek de, sayının her zaman aynı yönde kullanılmaması şaşırtıcı.
    • Belirli bir teknolojiye sahip insan sayısının dünyada bir elin parmaklarını geçmediği bir projede çalıştım. O noktadaki otobüs faktörü kesinlikle 1’di.
      Olasılığın sınırlarını zorlayan projelerde basitlik bazen bir seçenek değildir. Elbette bu, tüm yazılım projeleri içinde küçük bir orandır, ama daha önce yapılmamış bir şeyi yaparken asıl kaygı çoğu zaman kodu olabildiğince basit tutmak değil, “bunu nasıl başaracağız?” olur.
      Bu, kod kalitesinin düşük olabileceği anlamına gelmez. Sadece bazen zor işleri yapmak için karmaşık kod gerekir ve ancak birkaç nesil sonra tasarım kalıpları oturur da aynı zor işi daha az karmaşık kodla yapmak mümkün hale gelir. Bu, 10 yıl sonra bile olabilir.
    • Eğer ilk günden herkesin anlayabileceği ve alan bilgisi bile gerektirmeyen şeyler yapıyorsanız, o ürünün ya da ekibin değer önerisi nedir?
      Yapabileceğiniz en karmaşık şey bir yapılacaklar uygulamasıysa, bunun topluma çok fazla değer üretmediğini düşünürüm.
    • İşini iyi yapan ve kendine güvenen insanlar kendi otobüs faktörlerini aktif olarak düşürmeye çalışır.
      Otobüs faktörünüzün yüksek olması, işvereninizin sizi gelecekteki potansiyeliniz için değil, geçmişte yaptıklarınız nedeniyle elinde tuttuğu anlamına gelir.
    • Ordu böyle düşünür. İnsan kaybedildiğinde de işlemeye devam etmesi gerektiğini varsayar.

  • Orijinal makalenin temel tezi şu bölümde yatıyor:
    “Tahminimiz kapsama varsayımına dayanıyor. Mevcut yazar kümesi, sistemin mevcut dosya kümesinin %50’sinden daha azını kapsıyorsa, sistemin ciddi gecikmeler yaşaması veya durması olasılığı yüksektir.”
    Burada bir dosyanın yazarı, önceden hesaplanmış ağırlıklara göre o dosyaya anlamlı katkı yapmış kullanıcı olarak tanımlanır.

  • Bir yandan, bu tür dashboard metrikleri bir tür kurumsal yazılımın içinde zaten yoksa buna daha çok şaşırırdım. Eski şirketimde yöneticiler gerçekten de bölümde en çok e-posta gönderip alan kişinin kim olduğunu gösteren bir günlük rapor üretip üretemeyeceğimizi sormuştu.
    Bunun nereye varacağını sevmediğim için reddettim, ama başka bir iş arkadaşım yaptı. Tahmin edileceği gibi en çok e-posta alıp gönderen kişi sistem yöneticisiydi; çünkü çeşitli sunucuların otomatik e-posta göndericisi olarak onun hesabı ayarlanmıştı. Günde yüzlerce uyarı e-postasını kendisine gönderiyordu; üstüne bir de abone olduğu bültenler ve özet e-postaları vardı.
    Öte yandan, iş arkadaşlarınız hep birlikte işlerini etkileyebilecek bir şey yapmamanızı istemesine rağmen bunu hobi projesi olarak zorlamak oldukça kötüce geliyor.

    • 2015’te iş arkadaşlarım yapma dediğinde bunu yapmadım.
      Sadece kullandığım açık kaynak yazılımın, yaşayabilirliğini artıracak kadar bilgiyi iyi dağıtıp dağıtmadığını görmek istiyorum.
      O kötü davranışı yapmayı reddettim.
    • Saçma bir metrik.

  • “Kariyer basamaklarında yükseldikçe geliştiricilerin doğrudan klavyede yazmayı azaltıp daha çok review yapması gerekir” fikrinin teknoloji şirketlerinde yaygın bir yanlış anlama olduğunu düşünüyorum.
    Yapmak istediğiniz şey harika bir geliştiriciyi sıradan bir yöneticiye dönüştürmek değil.

    • Evet. Kod yazma konusunda müthiş olan teknik liderler var, ama liderlik ya da geri bildirim gibi becerileri korkunç.
      Teknik lider olmaktansa kıdemli geliştirici olarak kalmaları çok daha iyi olur. Yönetici olurlarsa ekibin ne kadar zorlanacağını hayal etmek zor değil.
    • Kod review’yu “yönetim” olarak görüyorsanız, bu ciddi biçimde endişe verici.

  • Bu işin hüzünlü ironisi, sorunun hâlâ yanlış olmasıdır
    Bir startup’ın toplu işten çıkarma yapması gerektiğinde sorulacak soru, “Kimi işten çıkarırsak mevcut işi sürdürebiliriz?” değil, “Batmayacak kadar hızlı biçimde ürünün bir sonraki sürümünü geliştirecek ekip kim?” olmalıdır
    Sonuçta her yol ayrımı bir yol ayrımıdır ve yeterince hızlı karar veremediği için ölen çok şirket vardır

  • CPAN uzun zamandır bus factor’ı takip ediyor. Örneğin https://metacpan.org/pod/Moose sol taraftaki bilgi sütununda Bus Factor 5 gösteriyor

  • Biz buna lotarya faktörü demeyi seviyoruz
    Yani birisi lotaryayı kazanıp elektrik ya da telekom altyapısı bile olmayan tropik bir adaya gitse bile proje devam edebilir mi demek
    Böyle söyleyince daha az ürkütücü oluyor

    • Lotaryayı kazanan kişi iki hafta önceden istifa bildirimini verir ve gerçekten gerekirse sonradan telefon da edebilir
      Otobüs çarpan kişi ise anında ortadan kaybolur. Aynı şey değil
    • İyi bir çalışan, projesini devretmeye ve soruları yanıtlamaya çalışır; ama bunun mümkün olmadığı durumlara da hazırlıklı olmak gerekir
    • İş değiştirmeyi sudden death diye yumuşatmak pek iyi bir tat bırakmıyor
      Spor mecazlarından hoşlanmayanlar da var ama en azından askerî mecazlardan daha iyi olduğunu düşünüyorum
      Zaten çoğu zaman düzgün bir devir teslim de olmuyor, bu yüzden ani oluşu başlı başına o kadar önemli bir unsur olmayabilir
    • Otobüsün çarptığı taraf olmak daha kolay olabilir, dolayısıyla bu ihtimali de hesaba katmak gerekir
    • Büyük lotaryayı kazananı ya da otobüs çarpanı bilmiyorum ama kripto zengini olup işi bırakan birkaç kişi tanıyorum