- “10x mühendis” kavramı sezgisel olarak kulağa makul gelse de, gerçek üretkenliği nesnel olarak ölçmek çok zordur; bunu değişmez bireysel bir özellik olarak görmek de yanlış bir yaklaşımdır
- Yazılımın fiili sahipliği ve çıktıları, mühendislik ekibi düzeyindeki iş birliği ve yetkinlik tarafından belirlenir
- Gerçekten üstün organizasyonlar, yalnızca istisnai derecede yetenekli insanların değil, sıradan mühendislerin de sürekli iyi sonuçlar üretebildiği ortamlar kuran yerlerdir
- Sistemler, sıradan insanların hata yapabileceği ya da yorulabileceği gerçeği dikkate alınarak tasarlanmalı; odak “10x takım” oluşturmada olmalıdır
- Yazılım sistemi tasarımı ve kültürü, “sıradan insanların” özellikleri, çeşitliliği ve gelişim potansiyeli temel alınarak kurulmalıdır
- Sonuçta üretkenliğin temel göstergesi iş etkisidir; “en iyi yeteneği” değil, “uygun kişiyi” işe almak ve takımı buna göre kurmak önemlidir
“Sıradan mühendisleri” överken
- Bu yazı, “10x mühendis” kavramına yönelik bir eleştiriyi ve sıradan mühendislerin olağanüstü takım sonuçları ürettiği organizasyonların önemini anlatıyor
“10x mühendis” miti ve sınırları
- Herkes kariyerinde adeta sihirbaz gibi görünen olağanüstü mühendislerle karşılaşmıştır
- Bunun sonucunda “10x mühendis” kavramı doğdu; ancak bu kavramın dayanağı zayıftır ve önyargıları da güçlendirebilir
- Üretkenlik için tek bir ölçüt belirlemek neredeyse imkânsızdır
- Kullanılan teknoloji yığını, alan, geliştirme aşaması, pazar koşulları, deneyim gibi değişkenlerin birleşimi sonsuzdur
- Bir kişi belirli bir alanda 10x mühendis olabilir, ama alanların çoğunda sıradan ya da ortalamanın altında olabilir
- Bir zamanlar mükemmel bir DBRE olan biri bile zamanla o alanda sıradan bir seviyeye gelebilir
- Sonuç olarak, hiç kimse her alanda her zaman 10 kat daha iyi olamaz
Takım merkezli yazılım sahipliği
- Yazılımın sahibi ve yöneticisi takımdır; bireyler değil
- Yazılımın teslimi, bakımı, iyileştirilmesi, genişletilmesi ve refactor edilmesi gibi tüm süreçler takım düzeyinde yürütülür
- Tek bir kişinin sahip olduğu sistem, o kişi izin aldığında ya da işten ayrıldığında tek hata noktası (SPOF) hâline gelir ve organizasyon için bir kırılganlık oluşturur
- Startup’larda başlangıçta bireysel sahiplik kaçınılmaz olabilir; ancak organizasyon büyüdükçe mutlaka takım sahipliğine geçilmelidir
- Mühendislik liderlerinin temel görevi, yüksek performanslı takımlar oluşturmaya odaklanmaktır; önemli olan “10x mühendis” değil, 10x takım yaratmaktır
Gerçek yüksek performanslı organizasyonun koşulları
- Pek çok şirket, ekiplerini FAANG geçmişine sahip, seçkin üniversitelerden mezun ya da Staff Engineer seviyesindeki kişiler etrafında kurmayı tercih eder
- Ancak gerçekten iyi organizasyonlar, sıradan mühendislerin istikrarlı biçimde somut etki yaratabildiği yerlerdir
- Yalnızca “en iyilerin” sonuç üretebildiği bir yapı yerine, ortalama geliştiricilerin de inisiyatif alarak büyüyebildiği ve ürüne ve işe olumlu etki yapabildiği sistemler kurmak daha büyük bir rekabet avantajıdır
- Hatta bu tür organizasyonlar daha fazla dünya standartlarında mühendis yetiştirir
“Sıradanlık” kavramını yeniden tanımlamak
- Yazılım sektörü, “üst %10”, “top .1%” gibi elit merkezli düşünce biçimleriyle doludur
- Ama mühendislerin büyük çoğunluğunun, çeşitli deneyimler ve pratikle gelişmiş sıradan insanlar olduğunu kabul etmek önemlidir
- Hiç kimse doğuştan “mükemmel mühendis” olarak doğmaz
- Büyük mühendisler sonradan yetişir — herkes öğrenme ve deneyim yoluyla çok iyi olabilir
Sıradan insanlar için sistem tasarımı
- İşe alımda istisnai güçlü yönlere bakmak doğru olabilir; ama sistem tasarlarken insanların sıradan biçimde hata yaptığı, yorulduğu ve alışkanlıklara yaslandığı gerçeği hesaba katılmalıdır
- Ortalama mühendisler bilişsel önyargılardan, yorgunluktan ve duygusal dalgalanmalardan etkilenir
- Sistemler zeki bir azınlığa göre değil, sıradan mühendislerin bakış açısına göre tasarlanmalıdır ki olağanüstü yeteneklerin yaratıcı gücü ürünün kendisine yoğunlaşabilsin
“10x takım” nasıl kurulur
- Kod yazımı ile dağıtım arasındaki süreyi mümkün olduğunca kısaltın
- Hızlı dağıtım döngüsü, bilişsel yükü azaltır ve daha hızlı deney ile geri bildirim sağlar
- Dağıtım ne kadar yavaşsa, o kadar çok değişiklik tek seferde birikir; sorun takibi ve rollback zorlaşır
- Hatalardan geri dönüşü ve rollback’i kolaylaştırın
- Geliştiriciler kendi kodlarını kendileri dağıtabilmeli ve sorun fark ettiklerinde hızla geri alabilmelidir
- Doğru davranışı kolay, yanlış davranışı zor hâle getirin
- Tasarımcılar ve platform mühendisleriyle iş birliği yaparak guardrail’ler ve self-service yapılar kurun
- Gözlemlenebilirlik ve ölçümleme araçlarına aktif yatırım yapın
- Gerçek kod davranışını görünür kılarak tüm mühendislerin sistemi kolayca anlayıp debug edebilmesini sağlayın
- İç araçlara ve üretkenlik artışına mühendislik kaynağı ayırın
- Bu tür sistemler ayrı bir sahiplik gerektirir ve şirket genelinde öncelik olmalıdır
- Kapsayıcı bir kültür oluşturun
- Herkesin soru sorabildiği, hata yapabildiği ve keşif yapabildiği bir ortam
- Farklı geçmişlere, becerilere ve kıdem seviyelerine sahip ekipler daha dayanıklıdır ve değişime daha iyi uyum sağlar
- Her seviyeden mühendisin karışık olduğu ekipler kurun
- Junior’dan senior’a kadar herkesin birbirinden öğrenip birbirine öğrettiği bir yapı
- Bu tür sistemler yeni çalışan onboarding’i ve ekipler arası geçişler için de yeniden kullanılabilir
Üretkenliğin gerçek ölçütü: "iş etkisi"
- Sonuçta yazılım mühendisliğinde üretkenliğin ölçütü iş etkisidir
- Önemli olan çok kod yazmak değil, sorun çözmek ve değer üretmektir
- Gerçekte sektörü hareket ettiren ana güç Staff+ mühendisler değil, senior ve mid-level mühendislerdir
- Organizasyonun temelini onlar oluşturur ve işi sürekli ileri taşırlar
- Eğer yalnızca Staff+ seviyesindekiler etki yaratabiliyorsa, bu organizasyonda bir sorun olduğunun işaretidir
Dünya standartlarında mühendisler yetiştiren organizasyon
- Olağanüstü bir mühendis olmasanız bile, herkesin etki yaratabildiği organizasyonlar gerçekten iyi organizasyonlardır
- En iyi organizasyonlar, ayrıca dünya çapında en iyi insanları seçmek zorunda kalmadan, doğal biçimde en çok dünya standartlarında mühendis çıkaran yerlerdir
- Mühendislerin sorun çözmeye, gelişmeye ve etki yaratmaya odaklanabildiği yerlere yetenek akar; “mutlu çalışıp gelişme deneyimi”nin kendisi olumlu bir döngü yaratır
- Liderler, üstün yeteneklerin bireysel kapasitesine bağımlı kalmadan, bunu organizasyonun genel büyümesine ve müşteri değerine bağlayan rolü üstlenmelidir
“En iyi yetenek” yerine “uygun kişi”yi işe almak
- Sektör yalnızca “en iyileri” aramaya eğilimlidir; ama gerçekten önemli olan sistem ve ortamdır
- “En iyi yetenekten” daha önemli olan, takıma ve organizasyona uygun kişiyi bulmaktır
- Hiç zayıf yönü olmayan birinden ziyade, kendine özgü güçlü yanları olan ve organizasyonun çeşitliliğini ve uyumunu artıracak uygun kişilerle takım kurmak daha etkilidir
- Kapsayıcı ve çeşitli ekipler, somut biçimde başarıyı, gelişimi ve uzun vadeli başarıyı beraberinde getirir
- Herkesin işten keyif aldığı, geliştiği ve anlamlı sonuçlar ürettiği yerler gerçek anlamda dünya çapında organizasyonlardır; başarısızlık ve hatalardan öğrenilebilen bir kültürde hem mühendisler hem de organizasyon büyür
- Tam da bu tür organizasyonlar gelecek nesil mühendisleri kendine çeker ve hâlihazırda yetkin insanların da kalmak istediği ortamlar olur
1 yorum
Hacker News görüşleri
Yazılım sahipliği ile teslimatın asgari biriminin mühendislik takımı olduğu görüşüne katılıyorum, ama biraz eksik buluyorum. Bu yapı, mühendislerin yönetici ya da ürün ekiplerine kıyasla ikinci sınıf vatandaş olduğu kültürle bağlantılı. Biz yalnızca teslimattan sorumluyuz; gerçekten anlamlı kararları, takımın çok küçük bir kapsamının ötesinde bağımsız biçimde alamıyoruz. En iyi takımlarda inisiyatif alanı aylarca, hatta yıllarca sürebiliyor; ama çoğu takımda bu birkaç gün ya da birkaç haftaya düşüyor. Oysa gerçekte, mühendislerin gerçek sahipliğe sahip olduğu ve sistemin kırılmadan ya da riskli hale gelmeden uzun süre devam edebildiği bir yapı gayet mümkün. Bunun sırrı, yeterli boşluk payı (slack) bırakmak, kaliteli işi teşvik etmek ve ekipteki herkesin gerektiğinde iş değiştirebilmesi için yeterli özgürlük tanımak. Herkes sahiplik alıp uzun vadeli kararlar verirken aynı zamanda ad hoc iş birliği yapabilir, örtük bilgiyi paylaşabilir; böylece birinin aniden devreye girip yardım etmesi ya da işi tamamen devralması da doğal hale gelir. Deneyimime göre böyle takımlarda sıradan takımlara kıyasla daha fazla rewrite olur, ama genel olarak çok daha üretkendirler. Sistemi küçük parçalar halinde kademeli olarak yeniden yazmak, hem tasarımın evrimi hem de kurum içinde bilgi ve yetkinlik birikimi açısından çok etkilidir. Dışarıdan bakınca israf gibi görünse de, organizasyonun tamamını esnek ve dayanıklı kılan bu boşluk payı aslında vazgeçilmezdir. Hatta tepeden inme organizasyonların sözde israfı azaltmak için koyduğu birçok sürecin, gerçekte bu kritik “slack” alanını yok ettiğine giderek daha çok inanıyorum
Mühendislik dışındaki insanlar, mühendislerin aldığı uzun vadeli kararları doğrudan değerlendiremez ve buna ne tür bir ödül verilmesi gerektiğini çoğu zaman bilemez. Bu durum, aynı mühendislik takımının dışına çıkıldığında bile geçerlidir. İçsel değeri olan uzun vadeli işlerin gerçekten değerli olup olmadığını doğrudan değerlendirme yetenekleri yoktur. Uzun vadeli karar verme ve slack zamanı kullanma konusunda kendine güveniyorsan, teslimat üzerinden ödüllendirilmek yine de kabul edilebilir. Çünkü o uzun vadeli iş, bir gün daha iyi sonuçlar olarak geri dönecektir
Yazılım yeniden yazımının geliştirme sürecinde önemli bir rol oynadığını düşünüyorum. Gerçek anlamda “agile”, ilk mimariyi fazla dert etmeden hızlı prototipler üretmek ve gereksinim değişikliklerine esnek yanıt verebilmektir. Kod yazmak, yazı yazmaya benzer: ilk taslak pürüzlü olsa bile önce ortaya çıkarmak, sonra ikinci versiyonda iyileştirmek çok daha verimlidir. İlk taslağın amacı iyi olmak değil; hızlıca bir şey üretmek, problem alanını keşfetmek ve edge case’leri ortaya çıkarmaktır. Ne yazık ki bu çalışma biçimi yönetim tarafında pek karşılık bulmaz. Çalışan bir prototip gösterdiğin anda “bunu hemen yayına alalım” derler, ama rewrite için zaman vermezler. Çözüm olarak, organizasyon yapısını daha yatay hale getirmek ve kod sahipliğini gerçekten mühendislere geri vermek iyi olurdu. Mühendislerle product owner’ların birlikte, demokratik biçimde karar aldığı bir yapı tercih edilir
Ben de bir zamanlar “bireysel sahiplik” fikrine çok önem veriyordum; bugün de mühendislerin sahiplik alabileceğini düşünüyorum, ama gerçekte birçok mühendisin bunu istemediğini de kabul ediyorum. Çoğu mühendis takım düzeyindeki sahiplikle barışık, ama bireysel mühendis düzeyinde sahipliğe pek ilgi duymuyor. Sonuçta bu sadece bir iş. Bunu bireylere bırakırsan takım içinde güvensizlik yaratabilir ya da liderlik eğilimi olmayan üyeleri dışlayabilirsin; sonunda da kimsenin gerçek inisiyatifi olmadığı bir durum ortaya çıkar. Takım düzeyinde sahiplik ve takdir yetkisi vermek çok daha basit ve etkilidir. Bu, takım lideri ya da yöneticinin varlığıyla mümkün olan bir dinamik aynı zamanda. Yazılım sahipliğini bireylere dağıtırsan, kadro değişimi, istikrar, kariyer gibi etkenler yüzünden başarısızlık riski çok artar. Organizasyon ne kadar sağlıklı olursa olsun büyük küçük sorunlar mutlaka olur; böyle bir yapıda da başarısızlığa giden yol en kısa hale gelir. Bunu bir şanzıman gibi düşünmek kolay: tek dişli varsa bozulduğunda gidemezsin; birkaç dişli varsa rahatsız edici olsa da biri bozulduğunda yol almaya devam edebilirsin
Gerçek anlamda bireysel sahipliğin mümkün olduğunu düşünüyorum. Hatta gerçekten “üretken” olmanın tek yolu bile olabilir. Ama asıl mesele bu değil. Bireyler ikame edilemez olabilir, ama takım üyeleri yapıya bağlı olarak bir ölçüde değiştirilebilir. Organizasyon büyüdükçe takım bazında öngörülebilirlik ister ve bunun için üye değiştirilebilirliği, yani redundancy gerekir. Mühendislikte de güvenilirlik ve dayanıklılık için redundancy kullanılır; verimlilik ise bunu azaltma yönündeki trade-off’tur
Biz, sadece 'delivery'den sorumluymuşuz gibi işleyen bir yapıda çalışırken, sahiplik denilen şey sonunda sadece yük getiriyor, ama gerçek bir karşılığı olmuyordu. İş de sadece bir sayfaya özellik eklemekle sınırlı kalıyordu. Ek sorumluluk gelecekse, buna karşılık ek ücret de olmalı. Yöneticiler ya da üst düzeyler sorumlu oldukları kişi sayısına göre daha çok kazanıyorsa, geliştiriciler için de benzeri geçerli olmalı
En iyi takımların, sıradan mühendislerin olağanüstü sonuçlar üretmesini sağlayan kültürlere sahip olduğuna kesinlikle inanıyorum. Kamuoyunda konuşulan “mühendislik kalitesi” ya da yetenekli insan işe alımından çok, kültür, güven, sistemler ve süreçler daha önemli. “Herkes en iyi mühendislerin olduğu bir organizasyon kurabilir” diye bir söz var, ama pratikte gerçekten böyle takımlar kurabilmiş organizasyon sayısı çok az. Neredeyse hepsi trading şirketleri ya da özel/araştırma odaklı yapılar. İnsan gerçekten neden herkesin bunu başaramadığını merak ediyor. Sonunda “üretkenlik” denen şeyin ne anlama geldiği bile belirsiz kalıyor. Hatta bazen organizasyon içindeki dysfunction’ı kaldırıp aşabilme becerisini ölçen değerlendirme sistemleri var; ama bunun gerçek anlamda “üst düzey mühendis” olmayı tanımladığını düşünmüyorum
Gerçekten olağanüstü mühendis arzı sınırlı olduğu için, eninde sonunda daha büyük şirketler daha ilginç işler ya da daha yüksek maaşlarla aynı insanları çekip alıyor
Başkalarının söylediği para meselesi önemli, ama “zaman” da en az onun kadar büyük bir etken. Şirketlerin mükemmel bir “unicorn” adayı çıkana kadar bekleyecek lüksü yok; çoğu zaman hemen alınabilecek kişilerle pozisyonu doldurmaları gerekiyor. Bazı şirketlerde, özellikle quant finance gibi alanlarda, sistem programcılığı, matematik ve finansal piyasalar uzmanlığını tek kişide birleştiren bir süper mühendis, üç ayrı uzmandan oluşan bir takımdan çok daha fazla değer yaratabiliyor. Ama böyle birini bulmak çok fazla zaman alıyor. Sadece web geliştirmeye baksan bile, ağ protokollerinden sistem yönetimine, dağıtık sistemlerden veritabanına, frontend’e kadar her alanda güçlü kavrayışı olan gerçek bir full-stack geliştirici son derece nadir. Yeterli zamanı ve bütçesi olan organizasyonlar ancak böyle insanları toplayıp en iyi ürünü çıkarabilir. Tabii ürünün gerçekten o düzeyde bir kaliteye ihtiyaç duyup duymadığı ayrı bir soru
Temelde, dünyanın “en iyi mühendis” arzı son derece sınırlı. İlk %10 maaş diliminde ödeme yapabiliyor, bu kalibrede insanları toplayıp elde tutabiliyorsan ne âlâ. Gerçekte bunu “herkes” yapamaz; yöneticilerin öğrenmeye ve büyümeye odaklanan sosyoteknik sistemler tasarlayabilen bir liderliğe sahip olması gerekir. Bu da başlı başına büyük bir başarıdır
En büyük sorun, çoğu birinci ve ikinci kademe yöneticinin o kadar da yetkin olmaması. Üretken bir ortam kurma ve bunu sürdürme becerileri yetersiz. Temel çözüm ise sonuçta daha çok “para” vermek. Para yeterince büyükse, insanlar zor koşulların çoğunu tolere edebiliyor
Bütçe meselesinden bağımsız olarak, gerçekten çok yetenekli mühendisler bazen takım oyunu açısından o kadar da iyi olmayabilir. Çok güçlü zihinler, kimi zaman gerekli uzlaşılara ya da sıkıcı ama zorunlu işlere ayak uydurmakta engel haline gelebilir
“İş etkisi tek üretkenlik ölçüsüdür” iddiasına büyük ölçüde katılamıyorum. Bu bakış açısı odağı ölçülebilir değişikliklere ve kısa vadeli sonuçlara kaydırıyor; böylece deneyimli mühendislerin gerçek değerini gözden kaçırıyor. Gerçek ustalık, bir projeyi ya da şirketi mahvedebilecek riskleri önceden bertaraf etmektir. Ama böyle “ortadan kaldırılmış riskler” ölçülmesi çok zor şeylerdir ve kulağa sıradan gelmeyecek şekilde anlatmak da neredeyse imkânsızdır
“Etki” ille de kısa vadeli bir kavram değil. Bir organizasyonda en büyük etkiyi yaratan kişiler uzun vadeli bakanlardır
Ben “üretkenlik” ya da “etki” gibi kelimeleri bilerek biraz muğlak kullanıyorum. Mesela “genel olarak bakınca X işini gerçekten çok iyi yaptı” gibi. Bunları sayısallaştırmak da, net kurallara bağlamak da zordur; ama zaten karmaşık ve yaratıcı organizasyonlarda insan içgörüsü ve yargısı daha önemlidir. Yönetimi her durumda sayıya dökmeye çalışmak temelde kısa görüşlü bir yaklaşım
Bir mühendisin değerini sadece proje yönetimi ya da riskten kaçınma üzerinden ölçmeye de katılmıyorum, ama her şeyi yalnızca “iş etkisi”ne indirgemek de rahatsız edici. Dünyada para ile ilgisi olmasa da bireyler, insanlık ve dünya için anlamlı çok şey var. Benim en çok saygı duyduğum mühendisler, 2001 sonrası Silikon Vadisi’nin efsane isimlerinden çok John von Neumann, Robert Oppenheimer, Nikola Tesla, Leonardo da Vinci, Roma su kemerlerini ya da Mısır piramitlerini yapan biri, Babil ve Mezoamerika astronomları gibi kişiler. Bunlar iş etkisi mi yarattı? Tesla bir dönem Westinghouse’a kâr getirmiş olabilir, ama bu onun başarılarını açıklamaz. Hatta iş tarafında bakarsan oldukça sıradandır. Günümüz bilişim endüstrisinin devleri için de benzer şeyler söylenebilir. Nvidia ya da Geoff Hinton’ın büyük başarı elde etmesinde, internetin reklamlaşmasıyla verinin patlaması gibi bir “şans” faktörü de vardı. Gerçek ustaların görmezden gelinip kaybolduğu çok sayıda örnek de var. Doug Lenat gibi yapay zeka alanının büyük isimleri bile tarihin akışında hak ettiği görünürlüğü bulamayabiliyor. Başarı ya da başarısızlık çoğu zaman kişinin çabasından bağımsız olabiliyor
Ya verimli sistemler kurarsın ya da felaket ihtimalini en aza indiren sistemler; çoğu zaman bu bir seçimdir. Gerçekte hangi felaketin engellendiğini kanıtlamak da zordur; çünkü olumsuz etki zaten “yaşanmamış bir olay” olduğu için sonuç olarak göstermek kolay değildir
Şirketler, “bilinmeyenler” kaynaklı riskleri olabildiğince daha iyi nicelleştirmeye çalışmalı
Şanslıyım; şimdiye kadar birçok harika takımda çalıştım ve şu anda da böyle bir takımı yönetiyorum. Yazının aksine, bu tür takımların organizasyon tarafından yönetilmesi çoğu zaman daha zordur. Büyük organizasyonlar standartlaşmaya odaklandıkça, çok iyi mühendisler kendilerini tam gösteremez ve motivasyonlarını kaybedebilir. Herkesi mükemmel mühendise dönüştürmenin mümkün olmadığı yönündeki karamsar görüşe katılmıyorum. Gerçekte, istikrarlı yatırım yapıldığında insanlar çok iyi mühendislere dönüşebilir; uzun vadede güçlü bir yetenek havuzuna sahip olmanın getirisi, bu yatırımın maliyetini fazlasıyla karşılar diye düşünüyorum
Bir şeyi etkili biçimde ölçemiyor olmamız, onun var olmadığı anlamına gelmez. Bireysel üretkenlik, yani kişinin iş çıktısı, kesinlikle vardır. Muhtemelen sadece grup düzeyinde üretkenliği ölçmek daha kolaydır. “İş etkisi” ise aslında çok daha keyfi bir ölçü olabilir ve bu tür bir ölçekte gerçekten üretken insanları elde tutmak zorlaşır. Uzmanlığın değerlendirilmesi, eşdeğer deneyim yoksa son derece zordur; tavsiye verebilirsin ama karşı tarafın bunu kabul edecek entelektüel esnekliğe sahip olup olmadığı başka bir meseledir. Benim bir dâhi mi yoksa sadece aşırı özgüvenli biri mi olduğumu nasıl anlayabilirsin
Sorun, üretkenliğin “ölçülememesi” değil; hatta soyut olarak bile “tanımlanamaması”. Sadece bir “replacement”a kıyasla ne kadar fazla katkı yapıldığını ölçmek bile sonucun tam olarak neden öyle çıktığını açıklamaz. Pratikte bireyin etkisi bağlam ve organizasyonun bütünü tarafından belirlenir. Daha doğrudan bir tanım yapmaya çalışsan bile, doğru cevap organizasyona ve duruma göre kökten değişir. Bu üzerine düşünmeye değer bir konu, ama “Top 1%” mühendis kavramının kendisinin gerçekten anlamlı olup olmadığı da ayrıca tartışmalı
Gerçek bir dâhi, kendi sonuçlarını nezaket sınırları içinde kalarak kolayca açıklayabilir. Bu yüzden aradaki farkın yeterince ayırt edilebilir olduğunu düşünüyorum
“Normal mühendislerin harika işler yapmasını mümkün kılan organizasyon en iyisidir” sözü çok hoşuma gidiyor. Takımdaki herkesin süperstar olması gerekmiyor. Asıl önemli olan, ortalama bir geliştiricinin yeterince iyi ve güvenilir bir performans sergileyebilmesi için ne kadar iyi desteklendiği
“Doğru olanı kolay, yanlış olanı zor hale getirin” ilkesi, karşılaştığım tüm platform ekiplerinin temel sloganı gibiydi. Amaç, mühendislerin karşılaştığı sorunlarda “doğru cevap”ın otomatik olarak göze çarpmasını ve kolayca uygulanabilmesini sağlayan sistemler tasarlamak. Güvenilirlik ve yönetilebilirlik sunup, insanları doğal olarak bu yönde geliştiren bir mühendislik “kas hafızası” oluşturabilirsen, bütün organizasyon bundan kazançlı çıkar. Bu ilke bundan sonra da geçerliliğini koruyacak
golang, python, COBOL, lisp, perl, React, brainfuck gibi farklı diller ve framework’ler anıldığında, uzun zamandır insanların React’i tüm frontend ekosistemiyle karıştırma eğiliminde olduğunu düşünüyorum. Oysa React dışında da son derece geniş bir frontend dünyası var; ama sanki herkes React her şeymiş gibi davranıyor
Bizim şirkette her zaman tavrı iyi olan ortalama mühendisleri işe almayı tercih ediyoruz. Nitelikleri iyi ama tavrı kötü olan insanlar, üst yönetimin güvenini kazanmayı ve itibar yönetimini genelde daha iyi beceriyor; sonrasında da dokunulmaz hale geliyorlar. Böyle biri yerleşince, çevresindeki insanlar haksızlığa uğrasa da bunu dile getirmeleri zorlaşıyor. Üst yönetim de kendi algısına uymayan verileri kolayca görmezden gelebiliyor. Çünkü nesnel veriden çok algıya dayanmak her zaman daha kolay
“Herkes en iyi mühendislerle çalışılan bir organizasyon kurabilir ve bireysel yeteneğe aşırı odaklanmak liderliğin gerçek rolünü gölgeler. Daha az deneyimli mühendislerin enerjilerini sonuca dönüştürebilmesini sağlayan sistemler kurmak muazzam bir rekabet avantajıdır” görüşüne gerçekten katılıyorum. Ben 10x mühendis değilim, ama son deneyimlerime göre takımda deneyimi ve becerisi daha düşük çok kişi olduğunda, karmaşık ticket’ların çoğu bana kalıyordu. Bu tekrarlandıkça işin büyük bölümünü tek başıma üstlenmeye başladım; bu da hem yorucu hem de adaletsiz hissettiriyordu. Açıkçası iyi bir SRE’nin biraz tembel de olması gerektiğini düşündüğüm için, takım arkadaşlarımın yükü paylaşmasını çok istiyordum. Bu yüzden birkaç hafta boyunca yoğun çalışıp en karmaşık kısımlara çeşitli soyutlamalar ekledim (ben daha çok IAC ile çalışıyorum; yazılımda da benzer desenler var). Sonrasında, beceri ya da deneyim açısından daha zayıf mühendisler bile benim rolümün bir kısmını üstlenebildi ve ben de zamanımı daha ilginç problemlere ayırabildim. Kimse bana bunu söylemeden ilk kez böyle bir şey denedim. Tersi durumda ise, böyle bir yapı olmadan tek başına kahraman gibi davranırsan, bütün takım senin arkandan gelip hataları düzeltmek zorunda kalıyor ve sonuçta gerçekten verimsiz bir takım ortaya çıkıyor