# Performans değerlendirmen bir hafıza testidir
> 740 pull request'i ciddiyetlerine göre puanladık, her birini yol haritamızın dokunduğu bileşene verdiği önemle çarptık ve liderlik tablosunu yayınladık. İki kişinin çıktının %58'ini oluşturduğu ortaya çıktı. İşte formül ve işte hâlâ yanlış olduğu her yer.
- Source: https://jays.fyi/tr/blog/performans-degerlendirmen-hafiza-testi
- Author: Jay Derinbogaz
- Published: 2026-08-08
- Language: tr
- Tags: engineering-management, performance-reviews, ai, gitrank
- Reading time: 16 min
- Machine translated: yes — original: https://jays.fyi/blog/your-performance-review-is-a-memory-test
---
Herhangi bir mühendislik yöneticisine en iyi mühendisinin kim olduğunu sorun. Cevabın ne kadar hızlı geldiğini izleyin. Hiç tereddüt yok, hiçbir uyarı yok, "önce bir şey kontrol edeyim" yok. Biliyorlar. Her zaman biliyorlardı.
Şimdi onlardan çalışmayı göstermelerini isteyin. Bir hikaye alırsınız. Genellikle iyi bir hikaye, birinin sabah 2'de hallettiği bir olay, bir çeyreği tıkayan bir yeniden düzenleme veya kanalda her zaman cevap veren kişi hakkında. Almayacağınız şey ise bir sayı, bir karşılaştırma veya yöneticinin odasında bulunmadığı dört mühendisin çalışmasına dair herhangi bir hesaptır. Güven asla ölçüme dayanmıyordu. Hatırlamaya dayanıyordu ve hatırlama yakınlığın bir fonksiyonudur.
İşte tez ve bundan sonraki her şey bunun kanıtıdır. Mühendislik performansı hafızadan değerlendirilir, hafıza değerden çok görünürlüğü ödüllendirir ve insanların gerçekte inşa etmesini istediğiniz şey, onları değerlendirdiğiniz şeyle asla bağlantılı olmayan bir yol haritasında yazılıdır. Bu iki belge, yol haritası ve performans değerlendirmesi, gördüğüm neredeyse her şirkette, yakın zamana kadar benimki de dahil olmak üzere, birbiriyle hiçbir ilgisi yoktur.
Bu yüzden onları birbirine bağladık. Birleştirilen her pull request bir model tarafından okunur, bir ciddiyet atanır ve dokunduğu bileşenle yol haritamızın ne kadar ilgilendiğiyle çarpılır. Sonuç aylık bir liderlik tablosudur ve bonus kararlarını besler.
Size bizimkini göstereceğim, utanç verici kısımları ve yanlış olduğu kısımları da dahil.
Platform deposu için 30 günlük liderlik tablosu, Ağustos 2026. Yedi geliştirici, aralarında 10.415 puan.
## Genel kabul gören bilgelik, bunun ölçülemeyeceği yönünde ve bu bilgelik bir omuz silkmedir
Bireysel mühendislik çıktısını ölçme konusundaki standart pozisyon, yapmamanız gerektiğidir, çünkü her vekil bir tuzaktır. Kod satırları şişkinliği ödüllendirir. Commit sayısı bölmeyi ödüllendirir. Hikaye puanları bir ölçüm değil, bir pazarlıktır. İyi çerçeveler bile kasıtlı olarak takım düzeyindedir: DORA, bir teslimat hattıyla ilgili dört şeyi ölçer ve insanlar hakkında hiçbir şey söylemez; bu, yazarlarının açıkça belirttiği bir tasarım tercihidir.
Bunların hepsi doğru ve hiçbiri bir cevap değil. Ölçmeyi reddetmek, kimsenin sıralanmadığı bir şirket yaratmaz. Herkesin yine de sıralandığı, ancak denetim izi olmayan bir mekanizmayla çalışan bir şirket yaratır. Sıralama hala maaş zamanında gerçekleşir. Sadece bir odada, hafızadan, odadaki kişinin en çok zaman geçirdiği kişiye göre ağırlıklandırılarak yapılır.
Buna **gürültücü mühendis primi** diyelim: ne kadar iyi değerlendirildiğiniz ile ne kadar iyi performans gösterdiğiniz arasındaki fark, tamamen değerlendirmenizi yazan kişiye olan uzaklığınızla açıklanır. Bu, yöneticilerde bir karakter kusuru değildir. Bir insandan, on beş kişinin teknik katkılarını bir yıl boyunca sadece fark ettikleri şeyleri kullanarak karşılaştırmasını istemenin tahmin edilebilir sonucudur.
Bu prim, yaklaşık iki yıl öncesine kadar kaçınılmazdı, çünkü daha iyi bir cevap için ham madde, kimsenin okumaya vakti olmadığı bir yığın diff idi. Bu kısıtlama ortadan kalktı. Bir model, deponuzdaki her diff'i her ay, şu anda tahmin yürüttüğünüz toplantının bir saatlik maliyetinden daha düşük bir maliyetle okuyabilir.
Onları okumak kolay kısım. Okumanın neye değer olduğuna karar vermek asıl sorun ve bu teknik bir soru değil.
## Formülün tamamı tek bir satıra sığıyor
İşte tamamı, [GitRank](https://gitrank.dev)'teki puanlama yolundan:
```
final_score = is_eligible ? severity_base_points × component_multiplier : 0
```
Bu, blog için bir basitleştirme değil. Bu satırın ta kendisi. Gizli bir regresyon, öğrenilmiş bir ağırlıklandırma, itibar terimi veya kıdem ayarlaması yok. Ciddiyet çarpı önem veya sıfır.
Ciddiyet yarısı sabit bir merdivendir. Dört seviye, dört puan değeri, bir kez ayarlanır ve puanlanan herkes tarafından görülebilir:
Ciddiyet başına temel puanlar. Bir model etiketi atar; puan değerleri bize aittir.
Kritik bir düzeltme, yirmi düşük öncelikli düzeltmeye bedeldir. Bu oran bir politika beyanıdır ve bunu birinin kafasında bırakmak yerine yazdık.
Önem yarısı aslında önemli olan kısımdır ve bu yaklaşımın genelleştiğini düşünmemin nedenidir. Depodaki her bileşen bir çarpan taşır ve çarpan, ürünün bu çeyrekte neye ihtiyacı olduğuna göre belirlenir:
Yirmi bileşen, dört önem kademesi. Kritik 2.0x, Yüksek 1.5x, Normal 1.0x, Düşük 0.5x.
Chat 2.0x çünkü sohbet, ürünü üzerine bahse girdiğimiz şey. Authentication 1.0x çünkü çalışıyor ve sessizce çalışmaya devam etmesini istiyoruz. İşbirliği özellikleri ve belge vurgulama, chat ile aynı nedenden dolayı 2.0x. Bu sayıların hiçbiri teknik yargılar değil. Bunlar, ödeme yapan bir alana yeniden yazılmış yol haritası.
İşte hamle bu. Model değil, liderlik tablosu değil, oyunlaştırma değil. Hamle, strateji belgesi ile ücretlendirme girdisinin aynı belge haline gelmesidir. Yol haritası Ekim'de değişirse, çarpanlar Ekim'de değişir ve teşvik, on dört ay sonraki bir sonraki yıllık değerlendirme döngüsünde değil, Ekim'de değişir.
Bunu açıkça söyleyeyim, çünkü insanların atladığı kısım burası. Büyüyen bir mühendislik organizasyonundaki asıl zorluk, insanların tembel olması değildir. Asıl zorluk, kırk akıllı insanın her biri kendi yerelinde dürüstçe optimizasyon yaparken, topluca şirketin istediğini söylediği şeye denk gelmeyen işlerin dörtte birini üretmesidir. Orta kademe yönetim büyük ölçüde bunu düzeltmek için vardır; stratejiyi konuşmalarında taşıyarak, masa masa dolaşarak ve her adımda doğruluğu kaybederek. Bir çarpan tablosu aynı yönlendirme işini tek adımda yapar, yorulmaz, kayırmaz ve Ocak ayında söylediğinizi unutmaz.
## Sohbetteki kritik bir düzeltme, API'deki kırk bakım commit'ine bedeldir
İki tarafı birleştirince fark ciddileşiyor.
Sohbetteki bir P0, 100 taban puanı çarpı 2.0 ile **200 puan** eder. API'deki bir P3 ise 5 taban puanı çarpı 1.0 ile 5 puan eder. Birleştirebileceğiniz en değerli tek pull request, en az değerli olanın kırk katıdır. Yüzde kırk daha fazla değil. Kırk kat.
Bu sayı kasıtlı olarak serttir ve nazik teşviklerin asla başaramadığı şeyi yapar. Kimse haftasını %15'lik bir fark için yeniden düzenlemez. İnsanlar haftalarını kesinlikle 40 katlık bir fark için yeniden düzenler.
Bu ağırlıklar altında gerçek bir haftaya ne olduğuna bakın. İşte beş hafta boyunca ciddiyet dağılımı, 13 Temmuz haftası genişletilmiş olarak:
13 Temmuz 2026 haftası: 1 P0, 50 P1, 111 P2, 26 P3. 188 birleştirilmiş pull request.
188 pull request. P2'ler %59'unu oluşturuyor, ki bu her yerde normal bir mühendislik haftasının görüntüsüdür: çoğunlukla geçici çözümü olan orta büyüklükte düzeltmeler.
Şimdi ağırlıklandırın. Bu 111 P2, 1x çarpanla 2.220 puan eder. 50 P1 ise 2.500 puan eder. **Yarısından daha az sayıdaki pull request, haftanın değerinin yarısından fazlasını taşıyor** ve tek bir P0, ham commit sayısının aynı iş olarak değerlendireceği yirmi P3'e bedel.
Ağırlıklandırmanın tüm argümanı, tek bir haftalık gerçek veride budur. Pull request'leri sayarsanız haftanın P2'lerle ilgili olduğu sonucuna varırsınız. Ağırlıklandırırsanız haftanın belirli elli iş parçasıyla ilgili olduğunu ve bunları kimin yaptığını söyleyebileceğinizi görürsünüz.
## İki kişi çıktının %58'ini oluşturuyordu ve sıralamayı tahmin edemezdim
Liderlik tablosuna geri dönelim, çünkü kendi sezgime güvenmeyi bıraktığım yer burası.
Yedi geliştirici, 30 günlük pencerede 10.415 puan. En üstteki geliştirici bunların 3.530'una sahip, yani **ekibin değer olarak ürettiği her şeyin %33,9'u**. İlk ikisi birlikte %57,7'sini elinde tutuyor.
Bunun ne anlama gelip gelmediği konusunda dikkatli olmak istiyorum. Diğer beş kişinin yetersiz performans gösterdiği anlamına gelmez ve eğer böyle okursanız bu yazıdan yanlış dersi çıkarmış olursunuz. Böyle bir yoğunlaşma genellikle ilk ikisinin en yüksek çarpanlı bileşenler üzerinde çalıştığı anlamına gelir ki bu tam olarak sistemin ödüllendirmek üzere tasarlandığı ve onlardan yapmalarını istediğimiz şeydir. Bu sayı, değerin nereye düştüğünün bir tanımıdır, beş kişi hakkında bir karar değil.
Ama sıralamaya bakın, çünkü tahminimi bozdu. İşte kimin neye sahip olduğu:
Bileşen başına birincil katkıda bulunan. Bir kişi, en yoğun iki alanın her ikisinde de lider uzman.
Mulualem-E, 2.0x bileşenimiz olan sohbetin, 230 pull request'inin 71'i ile birincil uzmanı. Aynı zamanda 1.5x bileşenimiz olan ajanların da 148'in 86'sı ile, yani o alanın %58'i ile birincil uzmanı. Bunu bana tarif edip liderlik tablosunda kimin zirvede olduğunu sorsaydınız, tereddüt etmeden onu söylerdim. İkinci sırada.
Zirve, tugberkayartextcortex'e ait; Mulualem-E'nin 12'sine karşı 31 P1 pull request'i var. Ciddiyet karışımı, bileşen sahipliğini yendi. Ürünün en önemli alanına sahip olmak, içinde tekrar tekrar yüksek etkili işler yapmakla aynı şey değil ve bunu yayınlayana kadar tazminatımızın aslında bu ikisinden hangisini ödüllendirdiğini size söyleyemezdim. Hangisini fark etmişsem onu ödüllendiriyordu.
İşte gürültülü mühendis primi, kendi şirketimde, suçüstü yakalandı. Sezgim doğru iki kişiyi ve yanlış sırayı tutturmuştu ve yanlış sıra, bir ikramiyenin ne olduğudur.
## En çok kodu yazan kişi son sırada
Şimdi beni rahatsız eden bulguya gelelim, ki bununla gerçekten oturmanızı istediğim bulgu bu.
karthikmudunuri, sunum oluşturucunun birincil uzmanı; bu bileşenin 58 pull request'inin 51'ine sahip. Bu, tüm bir ürün alanının %88'i. Hacim onun sorunu değil. Liderlik tablosunda 300 puanla son sırada.
Tam olarak bu sayıya denk gelen bir kombinasyon var: 1.5x bileşeninde dört P1 pull request'i ve puan getiren başka hiçbir şey yok. 4 × 50 × 1.5 = 300. Rozetinde 4 P1 yazıyor, bu da uyuyor. Bunun bu panodan gerçek ayrıştırma olduğunu kanıtlayamam ve bu belirsizliği dürüstçe belirtmek istiyorum, çünkü liderlik tablosu 30 günü kapsarken bileşen grafikleri 6 Temmuz'dan 3 Ağustos'a kadar olan dönemi kapsıyor, yani iki pencere yakın ama aynı değil.
Eğer ayrıştırma doğruysa, kabaca 47 birleştirilmiş pull request sıfır puan aldı. Bunun için sadece iki açıklama var. Ya gerçekten düşük önem derecesine sahip cilalama işleriydi – ki bu durumda puan doğrudur ve faydalı tartışma, bir kişiyi bir ay boyunca %88 konsantrasyonla, önemli olarak işaretlemediğimiz bir bileşene harcamamız gerekip gerekmediği üzerine olur. Ya da uygunluk eşiği tarafından sıfırlanan gerçek işlerdi – ki bu durumda puan yanlıştır ve araç ona bir açıklama borçludur.
Puanlama, uygunluk konusunda ya hep ya hiç şeklinde çalışır. Etkinleştirilmiş bir kriteri karşılayamazsanız, varsayılan küme şunlardır: konu bağlantısı, düzeltme uygulaması, PR açıklama kalitesi, modelin test gerektiğine karar verdiği durumlarda testler ve 3.000 satır tavanı. Ve önem derecesi ne olursa olsun puan sıfırdır. Kötü açıklamalı, gerçekten kritik bir düzeltme, hiçbir şeyle aynı puanı alır.
Hangi açıklamanın doğru olduğunu bilmiyorum ve asıl şikayetim şu: gösterge paneli bana bunu pull request başına söyleyebilmeli ve bugün bunu bir toplamdan tersine mühendislik yaparak çıkarmamı gerektiriyor. Bu, ürünümüzde gerçek bir eksiklik ve düzeltiliyor. Aynı zamanda insanların puanlama sistemlerinden korktuğu tam da bu başarısızlık modu, bu yüzden bunu bir tasarım incelemesinde bulduğumu iddia etmeyeceğim. Bu yazıyı yazarken buldum.
## Hataların nerede olduğu bir ürün kararıdır, mühendislik kararı değil
Her pull request'i puanlamanın diğer bir sonucu da, kalite hakkında anekdotlarla tartışmayı bırakmanızdır.
En yoğun on bileşen, 6 Temmuz – 3 Ağustos 2026. 740 pull request, bunların 230'u hata düzeltmesi.
En yoğun on bileşende 740 pull request. Bunların 230'u, **%31'i**, yeni iş değil hata düzeltmesiydi. Sadece Chat 230 pull request, yine %31, bu da 2.0x çarpanının çalışırken nasıl görünmesi gerektiğidir.
Sonra sunum oluşturucu var: 58 pull request, 23'ü hata. Bu, dört katkıda bulunanlı bir bileşende %40 hata oranı demek, yedi katkıda bulunanlı Chat'teki %25'e karşı. Ve ödemeler, paraya dokunan bileşende, 44 pull request ve 20 hata ile %45 oranında.
Bileşen bazında kritik hatalar. Chat ve agents 57'şer ile eşit.
Chat ve agents 57'şer hata ile eşit, ancak Chat bunları 230 pull request'te, agents ise 148'de üretti. Aynı hata sayısı, birinin arkasında %55 daha fazla iş var. Bu, agents hakkında hiçbir retrospektifin ortaya çıkaramayacağı bir sinyaldir, çünkü takımdaki hiçbir kişi her ikisinden de yeterince birleştirmemiştir.
Aynı beş hafta boyunca hata düzeltmeleri ve özellik geliştirme karşılaştırması.
Hata çizgisi ve özellik çizgisi, birbirleriyle takas yapmak yerine birlikte yükseliyor; bu, istenen şekil ve benim beklediğim şekil değil. Bu grafiği betimleyici olarak okuyorum, bir şeyi iyileştirdiğimiz iddiası olarak değil. Beş haftayı kapsıyor ve eğilim, tek bir büyük projenin iniş yapmasından kaynaklanacak gürültünün içinde.
## İşte kendi aracımızın şu anda yanlış olduğu yerler
Size sadece çalışan kısımları gösterseydim, hepsini göz ardı etmekte haklı olurdunuz. O yüzden:
**Prompt sekmesi, üretim yolunda söylediği gibi çalışmıyor.** Değerlendirme prompt'unu özelleştirmenizi sağlayan bir yönetici ekranı var. Toplu değerlendirme çalıştırıcısını yönlendiriyor. Pull request'leri üretimde puanlayan webhook ve cron yolu, kaynak kodunda sabit kodlanmış bir prompt kullanıyor. Bu şablonu, canlı puanlarınızı bugün değiştireceğini umarak düzenlerseniz, değişmeyecek ve kullanıcı arayüzünde bunu size söyleyen hiçbir şey yok.
**Gösterge panelindeki "PRs" etiketli liderlik tablosu sütunu, pull request sayısı değil.** Yazarlık puanı. Bunu yukarıdaki ekran görüntüsünde görebilirsiniz: en üst satırda PRs altında 3530 ve Score altında 3530 yazıyor. Bağımsız liderlik tablosu sayfası bunu doğru yapıyor, pull request'ler ve yazarlık için ayrı sütunlar var; yani bu, herkesin gerçekten açtığı tek ekrandaki yanlış bir etiket ve bu, yanlış etiket için en kötü yerlerden biri.
**README'miz yanlış puan değerlerini yayınlıyor.** P2'nin 25 puan ve P3'ün 10 puan olduğunu söylüyor. Veritabanı tohumları 20 ve 5 veriyor ve yukarıdaki yapılandırma ekran görüntüsü 20 ve 5'i doğruluyor. Dokümantasyon ve yazılım puanlama konusunda anlaşmazlık içinde ve yazılım kazanıyor.
**İnceleme parçası neredeyse ölü.** Başkalarının kodunu incelemek, ayrı bir hız merdiveninde puan kazandırıyor; daha hızlı incelemeler daha yüksek puan alıyor. Tüm liderlik tablosunda, tam olarak bir kişinin herhangi bir inceleme puanı var: toplam 10.415 üzerinden 90, yani puanlanan her şeyin **%0,86'sı**. Kod incelemesi konusunda neyi teşvik ettiğimizi düşünüyorsak, teşvik etmiyoruz. En olası neden, inceleme senkronizasyonunun yakın zamanda toplamaya başlaması, ancak bunu doğrulamadım ve doğrulayana kadar dürüst okuma, özelliğin oturmadığı yönünde.
**Kendi SSS'miz kabaca %90 sınıflandırma doğruluğu iddia ediyor ve bunu destekleyemiyorum.** Depoda hiçbir değerlendirme seti, hiçbir kıyaslama betiği ve bu sayının arkasında hiçbir hakemli derlem yok. Bu, bir satıcıdan kabul etmeyeceğim bir iddia ve kendi pazarlama sayfamızda. Kaldırılıyor.
## Bir puan tablosu oynanır ve bizimkinin neredeyse hiç savunması yok
Puanlama kodumuzda oyun oynamayı önleme önlemleri aradım. İşte var olanların tam listesi.
3.000'den fazla değişiklik satırı içeren pull request'ler uygun değildir, bu da en kaba şişirme yöntemini engeller. Kendi kendine yapılan incelemeler sıfır puan alır ve tüm liderlik tablosu sorgularından hariç tutulur. Kullanıcı adında `[bot]` bulunan hesaplardan gelen incelemeler atlanır. Modele, kodun gerçekten açıklamada iddia edilen şeyi yapıp yapmadığı sorulur; bu, bir anlamsızlık dedektörüne en yakın şeydir. Yöneticiler herhangi bir puanı geçersiz kılabilir ve geçersiz kılma işlemi en az on karakterlik yazılı bir gerekçe gerektirir.
İşte var olmayan şeyler. Kişi başına haftalık veya aylık puan sınırı yok. Aynı bileşende tekrarlanan çalışmalarda azalan getiri yok. Hiçbir türden zaman aşımı yok ve liderlik tablosundaki 30 günlük pencere, herkesin genişletebileceği varsayılan bir tarih aralığıdır, bir sınır değildir. Kopya veya geri alma tespiti yok; yani geçen hafta kırdığınız bir şeyi düzeltmek, başka birinin kırdığı bir şeyi düzeltmekle aynı puanı alır. İncelemeciler arasında gizli anlaşma tespiti yok. Bot filtresi incelemecilere uygulanır ancak pull request yazarlarına uygulanmaz; bu nedenle bir bot tarafından yazılıp birleştirilen bir pull request, insan tarafından yazılmış gibi puan alır ki bu 2026'da varsayımsal bir durum değildir.
Bu sistemi kullanmak isteyen herkes kullanabilir. İşi daha fazla pull request'e bölün, her birine bir sorun bağlantısı ve temiz bir açıklama ekleyin, 2.0x bileşenini hedefleyin. İşte açık budur ve tam olarak neye benzediği için adını koymak istiyorum: Ürünün en önemli kısmında yapılan küçük, iyi belgelenmiş, iyi test edilmiş değişikliklere benziyor. Skor tablomuzu aldatmanın en etkili yolu, istediğimiz şeyi yapmaktır. Bu bir kaza değil, tasarım hedefidir ve Goodhart yasasına karşı şimdiye kadar gerçekten işe yaramış tek savunmadır. Vekili, gerçek şey olmayan herhangi bir şekilde taklit etmeyi pahalı hale getirin.
Bu tam bir savunma değil. Ciddiyet, bir diff'i okuyan bir model tarafından atanır ve yeterince dramatik bir pull request açıklamasıyla bir modele orta seviye bir hatayı yüksek seviye olarak nitelendirmesi söylenebilir. Bunun ne sıklıkta olduğunu ölçmedik. Kimse ölçmedi. Bizimki de dahil olmak üzere bu kategorideki herhangi bir aracı değerlendiriyorsanız, sorulması gereken soru budur ve "kabaca %90" bir cevap değildir.
## Size iyileştirme rakamını vermeyeceğim çünkü bende yok
İşte yapmak istediğim iddia. Bu liderlik tablosunu aylık olarak yayınlamaya başladığımızdan beri, çalışmalar gözle görülür şekilde önemli olarak işaretlediğimiz bileşenlere kaydı, çünkü mühendisler puanı istiyor.
İşte bunu bir rakam olarak sunmama nedenim. Bunu işin ortasında, temiz bir temel çizgi, kontrol deposu veya "kayma"nın ne anlama geleceğine dair önceden kaydedilmiş bir tanım olmadan açtık. Çarpanlar bu dönemde değişti. Personel sayısı ve yol haritası da öyle. Yayınlayacağım herhangi bir yüzde, verileri gördükten sonra seçtiğim bir sayı olurdu ki bu bir ölçüm değil, bir süslemedir.
Size söyleyebileceğim şey nitelikseldir ve bunu da öyle etiketliyorum. Tartışmalar değişti. İnsanlar bana çalışmalarının takdir edilip edilmediğini sormayı bıraktı ve bir bileşenin neden 1.0x olarak derecelendirildiğini sormaya başladı. Bu, yapılacak çok daha iyi bir tartışma ve tek başına bunun için ödeme yapardım.
Eğer gerçek bir öncesi-sonrası verisine sahip olursam, önce metodolojiyi, sonra rakamı yayınlayacağım. Tersini yaparsam, bana inanmayın.
## Yol haritasına yöneltin, sonra cetveli insanlara verin
Ürünün üzerinde bitirmek istiyorum çünkü ürün buradaki en az ilginç şey.
Organizasyon şemasının gerçek işi hiçbir zaman yetki olmadı. Yönlendirmeydi. "Bu çeyrekte ne önemli" sorusunun cevabını karar verenlerden dışarıya, "kim ne yaptı" sorusunun cevabını da içeriye taşırdı ve her ikisini de kötü, yavaş ve her adımda muazzam bir bozulmayla yapardı. Kurumsal politikalar hakkında sevmediğiniz her şey, bu yönlendirmeden kaynaklanan bir sıkıştırma artefaktıdır. Yöneticiler buna neden olmadı. Onlar mevcut tek donanımdı.
Artık mevcut tek donanım onlar değil. Her diff'i artı bir çarpan tablosunu okuyan bir model, dışa yönlendirmeyi tek adımda, içe yönlendirmeyi ise bir sorguda yapar. İnsanlara kalan şey, aslında her zaman asıl iş olan ama hiçbir zaman zaman bulunamayan kısımdır: çarpanların ne olması gerektiğine karar vermek ve bu kararların puanlarını etkilediği insanlarla birlikte oturmak.
Politikalar ortadan kaybolmaz. Kimsenin size bunu satmasına izin vermeyin. Yer değiştirirler. "Yöneticim bu çeyreğimi hatırlıyor mu?" sorusundan "Yol haritası bunun temel olduğunu söylerken bileşenim neden 1.0x olarak derecelendiriliyor?" sorusuna kayarlar ve bu ikinci kavga, şirketin gerçek stratejisi hakkında, herkesin okuyabileceği bir tabloda, kamuya açık bir şekilde yapılan bir kavgadır. Ben her ay bu kavgayı, şu anki yılda bir kez, özel olarak, birisinin on bir ayı hafızasından yeniden inşa ettiği kavgaya tercih ederim.
Birisi bunu kötü yönetecek. Birisi, uygunluk açıklamaları veya geçersiz kılma izi olmayan bir skor tablosunu duvara asacak ve en alttaki ondalık dilimi işten çıkaracak ve bu bir felaket olacak ve suç modelden ziyade çarpanları seçen kişiye atılacak. Bunun bedelini ödeyen taraf odur ve bunu kuran kişi ödemeyecektir.
Öyleyse beni de aynı araçla ölçün. Buna benzer bir şey yürütüyorsanız, liderlik tablosunun yanında üç şey yayınlayın: çarpan tablosu, böylece insanlar puan yerine stratejiyle tartışabilir. Her pull request bazında döküm, böylece sıfır alan herkes hangi kapının kendilerine kapandığını görebilir ve itiraz edebilir. Ve geçersiz kılma günlüğü, çünkü bir insanın değiştirdiği sayı, denetlemeye değer tek sayıdır.
Şu anda ilkini yayınlıyoruz. Üçüncüyü kötü yapıyoruz: bir geçersiz kılma, gerekçesini değerlendirme satırına yazar ve geçersiz kılmayı temizlemek, gerekçeyi de onunla birlikte siler; yani elimizde olan, iptal edilebilen bir not, bir günlük değil. İkinciyi de yeterince iyi yayınlamıyoruz; bunu ancak bir bileşenin %88'ine sahip bir geliştiricinin kendi liderlik tablomda sonuncu olması ve ona nedenini açıklayamamam sayesinde fark ettim.
*GitRank, [gitrank.dev](https://gitrank.dev) adresindedir ve CC BY-NC 4.0 lisansına sahiptir. Üretim yolundaki puanlama, Claude Haiku 4.5 üzerinde 0.3 temperature ile çalışır. Yukarıdaki tüm rakamlar, 6 Temmuz ile 3 Ağustos 2026 tarihleri arasında kendi platform depomuzdan alınmıştır, örneklem büyüklüğü bir şirket ve yedi geliştiricidir; bu, bizim bir tanımımızdır ve herhangi bir şeyin kıyaslaması değildir.*
