Bildiğim En Kötü Programcı
(dannorth.net)- Bir Big Bank danışmanlık ekibi, bireysel üretkenliği tamamlanan story/story point ile ölçmeye çalıştı; Tim Mackinnon bu metrikte tekrar tekrar 0 puan aldı
- Puanının 0 olmasının nedeni çalışmaması değil, story’leri kendi adına almaması ve gününün büyük bölümünü pair programming ile geçirmesiydi
- Daha az deneyimli geliştiricilere doğrudan cevap vermek yerine Sokratik sorularla öğrenme fırsatları yarattı; senior geliştiricilerle ise farklı bakış açılarını bir araya getirerek daha iyi çözümleri birlikte buldu
- Tim ekibe katıldığında ekip daha etkili, üretken ve hizalı biçimde çalışıyordu; yönetici sonunda Tim’i ekipte tutup bireysel üretkenlik metriğini sessizce rafa kaldırdı
- Bireysel katkıyı ayrı ayrı ölçmeye çalışmak, Tim gibi katkıları 0 gösterebilir; bu yüzden üretkenliğe iş etkisi ve ekip düzeyindeki akış üzerinden bakmak gerekir
Bireysel metriklerin yarattığı “0 puanlık programcı”
- Big Bank’teki bir ekip, bireysel performans değerlendirmesi ve gelişim amaçları için kişiye özel performans metrikleri uygulamaya koydu
- Yönetici, kod satırı sayısı veya hata sayısı gibi kolayca manipüle edilebilecek metriklerden kaçındı; iş değerini temsil ettiği gerekçesiyle tamamlanan story’leri veya story point’leri ölçmeyi seçti
- Jira benzeri bir araçta herkes story’lere adını yazdığı için kişi bazında üretkenlik metrikleri oluşturmak kolaydı
- Tim Mackinnon’ın puanı düşük değil, her hafta ve her iterasyonda kelimenin tam anlamıyla 0 puandı
- Yönetici, Tim’in ekipten çıkarılıp story’leri gerçekten “teslim eden” biriyle değiştirilmesi gerektiğini düşündü; ancak ekip lideri bunu reddetti
Tim’in gerçekte teslim ettiği şey
- Tim story’leri kendi adına üstlenmiyor, bunun yerine her gün farklı bir ekip üyesiyle eşleşerek çalışıyordu
- Daha az deneyimli geliştiricilerle çalışırken direksiyona onların geçmesine izin veriyor ve onları nazikçe çözüme yönlendiriyordu
- Cevabı dayatmıyor veya bastırmıyordu
- “what if”, “how else” gibi sorularla ve Socratic questions ile öğrenme anları yaratıyordu
- Senior geliştiricilerle, ortak üretime veya sparring’e yakın bir şekilde çalışıyor; farklı dünya görüşlerini probleme uygulayarak tek başlarına akla gelmesi zor sonuçlar ortaya çıkarıyorlardı
- Tim doğrudan yazılım teslim etmekten çok, yazılım teslim eden ekibi büyütüyordu
- Ekip genel olarak daha etkili ve üretken hareket ediyordu
- Daha iyi hizalanmış ve daha hoşgörülü bir şekilde çalışıyordu
- Birlikte çalışma deneyimi de daha keyifli hale geliyordu
- Yönetici ekibi gözlemlemeye geldiğinde Tim her zaman başka biriyle birlikte “o kişinin işi” üzerinde çalışıyordu; bunun sonucunda çıktının kalitesi artıyor ve değer teslim süresi kısalıyordu
- Sonunda ekip Tim’i tuttu ve bireysel üretkenlik metrikleri yerine ekip sorumluluğunu seçti
- Yüksek performanslı bir birim olarak kuruma teslim ettikleri iş etkisini takip edip kutladılar
Üretkenlikte nereye bakmalı?
- Üretkenliği ölçmek gereklidir; sorumluluk sahibi olmak için ideal olan ölçülebilir iş etkisidir
- Tasarruf edilen tutar
- Yaratılan tutar
- Korunan tutar
- Doğrudan iş etkisini ölçmek zorsa, iş için vekil metrikler de kullanılabilir
- Karmaşık uyarlanabilir sistemlerde, tek bir kişinin katkısını ayrı biçimde ölçme varsayımı en baştan sarsılır
- DORA metrikleri, tek tek pistonların katkısını değil iş sisteminin nasıl çalıştığını ölçer
- Westrum kültür göstergesi olarak görülebilir
- Teknik değişikliklerin prodüksiyona nasıl aktığını gösteren metrikler olarak da görülebilir
- Bireysel metrikler Tim gibi kişilerin gerçek katkısını 0 gösterebilir; ekip düzeyindeki performansa ve sistem seviyesindeki akışa bakmak daha uygundur
1 yorum
Hacker News yorumları
Yaklaşık 20 yıl önce Mac ve Windows için masaüstü uygulamaları satan orta ölçekli bir yazılım şirketinde çalışıyordum; ekibin çoğu yalnızca Mac deneyimine sahipti ve Windows'u yeni öğrenme aşamasındaydı, bu yüzden Windows sürümünde çok sorun vardı.
O dönem Windows uzmanı olarak biliniyordum; bu sürümü iyileştirmek ve ekibin Windows programlamaya alışmasına yardımcı olmak için işe alındım.
Günün ilk kısmını çoğunlukla “ev ziyareti” yapar gibi diğer geliştiricilerin odalarını dolaşarak pair programming, hata inceleme ve Windows API en iyi uygulamalarını tartışarak geçiriyordum; daha sonra bir meslektaşım “nasıl bu kadar bol zaman ayırabiliyorsun?” diye sordu.
Birkaç ay sonra değerlendirmede “üretkenliğinin beklendiği kadar olmadığı, özellikle de ekibin geri kalanının üretkenliğinin son dönemde arttığı dikkate alındığında bunun böyle olduğu” yorumunu aldım; oysa beni işe almalarının nedeninin tam da bu olduğunu sanıyordum.
Bilgi paylaşımı, başka bir geliştiriciye sağlayabileceğiniz en büyük fayda; ama bu yolu seçenler çok az ödüllendiriliyor.
Böyle geliştiriciler olmasaydı bugünkü yazılım dünyasına yaklaşamazdık bile; doğrudan teşekkür almasalar da kesinlikle değerliler.
Tüm tamir işlerinin önceliği aynıydı ama zorlukları farklıydı; bir ay boyunca öğrenip kimsenin de yapmak istemediği için baz istasyonu tamirini üstlendim. Daha uzun sürüyordu ama operasyon için çok daha kritikti.
Ay sonu toplantısında kullanım oranı pasta grafiği gösterildi ve ben deneyimli kıdemlilerden çok daha kötü görünüyordum.
O zaman kıdemlilerin neden hızlı ve kolay işleri seçtiğini ve şirket içi politikanın varlığını öğrendim; berbat bir yöneticiyi kariyerimin başında yaşamış olmak aslında şanstı.
Yeni yöneticim ilk değerlendirmede aslında bir performans iyileştirme planı hazırladığını, ama açık ofise taşındıktan sonra yardım almak için bana sıraya giren insanları ve hiç kimseyi geri çevirmediğimi görünce bunu çöpe attığını itiraf etti.
Bölmeli masamı kaybetmek biraz can sıkıcıydı ama bu olay sayesinde açık ofise olumlu bakmaya başladım.
Elbette artık hiçbir ofiste çalışmıyorum ve uzaktan çalışma olmayan bir işi yeniden kabul etmeyi düşünmüyorum.
Ancak önce itibar oluştuktan sonra bir şeyleri değiştirebilirsiniz; ondan önce zordur.
Çok fazla kişi “ekip” için optimize etmeye çalışırken üst yönetimin olumsuz algısı yüzünden işten çıkarıldı ya da terfide geri bırakıldı; buna karşılık şirketin o an önem verdiği ölçütlerde iyi bir itibar kazanan kişilerin epey uzun süre kötü davranışlarına bile göz yumulabiliyor.
Hemen daha iyi bir yere mi gitti, şirketin performans metriklerine uyup zamanını başkalarıyla daha az mı paylaşmaya başladı, yoksa organizasyon şemasında yeterince üst düzeyde birine gerçekten bu rol için işe alındığını ikna mı etti, merak ediyorum.
Bell Labs anekdotu aklıma geliyor.
Birisi patent sayısı gibi ölçütlerle en üretken çalışanları hesaplamış ve bunların çoğunun aynı kişiyle öğle yemeği yediğini keşfetmiş.
O kişinin kendi bireysel üretkenliği yüksek değildi ama sürekli derinlikli ve ikna edici sorular sorarak meslektaşlarını ölçülebilir biçimde daha üretken hâle getiriyordu.
Bell Labs'in patent departmanındaki avukatlar, bazı insanların neden daha üretken olduğunu açıklayacak örgütsel bir ilke bulmaya çalışıyordu; ortak nokta ise çok patenti olan çalışanların elektrik mühendisi Harry Nyquist ile sık sık öğle ya da sabah yemeği yemesiydi.
Nyquist onlara somut fikirler vermiyordu; insanları konuşmaya ve düşünmeye yöneltiyor, en önemlisi de iyi sorular soruyordu.
İnsan toplulukları hassas yapılardır; iyi bir ekip atmosferi ve iyi sorular, görünmez biçimde durumu iyileştirebilir.
Aksi hâlde adil ücret almaları zor.
Ben inanmıyorum.
Birkaç yıl çalıştığım şirkette haftada 10 puan üretemeyenler performans iyileştirme kapsamına alınıyordu; junior ya da senior olmanız fark etmiyordu.
Birkaç ekipten geçtim; bir ekibin puanları nasıl ölçtüğünü, geliştiricilerin stres seviyesine bakarak hemen anlayabiliyordunuz.
İyi niyetle puan ölçmeye çalışan ekip stres altındaydı, çoğunda tükenmişlik belirtileri vardı ve haftada 60 saat çalışıyorlardı.
Buna karşılık sistemi bir oyun gibi ele alıp bunun imkânsız bir görev olduğunu anlayan ekipler, ticket’lara mümkün olduğunca yüksek puan veriyor ya da işleri küçük ticket’lara bölüp sürekli puan biriktiriyordu; stressiz ve mutluydular.
Böyle bir ortamda kurallara göre oynamak enayi stratejisiydi; ben sonunda ayrılınca şirketin 7 senior mühendisi de 4 ay içinde peşimden çıktı.
Büyük belirsizlik ve risk taşıyan hikâyeler yerine, düzenli biçimde ve stres yaratmadan tamamlanabilecek hikâyelere bölmek hedeflenir.
O iş yerinin iyi göründüğü anlamına gelmez, ama sistemi oyunlaştırdığını düşündüğümüz geliştiriciler genel olarak Scrum’ın teşvik etmeye çalıştığı şekilde hareket etmiş gibi görünüyor.
Ancak haftalık minimum puan dayatıp puan şişirmeyi teşvik etmek berbat yönetimdir.
Çünkü baskı uygulamadığında aynı kişilerden alabileceğinden daha fazla iş çıkardı.
Eski yöneticim bir projeyi bitirmek için açıkça “insanları işe alıp yakıp tükettiğini” söylerdi; planı, 6 ay işe yarar şekilde çalışmalarıydı.
Stresi ve düşük ücreti göze alıp kalırlarsa şirket açısından bonus gibi görülüyordu; ben de çok uzun dayanmadım.
O hafta bitiremediysen ticket tamamlandı diye kapatılır, kalan iş de bug olarak yeniden açılırdı.
“Bir ölçüt hedef hâline geldiği anda, iyi bir ölçüt olmaktan çıkar.”
Bazı yerlerde hedefe yönelik saf üretkenlikten çok, yöneticinin ne bekleyebileceğini bilmesi daha önemliydi.
İyi niyet varsayanlar yönetimin de iyi niyetle davrandığını düşünmüş olabilir; ama birçok proje temennilerle oluşturulur ya da insanları “motive etmek” için yapay olarak kısa son tarihler konur.
O stres, yöneticinin duygusal tatmini dışında pek değer üretmemiş olabilir.
Yazılım mühendisinin performansını teknik olmayan biri değerlendirirse dramatik sonuçlar çıkabilir.
Arkadaşım “Tommy” ağ konusunda çok yetkin bir IT sorumlusuydu; devlete ait bir enerji şirketine geçtikten birkaç hafta sonra, genel merkezdeki tüm binalar dâhil ağı modern ekipmanla baştan kurması gerekti.
Şirket işi dışarıya vermek istiyordu, ama finans departmanının çıkardığı maliyeti görünce Tommy şaşırdı; router, switch, kablo gibi fiziksel ekipmanlar ve kablolamayı yapacak 2 kişi olursa bunu kendisinin yapabileceğini söyledi.
Birkaç hafta içinde işi ilk bütçenin onda birinden bile az maliyetle bitirdi, ama aldığı tek şey yöneticisinin sözlü “teşekkürler, iyi iş çıkardın” demesiydi.
Yöneticilerin eski kafalı olup gerçek değeri anlamadığı dönemlerin IT çalışanı olmak gerçekten buruk.
Sonrasında Tommy yüklenici olarak girip ek ücret alabilirdi.
Birlikte çalıştığım gerçekten çok iyi bir geliştirici hem harika kod yazardı hem de hemen çöpe atılması gereken korkunç kodlar yazardı; ikisi de onunla çalışmayı iyi kılan unsurlardı.
İyi kodun değerini açıklamaya gerek yok; muhtemelen hâlâ onun kodunu kullanıyor olabilirsiniz.
Ama acil durumlarda da olağanüstüydü.
Müşteri tamamen durmuşken ve hata bizde olabilecek bir durumda hemen ortaya çıkar, sorunu hızla kavrar ve müşteriyi yeniden çalışır hâle getirecek kirli spagetti kodu hızla yazıp kurardı.
Check-in yapılamayacak, refactor edilemeyecek, göz kanatan bir koddu; ama biri daha sonra düzgünce düzeltene kadar o anki kriz atlatılırdı.
Ben asıl bu ikinci yeteneğine daha çok hayrandım; her şeyden önce nadir bir beceriydi ve o da zaten iyi bir insandı, herkes onu severdi.
Yine de işleri hızlı bitiriyorum; tuhaf kodum acil durumları çözdü ya da ihaleleri kazandırdı, birçok kez günü kurtardı.
“Mükemmeliyetçi” geliştiricilerle iletişim kurmak zor; onlara göre kod yeterince tasarlanmamışsa, hızın gerekli olduğunu anlasalar bile değerli görünmüyor.
Elbette onlar da benim hakkımda tersini düşünüyordur.
Şimdi sorunları hafifletmek için haftalık toplantılar koyduk ve oldukça iyi işliyor.
En zor olan, acil durum olmayan ama takvimin sıkışık ve spesifikasyonların belirsiz olduğu anlarda hangi yaklaşım türünün doğru olduğuna karar vermek; en azından bunu ortaklaşa kararlaştırıyoruz.
İnsan bunu kendi kendine öğrenemez değil, ama yaygın problemleri ve çözümleri mekanik biçimde yazabilecek kadar ezberleme yöntemi benim için gerçekten eziyetli.
Şirketin sahibi değilseniz, her zaman dışarıdan görünen değerinizle değerlendirilirsiniz.
İşvereniniz görsel olarak değerinizi göremiyorsa orada tutunma ihtimaliniz düşüktür.
Tam anlamıyla liyakate dayalı bir performans sistemi ideal olsa da, işe alım ya da değerlendirme başkasının elindeyse başarı %100 o kişinin sizi nasıl gördüğüne bağlıdır.
Bu algı, şirkete gerçekten değer katsın ya da katmasın, dışarıdan görünen görüntüden doğar.
Burada bahsettiğim programlama becerisi ya da gerçek değer değil, istihdam ve değerlendirme; hem üretken olup hem de itibar yönetimini iyi yapan pek çok kişi de var.
Kişisel olarak, ekipteki kıdemlilerin gerçekten zor işleri fiilen başarmasını isterim.
Junior’ların iş yapmasına yardımcı olmak güzel, ama bilgi, deneyim ve insan ilişkileri becerileri eksik olan junior’ların yapamayacağı zor ve karmaşık işler için hâlâ deneyimli insanlara ihtiyaç var.
Hiçbir pair programming bunu tamamen ikame edemez.
Düşük değerli özelliklerin çok iyi uygulanmış olduğu, ama en deneyimli insanların daha az deneyimli olanlara birim testi yazma gibi konularda yardım etmekle meşgul olduğu için yüksek etkili, yüksek öncelikli işlerin bitmediği durumlardan kaçınmak gerekir.
Bir işin junior’a verilmiş olması, varsayılan olarak kolay bir problem olduğu anlamına gelmez; aksi hâlde mühendisleri nasıl geliştirebilirdik?
Tüm kıdemliler zamanını junior mentörlüğüne ve iş birliğine harcamamalı; ama ekipte böyle birkaç kişi varsa güç çarpanı rolü oynar ve tüm ekibe fayda sağlar.
İşe alım sırasında bilinmiyor olsa bile, o kişi faydalı bir niş rol bulduysa şirket bunu resmî bir role dönüştürmeliydi.
O bir koçtu; böyle bir rol için işe alınsaydı sorun olmazdı, ama muhtemelen koç istenseydi ayrıca işe alınırdı.
Zor özellikler, sınırsız zaman verilse bile junior’ın bitiremeyeceği türden olabilir; çünkü henüz o beceriye sahip değildir ve bu becerinin oluşması yıllar alır.
Bazen kıdemli desteği gerekir, ama bu yüzden kıdemli hiçbir şey üretemiyorsa şirket açısından anlamı zayıftır.
Zor özellikleri yeterince kıdemli birine verip, junior’ı yetiştirmek istiyorsanız işin daha kolay kısımlarını onunla paylaşmasını ve kıdemlinin ne yaptığını açıklamasını sağlayabilirsiniz.
Tim’in herkese yardım etme tavrı harika; ama diğer programcıların bu kadar çok yardıma ihtiyaç duyması ve Tim’in kendi çıktısını üretmeye hiç zamanı kalmaması da tuhaf.
Sorun Tim’de değil; uzmanların sürekli yardıma ihtiyaç duyduğu ve gönüllü gibi davranan Tim’in her an yardıma koştuğu bir yapıyı kabul edilebilir gören yönetimde.
En başta kıdemlilerden biri düzgün inşa etmiş olsaydı, junior’ların da değiştirebilmesi gerekirdi.
Eğer o kıdemli yapmış olmasına rağmen yapı yüzünden zor ve karmaşıksa, ona neden kıdemli dendiği sorgulanır.
Yine de tüm kıdemlilerin işi sadece junior’lara yardım etmek olamaz.
Bugünlerde böyle biri olmak zor.
Her şey dışarıdan görünen performans odaklı olduğu için böyle kişiler kolayca işten çıkarılacaklar arasına girebiliyor; bunu bizzat yaşadım.
Takım oyuncuları, mentörler, yazılım mimarları giderek geri plana itiliyor; çok kod döken coder’lar onların yerini alıyor.
Teknik borç yüzünden özellik teslimi ve bakım yapabilme kapasitesi zamanla düşse bile, yöneticiler fiilen çıkan özelliklerden ya da hata sayısından bağımsız olarak haftada 5000 satırdan fazla kodu istikrarlı şekilde yazan geliştiricileri seviyor.
Bir ekip lideri ve karmaşık projeler yönetmiş bir mühendis olarak, haftada 2000 satırdan fazla kod yazan biri bana korkutucu geliyor.
Bu yılda 100 binden fazla satır kod demek; gereksiz karmaşıklığı düşünmek gerekir.
Aynı özelliği 10 bin satırla, daha az hatayla ve yarı sürede gerçekleştirme olasılığı yüksek olabilir; ama o zaman haftada yalnızca 380 satır eder ve yönetici bundan hoşlanmaz.
Binlerce satır üreten geliştiricilerin projenin uzun vadeli yönünü yeterince derin düşünmediğini varsayma eğilimindeyim; bu kodların çoğu bana atılacak kod gibi geliyor.
Google bunu bir ölçüde Tech Lead rolüyle kurumsallaştırdı; bu mühendisten bireysel katkıcıdan ziyade güç çarpanı ve mentör olarak davranması beklenir.
Tasarlandığı gibi her zaman çalışmaz; belki de nadiren çalışır ve TL insan koordinasyonu, planlama ve küçük tartışmalara gömülüp mühendis olarak çalışamaz hâle gelebilir.
Yine de rolün niyeti iyi.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
Her şeyi ölçme ve elde edilebilen sayılara göre hareket etme fikri 19. yüzyıldan beri vardı.
Yöneticiler o zamandan beri aynı uygulamaları tekrarladı ve sonuçlar da aynı şekilde oldukça istikrarlı biçimde ortaya çıktı.
Kısa süre çalıştığım bir şirketin sahibi, en yeni web framework’lerini ve trendleri takip etmek için web servisini her 6 ayda bir baştan yazmak istiyordu.
Haftada 5000 satır yazan bir kahraman olsaydı, onu hemen işe alırdı.
Bakım projelerinde tek başıma bir satır bile yazmadan bir hafta geçirdiğim de olur; hatta bütün haftayı kod satırı sayısını azaltmaya ayırdığım da olur.
Harika.
Kürekte seat racing denen bir antrenman vardır; sekiz koltuk için farklı kombinasyonlara insanları ekleyip çıkararak en hızlı kombinasyonu bulursunuz.
Bireysel güç de bir metriktir, ama yarış teknesine kimin bineceğini takımın hızı belirler.
Sonunda en hızlı kombinasyonda en güçlü sekiz kişinin aynen yer alması nadirdir; çoğu zaman kâğıt üzerinde daha üstün görünmese bile hangi tekneye koyarsanız koyun onu hızlandıran “sihirli” bir iki kişi olur.
Bu kişiler başkalarının dengesini, ritmini ve gücünü incelikli biçimde iyileştirir.
Bazı koçlar bunu gönülden kabul etmez ve direnir; sonuçta daha az galibiyet alırlar.
Yazılım ekiplerine de çok benziyor; nihayetinde önemli olan kombinasyon ve sonuçtur.
“Teknik liderlik” konusunda koçluk yapmam istendiğinde, her zaman kolaylaştırıcı tipteki çalışanlara dikkatle bakılmasını söylerim
Onların yardımı diğer çalışanları daha üretken ve etkili kılar; bazı insanlar da şaşırtıcı işleri bizzat yapıp tüm takdiri toplamaktansa, başkalarının harika işler çıkarmasına yardımcı olmaktan daha büyük mesleki tatmin duyar
Bu tür insanlar çoğu zaman düşük puan alır, ama kaybedildiklerinde ekip üretkenliğinde net bir düşüş olur
Bu yüzden gerçekten üretken olmayan kişilerle, üretkenliği başkalarının başarısında ortaya çıkan kişileri ayırt etmeye yarayan araçlar sunmaya çalışırım
Tek bir metriği ölçüp buna göre yönetmek asla iyi değildir
Çünkü metriği manipüle eden kişi “kazanır” ve bu davranış terfiye yol açar
Bunu Google liderliğine de söyledim, ama Laszlo “Elimizdeki sistem bu; mükemmel değil ama bununla devam edeceğiz. Onun içinde çalışıp çalışmamak senin seçimin” dedi
Sadece o toplantı bile üst düzey liderliğin daha iyi bir mühendislik ortamı oluşturmak isteyip istemediğini anlamak için yeterliydi
Birçok yeni yönetici, özellikle de eskiden bireysel katkı sağlayan mühendis olanlar, “en iyi” üyeleri tutup “kötü” üyeleri gönderirlerse ekip moralinin ve çıktının birlikte iyileşeceğini düşünür
Ama onların anladığı “en iyi”, insanları yönetme ölçütlerine değil, eskiden kendi işlerini iyi yapma ölçütlerine dayanır
Bu yüzden kendilerine benzer beceri ve alışkanlıklara sahip kişileri tercih eder, farklı beceri ve alışkanlıklara sahip kişileri ise küçümserler
Bunu fark etmelerini sağladığınızda gözlerinin açıldığı an her zaman ilginçtir
Sıfır faiz politikası, Jira panolarını ve görev listelerini yöneten kıdemli direktör benzeri rolleri artırdı; gerçek işi yapabilecek insanları ise yetersiz bıraktı
Başkalarının üretkenliğini kolaylaştıran insanların olabileceği fikrine karşı değilim, ama sonuçta bir şeylerin tamamlanması için o “başkaları”na ihtiyaç var
Aksi halde organizasyon nekroza uğrar