İş Yerinde Hiçbir Şey Yapmamak

 (seangoedecke.com)
5 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yazılım mühendislerinin performansı, daha fazla zaman veya daha fazla koddan ziyade doğru andaki yüksek etkili işlere bağlıdır; normalde günün yaklaşık %20’sini bilgisayardan uzakta geçirerek %80 kullanım düzeyinde kalmak etkilidir
  • Büyük mühendislik organizasyonlarında büyük sözleşme desteği, olay hafifletme, önemli özellik lansmanları gibi zamana bağlı fırsatlar büyük değer yaratabilir; zaten meşgulseniz bu fırsatları kaçırmak kolaydır
  • Düşük öncelikli ticket’ları sürekli kapatmak, diğer ekiplerin durumunu, ekip güncellemelerini ve devam eden olayları görmeyi engeller; yöneticilerin de sizi zamanı olan biri olarak değerlendirmesini zorlaştırır
  • Hiçbir şey yapmamak için ayrılan zaman, stresten toparlanmayı, olay müdahalesinde sakin kalmayı, yeni fikirler üretmeyi ve önemli işler için odaklanmayı mümkün kılar
  • Normal zamanlarda bilinçli olarak kapasite bırakıp yalnızca ödülün çok büyük olduğu dönemlerde %100 yoğunlukla çalışmak, yüksek performanslı bir mühendis olmayı daha kolay hale getirir

Yüksek etkili fırsatlar

  • Birçok mühendis daha az çalışmalıdır; bu, daha az kod yazmak ya da daha az değişiklik yapmak değil, gün içinde gerçekten çalışılan süreyi azaltmak ve çalışırken de daha yavaş bir tempoda ilerlemek anlamına gelir
  • Varsayılan durumda hedef %80 kullanım oranı olmalıdır; yüksek baskılı bir proje yokken çalışma zamanının %20’si bilgisayardan uzakta geçirilmelidir
  • Teknoloji şirketlerindeki sonuçlar büyük ölçüde alışılmadık olaylar tarafından belirlenir ve en büyük etkiyi yaratan değişikliklerin çoğu şaşırtıcı derecede az emekle yapılabilir
  • Yazılım geliştirmede çabanın kendisine puan verilmez; önemli olan doğru problemi doğru zamanda çözmektir

  • Büyük organizasyonlarda mümkün olan üç örnek

    • Büyük bir kurumsal sözleşme imzalanmak üzereyken bir özellik ya da hata düzeltmesiyle destek vermek, anlaşmanın kapanmasına yardımcı olabilir
    • Özelliğin mükemmel olması gerekmez; bazen belirli bir değişikliği yapma isteği ve yeteneği göstermek bile yeterlidir
    • Bir olayı erken önlemek veya hafifletmek, olay sırasında oluşan anlık gelir kaybını ve sonrasında müşteri kaybı ya da sözleşme reddi nedeniyle yaşanacak gelir kaybını azaltabilir
    • Doğru feature flag’in kapatılması gerektiğini bilmek bile büyük miktarda para tasarrufu sağlayabilir
    • Şirket önemli bir özelliği yayımlamak üzereyken başarı ile başarısızlık arasındaki fark, küçük ama bulunması zor bir değişikliğe bağlı olabilir
    • Kullanıcı ayarlarına hızla yeni bir alan eklemek veya yıllardır dokunulmamış eski bir kurumsal veri dışa aktarma özelliğini düzeltmek buna örnektir
    • Sisteme aşinalık, birkaç saat sürecek bir değişiklik ile bir hafta sürecek bir değişiklik arasındaki farkı yaratabilir

  • Zaman bağımlılığı

    • Bu fırsatların hepsi zamana bağlıdır; sabah giriş yaptıktan sonra rastgele büyük bir sözleşmeyi çözüme kavuşturamaz, bir olayı hafifletemez ya da önemli bir özelliği hızla üretemezsiniz
    • Doğru yerde ve doğru zamanda olmak tek başına yetmez; aynı zamanda zaten meşgul olmamanız gerekir

