Yazılımcılar için 48 Güç Yasası
Robert Greene'in kitabından çıkan dersler, işinde daha fazla etki ve saygı isteyen yazılım mühendisleri için yeniden okundu.
Kod tabanında güç
Robert Greene'in tartışmalı kitabı "48 Güç Yasası"nı büyük ihtimalle duymuşsundur. Genelde riskin yüksek olduğu ortamlardaki sosyal dinamiklerin rehberi olarak okunur. Saraylar ve krallıklar için yazılmış o yasaların epeycesi teknoloji dünyasında da karşılık buluyor. Kendini liyakat düzeni sayan bir alanda bile, güç dinamiklerini okuyabilmek insanların etki kurma ve liderliğe geçme biçiminin parçası.
Bir sonraki günlük toplantında Makyavelist planlar kurmanı önermiyorum. Mesele, her kurumda zaten işleyen kuvvetleri fark etmek ve onlara bilinçli davranmak. Aşağıda bu yasalardan dördü, günlerini kod tabanında geçirenler için yeniden okundu.
1. yasa: Efendini, yani tech lead'ini gölgede bırakma
Bizim dünyamızda "efendi" senin tech lead'in, yöneticin ya da kıdemli bir mimar. Zekice bir çözümü göstermek istemek doğal, ama bazı anlarda kazananın üstündeki kişi olmasına izin vermek daha iyidir.
"Ama ben gerçekten iyiyim, niye saklayayım?" diye düşünebilirsin. Mesele yeteneğini saklamak değil, onu nasıl sunduğun. Lead'inin hatalarını sürekli herkesin önünde işaret ediyorsan ya da onun görüşünü sessizce atlayan bir çözümü yayına alıyorsan müttefik kazanmıyorsun, rakip üretiyorsun.
Pratikte bu, yalnızca kusur bulmak yerine çözüm önermek demek. "Kodun verimsiz" ile "Bu fonksiyon için performansı iyileştirebilecek bir optimizasyona bakıyordum" arasında ciddi fark var. Bir başkasının önerisi işini açtıysa bunu söylemek, büyük bir proje sürerken lead'in yönünü gölgelemek yerine desteklemek de aynı kapsamda.
Kendinden emin bir yönetici katkını değerli bulur. Emin olmayan biri onu tehdit olarak okuyabilir. İkisini ayırt edip yaklaşımını buna göre kurmak işe yarar bir beceri.
7. yasa: İşi başkalarına yaptır, ama krediyi hep sen al
Bağlamından koparıldığında sert duruyor. Yazılımcı için yeniden okunduğunda konu delegasyon, mentorluk ve etki: her satırı kendin yazmak yerine başkalarını yetkinleştirerek daha fazlasını bitirmek.
Kıdemli ve lead rollerine geçtikçe daha çok saat kod yazarak ölçeklenemiyorsun. Kaldıraç mentorlukta. Bir junior geliştiriciyi bir problemin içinden geçirdiğinde ve o teslim ettiğinde, sen güçlü bir ekip kurmanın kredisini alıyorsun, o da deneyimi kazanıyor. Kod incelemesi de aynı: hatayı kendin düzeltmek yerine yazan kişiyi düzeltmeye götür. Onun becerisi gelişir, iyileşen kod da ekibin işi olarak görünür.
Mimari için de geçerli. Karmaşık bir sistemin şeklini sen ortaya koyarsın, ekip modülleri yazar, sistem yayına girdiğinde koyduğun yön sonuçta görünür olur.
Amaç tembellik değil, çarpan etkisi yaratmak. Kalıcı kredi, iyi yönlendirilmiş bir ekibin bitirdiği iddialı projelerden gelir.
11. yasa: İnsanların sana bağımlı kalmasını sağla
Kulağa sahiplenici geliyor, ama profesyonel bağlamda anlamı şu: kendini gerçekten değerli ve yeri doldurulması zor hâle getirmek. Seni ekipte kilit taşına dönüştüren beceriler, bilgi ya da ilişkiler.
Bunun bir kısmı iş güvencesi. Bir kısmı da etki. İnsanlar uzmanlığına güvendiğinde görüşlerin daha ağır basar.
Bu birkaç yoldan oluyor. Başkalarının uzak durduğu kritik ya da gözden düşmüş bir sistemin sorumlusu olursun. Kodun ardındaki iş mantığını herkesten iyi bilirsin, birinin "bu neden böyle çalışıyor?" sorusu olduğunda sana gelir. Eski sistemlerin nasıl bağlandığı, kadim bir API'nin tuhaflıkları, bir mimari kararın gerekçesi gibi yazılı olmayan bilgiyi taşırsın. Ya da geliştirme, test, ürün ve operasyon arasındaki köprü olursun; aralarında çeviri yapabilmen ekipler arası projeleri yürütür.
Önemli olan ayrım: bilgiyi saklama. Başkalarının çözemediği problemleri çözen ya da daha hızlı çözen kişi ol.
18. yasa: Kendini korumak için kale inşa etme
Kulaklık takıp editörünün içinde kaybolmak kolay. Derin çalışma iyidir. Tam yalıtım değil, en azından etkin ve gelişimin açısından.
"Ben sadece kod yazmak istiyorum" savunulabilir bir pozisyon. Ama yalnızca kendi ekibinle konuşuyorsan fırsatları ve farklı bakışları kaçırırsın, itibarın da o ekibin sınırında durur.
Birden fazla ekibi ilgilendiren projelere gönüllü olmak ağını genişletir ve sınırların ötesinde çalışabildiğini gösterir. Şirket içi topluluklar, teknik sunumlar ve meetup'lar bildiğini paylaşmanı ve insan tanımanı sağlar. Kod incelemeleri de sosyal bir yüzey: soru sor, yardım öner, kod tabanının başka köşelerini görmek için kullan. Kendi işinin dışında bile yardıma açık olmak zamanla birikir.
Bağlantıda kalmak, fırsatlardan haberdar olmanın, müttefik kazanmanın ve işinin yakın çevrenin ötesinde görünür olmasının yolu.
Kod ve bağlam
"48 Güç Yasası" bir yazılımcı için beklenmedik bir kariyer tavsiyesi kaynağı, ama tarihsel dekoru kaldırdığında geriye sıradan kurum dinamikleri kalıyor. Teknik beceri en önemlisi, ama kararların alındığı seviyeye tek başına çıkarmaya nadiren yetiyor.
Etkinin ekibinin gündelik etkileşimlerinde nasıl işlediğini anlamak seni daha etkili yapar. Oyun oynamak değil, tahtayı görmek.