Rahat kalmak

  • Düşük öncelikli işleri sürekli yapıp %100 kullanım durumunda kalırsanız, yüksek etkili iş fırsatlarını iki şekilde kaçırırsınız
  • Birincisi, fazla meşgulseniz fırsatın kendisini fark etmezsiniz
    • Başka işler yapan insanlarla konuşmaya, ekip güncellemelerini okumaya veya devam eden olaylara bakmaya daha az zaman kalır
    • Yüksek etkili işlere katılmanın en iyi yolu, uzmanlığınızı gönüllü olarak sunmaktır
  • İkincisi, sürekli meşgul görünürseniz yöneticinizin sizi dahil etmesi zorlaşır
    • Bir yönetici ya da ürün yöneticisinin “burada yardımcı olmaya vakti var” diye düşünüp sizi bağlaması, katılmanın ikinci en iyi yoludur
    • Yöneticiler ve ürün yöneticileri, mühendislerin katılmadığı toplantılara girdikleri için hangi yüksek etkili işlerin yürüdüğünü çoğu zaman daha iyi bilir

Hiçbir şey yapmamak

  • Yüksek etkili işler için zaman boşaltmanız gerekiyorsa ve sadece ticket kapatmaya devam etmemeniz gerekiyorsa, dakika bazında gerçekten hiçbir şey yapmıyor olabilirsiniz
  • Yazılım mühendisliği stresli bir iş olabilir, ancak genellikle sürekli yüksek stresli bir iş değildir
    • Stres daha çok ara sıra yaşanan olaylar, acil yüksek baskılı işler veya yakın zamandaki işten çıkarmalar gibi durumlarda ortaya çıkar
  • Görece düşük baskılı iş dönemlerine bile acil durum yoğunluğuyla yaklaşırsanız, yüksek baskılı bir durumu yönetmeniz gerektiğinde zaten yorgun ve gergin olursunuz
  • Yüksek baskılı iş dönemlerinde bile hiçbir şey yapmama tutumu faydalı olabilir
    • On-call’a alışık olmayan mühendisler acele etmemeli; görüşmeye girmeden ya da konuşmadan önce birkaç kez nefes almak daha iyidir
    • Olay müdahalesinde genel olarak “yavaş hareket ederek düşünmek” gerekir
  • Olayların çoğu kendiliğinden çözülür ve olay sırasında aceleyle devreye alınan “belki yardımcı olur” değişiklikleri, durumu iyileştirmekten çok kötüleştirir
  • Genel olarak panikten kaçınmak bile olay müdahalesinde çoğu mühendisten daha iyi performans göstermek anlamına gelir
  • Hiçbir şey yapmamak için ayrılan zaman, işlerin ortaya çıkabileceği bir alan yaratır
    • Beyin dinlenme fırsatı bulduğunda yeni fikirlerin ortaya çıkma olasılığı artar
    • Önemli bir iş verildiğinde arka planda devam eden üç işi aynı anda taşımak yerine tamamen odaklanabilirsiniz
    • Meşgul olmadığınızda sadece etrafınızdaki şeylere bakmak ve yeni verileri almak için zamanınız olur

Belirli işleri bilerek yapmamak

  • Birçok mühendis, yapılacak bir iş gördüğü halde onu yapmama durumundan rahatsız olur
  • Bu eğilim, birçok yazılım mühendisinin paylaştığı psikolojik bir özelliktir ve belli ölçüde bu işe uygun olmalarını sağlayan etkenlerden biridir
  • Hiçbir şey yapmamak için zaman yaratmak istiyorsanız, bazen bilerek araya girmemek için kendinizi zorlamanız gerekir

  • Glue işinden kaçınmak

    • Mühendisler genel olarak glue işinden kaçınmalıdır
    • Glue işi; insanları birbiriyle konuşturmak, liderliğini yapmadığınız işlerin dokümantasyonunu güncellemek veya teknik borç çözümü için kaynak bulmak gibi işleri ifade eder
    • Çoğu glue işi, organizasyonun bu işi açıkça önceliklendirmediğini yansıtır
    • Organizasyon bunu önceliklendirseydi, bir bireyin gönüllü olması gerekmezdi
    • Organizasyonun önceliklendirmediği bir şeyin gerçekten sorun olmaması durumunda, o işi üstlenmek zaman kaybıdır ve yöneticiyi rahatsız edebilir
    • Organizasyonun önceliklendirmediği şey büyük bir hata olsa bile, bunu bireyin telafi etmesi şirketin kendi hatasının sonuçlarını yaşamamasına yol açar ve bedeli kişinin kariyeri ile zihinsel iyiliği öder
    • Bu hem kişi için kötü bir anlaşmadır, hem junior çalışma arkadaşları için kötü bir örnektir, hem de burnout sonrasında başka birinin aynı role girmesi için kötü bir emsal oluşturur
    • Sonuç gerçekten ciddiyse, organizasyonun acı çekmesini ve politikasını değiştirmesini sağlayacak sonuçların yaşanmasına izin vermek gerekir

  • Aşırı yardımseverlik kırılganlık yaratır

    • Fazla yardımsever olmak, sizden karşılıksız emek çıkarmaya çalışan insanlara karşı sizi savunmasız bırakır
    • Teknoloji şirketlerinde, yazılım mühendislerinden karşılığı ödenmeyen iş çıkarmaya çalışan çok kişi vardır
    • Bu, normal yoldan gelen ve terfi, prim veya genel maaşla karşılığı verilen işlerden farklıdır
    • Sorunlu işler gayriresmî kanallardan gelir ve o işi resmî olarak kendi adına kaydetme becerisi ya da isteği olmayan kişilerden çıkar
    • Başka bir organizasyondaki bir ürün yöneticisinin veri sorgularında iyi olduğunuzu söyleyip sizden belirli istatistikleri çıkarmanızı istemesi buna örnektir
    • Başka bir ekipten bir mühendisin pair çalışması istemesi ama gerçekte tüm kodu size yazdırıp değişikliği kendi adıyla göndermesi de buna örnektir
    • Bu tür işlerden bir miktar yapmakta sorun yoktur; mümkün olduğunda insanlara yardımcı olabilirsiniz
    • Ancak reddedebilmeniz ya da birkaç saat veya birkaç gün geç yanıt vererek geri baskı uygulayabilmeniz gerekir

  • Ortadan kaybolma ihtimali yüksek işlere aşırı yatırım yapmamak

    • Yakında ortadan kalkma ihtimali yüksek işlere çok fazla yatırım yapmamak daha iyidir
    • Ürün tasarımcısının ne istediğini gerçek zamanlı olarak netleştirdiği bir durumda, her saat sayfayı baştan sona yeniden yazmamalısınız
    • Sabah 9’da sayfa başlığını bir şekilde istemesi, 10’da değiştirmesi, 11’de tekrar başka bir şeye çevirmesi buna örnektir
    • Böyle durumlarda yürüyüşe çıkmak gibi hiçbir şey yapmamak, sonra öğleden sonra en güncel tasarıma göre sayfayı bir kez yeniden yazmak daha iyidir
    • Siyasi itiş gücü zayıf bir yöneticinin büyük fikri de yaygın bir örnektir
    • Çoğu zaman proje iptal edilene kadar zamanın akmasına izin verebilirsiniz
    • Ancak projenin siyasi desteğini yanlış değerlendirirseniz tembel biri gibi görünebilir ve sonra sonucu aceleyle çıkarmanız gerekebilir

Sonuç

  • Yazılım mühendisliği tavsiyeleri ve araçları çoğu zaman aynı anda daha fazla iş yapmak, daha geniş kapsamlı projeler almak ve daha fazla kod yazmak için teknik çabayı büyütme becerisine odaklanır
  • Yazılım mühendisliğinde başarı bunlarla belirlenmez
  • Başarı, doğru şeyi doğru zamanda yapabilme becerisiyle belirlenir ve bunun için günlük işlerde bilinçli olarak bir miktar eforu saklı tutmak gerekir
  • %80 eforla da yüksek performanslı bir mühendis olmak mümkündür; hatta bu, stresten kaynaklanan aptalca hataları azaltır ve büyük getiri sağlayan yüksek etkili işlere atlamayı kolaylaştırır
  • %100 eforla yüklenmeniz gereken dönemler de vardır; yılda iki ya da üç kez, uzun saatler, güçlü odak ve gün boyu problemi düşünerek çalışabilirsiniz
  • Bu çalışma biçimini gerçekten ödülün büyük olduğu zamanlar için saklamak, geri kalan dönemlerde ise nispeten rahat çalışmak daha iyidir

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Güzel bir yazı, ama sonunda yine sorunun teşvikler olduğu ortaya çıkıyor
    Bir sorunu erken durdurmanın ya da etkisini azaltmanın büyük para tasarrufu sağlayabileceği doğru, ama farklı şirketlerde tekrar tekrar gördüğüm şey şu: sorunları önlemek takdir edilmiyor, ama ortalığı tutuşturacak malzemeyi yığıp kaçınılmaz yangını söndürürsen iki kez takdir görüyorsun. “İyi” organizasyonlarda bile böyleydi
    Kasten çöp kodu hızlıca çıkarıp bunun üzerinden prim toplanan oyun teorisi tarzı siyasete hiçbir zaman tam anlamıyla kendimi veremedim. Çünkü yaptığım işle fazla gurur duyuyordum
    Önceki ürün sürümünü rahatsız eden sorun sınıfını ortadan kaldırmak için bir framework’ü 5 yıldan uzun süre yönettim ve büyüttüm, ama çöp kod deploy edip kesinti yaratıp sonra düzelten partner ekip açıkça övülürken, bizim ekip böyle kesintiler yaşanmadığı için hiçbir paye alamadı. Çünkü bu, ölçülemeyen önleme

    • Oyun teorisine göre, tekrar tekrar sorun çıkarıp müşteri kaybettiren ekiplerin buna uygun şekilde cezalandırılması gerekir. Eğer öyle olmuyorsa, hızlı deploy’dan doğan sorunlar müşteri elde tutma oranını düşünüldüğü kadar etkilemiyor olabilir
    • Oraya buraya Thread.sleep(100000) koyup bir şeyler patlayana kadar beklersin. Sonra da release sonrası cuma gece yarısına kadar uzun ve kahramanca yangın söndürme yapan kişi olursun
      Neden ödüllendirildiğini sormamak gerekir, ama elbette bazen organizasyon ödül ölçütlerini başka bir şeye de çevirebilir
    • “Böyle kesinti yaşanmadığı için takdir alamazsın, çünkü ölçülemez” sözüne karşılık, felsefi olarak hiçliğin ağırlığının da ölçülebileceğini düşünüyorum
    • Ne yazık ki tamamen doğru, ama tek yol bu değil
      Dürüst yaklaşımda, karmaşık ama gerekli birkaç araç geliştirip diğer mühendislerin sürekli sana gelmesini sağlayabilirsin. Belirli bir aracın yanlış kullanımını iyi fark etmeye başlar ve başkalarının kodundaki bug’ları birkaç saniyede işaret ettiğinde gerçekte olduğundan çok daha zeki görünürsün
      İdeal olarak araç güvenilir ve faydalı ama karmaşık olmalı. Diğer geliştiriciler aracı kullanırken bir bug’la karşılaştıkça sana gelmeye devam eder ve sen de onların hatalarını gösterebilirsin. Bu stratejinin işlemesi için hatanın neredeyse her zaman karşı tarafta olması ve kodunun sağlam olması gerekir
      Kendi kodunda gerçek bir bug, mümkünse küçük bir köşe vaka bulunursa çok alçakgönüllü ve üzgün olmalı, ekip toplantısında da o karmaşık bug’ı bulan geliştiriciyi övmelisin
      Kendi bug’lı kodunu düzeltip bununla kredi toplamaktan daha iyi bir yöntem. O yol yöneticilere ya da junior’lara işe yarayabilir ama diğer senior mühendisler bundan hoşlanmaz
      Karmaşık ama kararlı araçlar üretme yöntemi, tekrar tekrar ve çoğu zaman iki kereden de fazla takdir getirir; diğer geliştiricilerin takdiri de sonunda yöneticilerin kulağına gider. Akıllı liderler bunun gösterişli demolardan daha iyi bir sinyal olduğunu bilir
      Sırf hızlı prototip yapıyor diye belli bir geliştiriciye övgü yağdıran liderler sonunda hatalarını öğrenir. Genç kurucular özellikle yüzeysel şeyleri övdükleri bu aşamadan sık geçiyor gibi görünüyor
    • Meseleyi böyle karşıt kutuplar halinde kurarsan katılırım, ama biraz nüans gerek
      Bir ürün ya da özellik paketini inşa etmenin bir kısmı, mükemmel mühendislikten çok keşif işidir. Bazen tek bir sağlam özellik yapmak yerine, kullanıcı için neyin değerli olduğunu anlamak amacıyla yeterince iyi iki özellik yapmak daha iyidir
      Ben hep “önce deneyelim, sonra görürüz” tarafında oldum. Yine de benim gibi olmayan birinin git’i yapmış olmasına minnettarım
      Burada bir denge var ve şu an uğraştığın problemin ne kadar keşif problemi olduğuna bağlı. Burada “sağlamlık”, saf mühendislik açısından erişilebilirlik, bakım yapılabilirlik ya da kullanıcının hassas fotoğraflarının sızma ihtimali gibi şeyler demek

  • “Karşılığı olmayan işleri senden koparmaya çalışan insanlar” bölümü çerçeveletmelik
    Özellikle başka bir organizasyondan ürün yöneticisinin “Veri sorgularında iyisiniz, X hakkında bazı istatistikler çıkarabilir misiniz?” demesi ya da başka bir ekipten bir mühendisin “pair” isteyip sonunda tüm kodu benim yazmam ve onun da kendi adıyla sessizce değişikliği göndermesi gibi durumlar

    • Çalıştığım yerde Principal Engineer herkesin istediği, iyi ödüllendirilen ama nadiren ulaşılan bir unvan. Birlikte çalıştıklarımın hepsi çok yetkin ve insani olarak da iyiydi; içlerinden birine önceki şirketinde bu unvanı nasıl aldığını sormuştum
      Stratejisi insanlara yardım etmek ve krediyi aktif biçimde başkalarına vermekmiş. Bire bir görüşmelerde ya da çok katmanlı yöneticilerin olduğu toplantılarda ekip arkadaşlarının işinin değerini sürekli vurgulamış ve bu sayede ekibin sevgisini kazanmış
      Birkaç yıl sonra, büyük paranın söz konusu olduğu bir proje takvimden sarktığında ve birkaç kilit mühendis ayrıldığında, gece geç saatlere kadar çalışarak projeyi başarıya ulaştırmış ve sonraki değerlendirmede unvanla maaş artışını almış
      O proje son itici güç olmuş olabilir ama fazla mesai yapan tek mühendis o değildi. Kendi terfisini, görev süresi boyunca başkalarına kredi vererek biriktirdiği iyi niyete bağlıyor
    • Bunun yöneticinin ne kadar dahil olduğuna bağlı olduğunu düşünüyorum. Birlikte çalışmak istemediğim insan tiplerinden biri “Bu benim işim değil” diyenler
      İş tanımında olsun olmasın, bir problem görüp çözüm öneren insanlarla çalışmak isterim
      Yaptığım iş takdir edilmiyorsa bu bir liderlik sorunudur. İşleri keskin biçimde reddetme yaklaşımı bana katılaşmış, yavaş bir organizasyon kültürüne giden yol gibi geliyor
    • Çerçeveletilecek söz “Bunu bir ticket olarak açar mısın”dır
    • Doğru, ama ben buna o kadar siyah-beyaz bakmıyorum. Kendi karşılığımı doğrudan korumanın ötesinde, şirketin başarılı olmasına yardım etme yönünde de teşvikler var; bu yüzden törenle alkışlanmasan bile küçük taleplere yardım etmek mantıklı olabilir
      Aynı şekilde bir gün benim de bir iş arkadaşımdan bir şeye ihtiyacım olabilir ve o zaman “resmi kanaldan gel” diye geri çevrilmek yerine hevesle yardım etmesi hoşuma gider. Resmi kanallar çok daha uzun sürebilir
    • İyi şirketlerde bir kültür vardır ve insanlar birbirine yardım eder
      Öğle yemeğindeki sohbetler bile insanların bir şeyi anlamasına yardımcı olur
      Ama biri için saatler sürecek bir işi yapmak bambaşka bir mesele olabilir

  • Alay etmek için söylemiyorum, daha çok bir gözlem ama yeterince büyük ya da bürokratik organizasyonlarda sorunları önceden engellesen bile bunun için takdir ya da görünürlük kazanmak zordur. Böyle başarılar “zaten yapılması gereken iş” hanesine yazılır
    Bu yüzden şirket politikasında iyi olan insanlar bazen sorunun çıkmasına izin verip sonra takip aksiyonlarında gürültülü şekilde hareket etmeyi seçer. İşin püf noktası, sorunu bir felakete dönüştürmemektir; bu da epey hassas bir iştir

    • Bunu muhafazakar bir organizasyonda erkenden öğrendim. Önleme tehlikelidir. İşler ters gittiğinde kullanılacak çözümleri hazır tutmak daha iyidir ve onay da ancak o zaman alınabilir
    • Büyük etki yaratan örneklerin hepsi, takdir görmesi zor işler gibi duruyor
      Satış sözleşmesini kurtarırsan alkışı satış ekibi alır, komisyonu da onlar alır. Ben bunun bir kısmını bile almam
    • Bir felaket, üst yönetime organizasyonda bir sorun olduğuna dair iyi bir sinyal de olabilir. Bütün yangınları kahramanca söndürürsen patronun bunu fark edebilir ama patronunun patronunun patronu organizasyonun harika çalıştığını ve her şeyin yeşilde olduğunu sanır
      Birkaç şeyin yanmasına izin verirsen patronunun patronunun patronu o yangını görür ve belki iyileştirme yapılır. Belki de onlarla iletişim kurmanın en kolay yolu budur
    • Kilit nokta, insanların bunu fark edip etmediğidir. Yerel yönetimlerde bazen popüler programlar kesilip tepki yaratıldıktan sonra yeniden geri getirilerek bunun kredisi alınır diye duydum. Bu arada gerekli ama popüler olmayan başka önlemler de araya sıkıştırılabilir
    • Kariyerler ve bonuslar çoğu zaman kahramanlık oyunu üzerinden inşa edilir

  • Eskiden bu yönde yarım kalmış bir yazım vardı; fantastik RPG benzetmesi kullanmıştım. Böyle oyunlarda mana kullanan bir karakter oynarsan, her küçük savaşta tüm manayı harcayıp boş halde dolaşmanın ve gerçekten gerektiğinde elinde hiçbir şey kalmamasının ne kadar kolay olduğunu çabucak öğrenirsin
    İşte kullandığın zihinsel enerji de çok farklı değil. Depoda biraz bırakırsan, beklenmedik bir şey olduğunda bunu sağlığını, yani tükenmişliği riske atmadan stratejik biçimde kullanabilirsin
    Bu tür oyunlarda mana yönetemeyen biriyle aynı partide oynarsan, o kişinin çok da iyi bir takım arkadaşı olmadığını da öğrenirsin

    • Bir süre yeterince zorlanmazsan, bir sonraki zorluğun üstesinden gelmek son derece zorlaşabiliyor; bunu hissettim
      Hangi alan olursa olsun, yeteneğimin zirvede olduğu dönemler önümde yeterince iş olduğunda, makine gibi istikrarlı biçimde iş çıkarabildiğimde ve hedefe doğru engellenmeden çalışacak kadar güven duyulup sürekli açıklama yapmak zorunda kalmadığım zamanlardı. Beceriler yangın gibi artıyor, işler de beklenenden hızlı bitiyordu
      Ne yazık ki bu yapıyı kullanan işyerleri çok nadir. Gerçek anlamda derin çalışmaya girmeyi engelleyen çok fazla bariyer ve dikkat dağıtıcı unsur var
    • Ben olsam RPG’yi bitirdiğimde elimde 29 Ether kalmış olurdu; bunları başta kullansaydım oyun çok daha az grind gerektirirdi

  • Bir sistemi çökertmek istiyorsan, temel işletimi %100 kapasitede çalıştırman yeterli. Hiç pay kalmaz, yeni talebi karşılayacak kapasite de olmaz; bu yüzden sisteme küçük bir bozulma girdiğinde bile kalıcı başarısızlık moduna geçer

    • Verimlilik, dayanıklılığın düşmanıdır
    • Yine de çöküş yaşanmaz. Mühendisler tükenmişliğe girer ya da yaşlanır, sonra yenileri işe alınır ve döngü tekrarlanır
      Bu tür yazıların ya da Peopleware / Slack gibi kitapların sorunu, muhasebecileri farklı bir yaklaşımı denemeye ikna edecek kadar güçlü gerçek metrikler sunmamalarıdır

  • Bakış açımı değiştiren benzetme, “The Power of Full Engagement” kitabından bir sözdü. Kabaca şöyleydi: “Sezon dışı olmayan bir dünya çapında dayanıklılık sporcusu gibi davranıyorsun. Bırak bunu.”

  • Burada çok fazla bilgelik var. Gerçekten yüksek değerli bir iş geldiğinde kullanmak için bir miktar kapasiteyi boş bırakmanın ötesinde, yazılım mühendisliğinin sürekli meşgul kalarak iyi yapılabilecek bir iş olmadığını düşünüyorum
    Kodu olabildiğince hızlı yazmaya çalışınca iyi tasarım çıkması nadirdir. Bu yazı bir başka önemli boyutu ele almıyor: yöneticiden azar işitmeden %80 kapasiteyle nasıl çalışılır
    Bunun için iletişimde ve iş tahminlerinde biraz dikkat gerekir. İlk gerçek programcılık işimde daha yaşlı ve deneyimli geliştiricilerden aldığım iyi bir tavsiye hâlâ aklımda: Bir işin ne kadar süreceğini tahmin et, sonra bunu yöneticiye ya da kullanıcıya söylemeden önce ikiyle çarp
    Deneyim kazandıkça bu oran 2 kat yerine yaklaşık 1,5 kata inebilir ama ilke hâlâ geçerlidir

    • Kent Beck, Good News Factory’de miydi yoksa bir konuşmada mıydı hatırlamıyorum, kendi ekibinin yapabileceğini düşündüğü işin yarısından fazlasını asla taahhüt etmediğini söylemişti. Bu, sürdürülebilirlik açısından iyi bir yaklaşım
      Optimize edilmesi ve örnek alınması gereken şey, uzun vadede istikrarlı biçimde, sürdürülebilir hızla teslimat yapabilmektir. Bu uzun bir oyun ve fazla söz vermek yalnızca güveni aşındırır. Geliştiricilerin ihtiyaç duyduğu alanı kazanmasının en büyük yolu da zaten bu güvendir
      Az söz ver, söylediğini yapacağına dair güven oluştur ve tükenmeden çalışacak alanı kendine aç
      Kıdem arttıkça, özellikle de lider oldukça, sınır koymak, dikkatini korumak ve tükenmişliği önlemek işin bir parçası haline gelir. Çünkü insanın kendini mahvetmesinin çok fazla yolu vardır
    • “Süre tahminini ikiyle çarpıp yöneticiye ya da kullanıcıya öyle söyle” tavsiyesi doğru, ama Hofstadter yasası hesaba katıldı mı merak ediyorum
      Hofstadter yasasını hesaba katsan bile işler her zaman beklenenden uzun sürer
      https://en.wikipedia.org/wiki/Hofstadter%27s_law

  • Müşteriyle doğrudan temas edilen işlerde çok bulunmuş biri olarak, defalarca karşılaştığım en kötü tuzaklardan biri parayı ödeyen müşteriyle yakınlaşmaktı. Yardım etmesi için tutulmuş bir uzman olarak, müşteri gerçekten iyi biriyse hayır demek delice zorlaşıyor
    Daha kötüsü, o kişi karar verici değilse ve bana bir şeyi kabul ettirmek için baskı görüyorsa. Güvenilen bir uzman olarak müşterinin kendisi kötü bir fikirle gelirse hayır demek kolay, ama hiç doğrudan muhatap olmadığım patronu talimat verirse kendimi ya işe yaramaz bir maliyet gibi görüyorum ya da arkasında bir canavar bırakıp giden bir evetçi konumuna düşüyorum
    Çoğunlukla kurum içi işlerde çalışmış insanları bazen kıskanıyorum. En azından yukarıda bir yerlerde birilerini ikna etme şansları vardı

  • Glue work ile ilgili bölüm ilginç; büyük bir şirkette çalışırken bu, yıllık performans değerlendirmesinin açık bir parçasıydı. Google buna “citizenship” diyordu ve bence bu, meseleyi iyi yakalayan bir ifadeydi. Yani, “şirketteki diğer herkes için neyi daha iyi hale getirdin” demekti
    Bir yandan biraz tuhaftı. İş tanımımda yoktu, yani teknik olarak karşılıksız bir işti, ama aynı zamanda resmî beklentilerin de bir parçasıydı. Öte yandan, herkesin biraz zaman ve emek harcayıp ortamı herkes için iyileştirdiği bir yerde çalışmak güzeldi
    Bunu herkes için açık bir gereklilik haline getirmek, “Ben rockstar mühendisim, önemli işler yapmakla meşgulüm, glue work'ü başkası yapsın” şeklindeki toksik kültürü aşma girişimi de oluyordu. Üstelik o “başkası” genelde bir kadındı ve neredeyse kesin olarak o rockstar mühendisten daha az maaş alıyordu
    Asıl yazı, şirketin glue work yapacak birini resmen işe alması gerektiği imasını veriyor, ama gerçekte bu işler o kadar çeşitli parçalardan oluşuyor ki bunu tek bir kişiye vermek neredeyse imkânsız. Mesela “dokümantasyon yazımı, yazılım mühendisi mülakatları, ekip offsite etkinliklerini organize etme” işlerinin hepsini kapsayan unvan ne olurdu ki
    Ama bu işlerin hepsi gerekliydi ve citizenship beklentisi yükün daha adil paylaşılmasını sağlıyordu
    Bence daha iyi ifade “glue work yapmayın” değil, “karşılıksız glue work yapan tek enayi olmayın” olurdu. Yani herkes bir kısmını üstlenmeli ve bunun resmen iş olarak kabul edildiği bir kültür desteklenmeli

  • %80 kullanım oranıyla çalışmak iyi bir alışkanlık ve her gün tam gün %100 talep eden nezaretçi tarzı bir yönetici olmadığında işe yarıyor. Böyle insanlar, yazılım mühendisinin sessiz ve rahat biçimde düşünmesini tembelce boş durmak sanıyor
    Bu yüzden uzaktan çalışma, bir miktar kapasiteyi yedekte bırakıp ruh sağlığını korumanın en iyi yolu
    Biraz glue work, herkesin iş hayatını çok daha iyi hale getiriyorsa ve bunu nasıl yapacağını kimse bilmiyorsa, ekip içinde beni vazgeçilmez biri ya da bir kahraman haline getirebilir

    • Bence %80 bile yüksek. Üstelik geliştiriciden geliştiriciye değişir
      Benim öğrenme, düşünme ve işe başlama konusunda zorlanma biçimimi hesaba katarsak, benim %80'im teknik olarak daha güçlü bir meslektaşın %80'iyle hiç aynı değil
      Nöroçeşitlilik özellikleri biraz olsun hesaba katılırsa, bir kişinin 80'i başka birinin 120'si olabilir