Kıdemli Bir Mühendis Olmak Üzerine*

*Bu yazı John Allspaw’ın blogundaki “On Being A Senior Engineer” makalesinin çevirisidir.

Alanımızda, özellikle üretken bir mühendis nasıl olunacağı konusunda olmak üzere kurumsallaşmış epey bilgi birikiminin mevcut olduğunu düşünüyorum. Fakat yönetim alanında teknik olmayan yazarlar tarafından yazılmış “uzman” rolleri ve sorumlulukları konusunda yeterli miktarda kitap varken, iyi bir kıdemli yazılım mühendisi nasıl olunacağı konusuna ışık tutabilecek yeterli kitap veya blog yazısı görmüyorum. Tabii ki mühendisliğin kültürel yönleri konusunda son zamanlarda bir hayli yazı yazan Kate Matsudaire dışında.

Aynı zamanda, tanıdığım birçok başarılı mühendis kendilerine “kıdemli” olmanın ne demek olduğunu öğreten mentörlerini hep hatırlarlar.

Arkadaşım Theo’nun O’Reilly’dan çıkan Web Operations adlı kitabındaki bölümünde sarfettiği “kıdemli” hakkındaki sözlerine %100 katılıyorum.

“X nesli (ve hatta Y nesli) anında tatmin nesilleridirler. Sadece zeki oldukları için kendilerini beş yıl içerisinde mühendisliğin en üst basamaklarına çıkaracak “kariyer yolları” beklentisi içinde olan çok miktarda mühendis ile birlikte çalıştım. Tanıdığım birçoğu için bu imkansızdı. Herkes kıdemli olamaz. Eğer, beş yıl sonra bir kıdemli iseniz, işinizin zirvesinde misiniz? İkinci bir beş yılın sonunda paha biçilmez yeni tecrübeler elde etmeyecek misiniz? Sonra ne olacak? “Süper mühendis” ? Beş yıl daha sonra? “Ultra — süper mühendis.” Bu sıkıntıyı disiplinimizin gençliğine veriyorum. Gerçek şu ki web operasyonları sahasında 15 yıl yer alan çok az mühendis var. Endüstrimizin dinamikliği göz önünde bulundurulduğunda birçoğu ya yönetim pozisyonlarına yükseldi ya da çeşitli girişimcilik denemelerinde bulundu.”

Söylediklerinde haklı: Web operasyonları sahası halen oldukça genç. Dolayısıyla “kıdemli” ünvanına sahip birileri — ister teknik olsun ister olmasın — acemi davranışlar sergilediklerinde şaşırmamalıyız. Eğer Theo’nun bölümünü okumadıysanız okumanızı tavsiye ederim.

Bunanla beraber, disiplinimizde “kıdemli” olmak gerçekte ne anlama geliyor? Kıdemli kabul edilen mühendislerin işe alımından, desteklenmesinden ve elde tutulmasından sorumlu olduğum göz önünde bulundurulduğunda, “kıdemli”nin ne anlama geldiği konusunda elbette bir fikre sahibim. Kariyer gelişimi açısından aşılması gereken bir eşiğin olması fikri iyi bir şey, fakat şunu da belirteyim ki bu kriterler basit bir kontrol listesinden çok bir spektrum halindedir. Bir terfi sonrası ünvanınız öyle oldu diye bir sabah aninden “kıdemli” olarak uyanmazsınız. Kıdemli mühendisler herşeyi bilmezler. Meslekî bilgilerinde mükemmel değillerdir ve bu durum onlar için problem teşkil etmez.

Unvanlar ile bulanık beklentileri birbirlerine karıştırmamak için bazen mühendislik olgunluğu ifadesine başvuracağım.

Anlamı: “Kıdemli” bir mühendisin olgun bir mühendis olmasını beklerim.

Olgun bir mühendisin belli bir derecede bilmesi veya uzmanlığı olması gereken teknik alanları (“Networking”, “Dosya Sistemleri”, “Algoritmalar”, vb.) geçeceğim. Onun yerine kuruma veya işe mühendislik sahasında olumlu etkisi olabileceğini düşündüğüm kişisel özelliklerin altını çizeceğim.

Bir keresinde Quora üzerinde bana birisi “İyi bir Teknik Operasyonlar Yöneticisi olmak için (teknik tecrübe ve beceriler dışında) gerekli vasıflar nelerdir?” diye sormuştu. Cevapta belirttiğim vasıflar listesi benim kişisel ideallerimin bir yansıması oldu. Bu yazı da verdiğim cevaba benziyor. Öncelikle şunu diyebilirim ki web geliştirme ve operasyonları sahasındaki kıdemli mühendisler diğer mühendislik sahasındaki (makine, elektrik, kimya, vb) mühendisler ile aynı kişisel özelliklere sahiptir. Dolayısıyla Mühendisliğin Yazılı Olmayan Kanunları bunlar için de geçerlidir. Eğer bu kitabı henüz okumadıysanız, lütfen okuyun. İlk olarak 1944’de yazıldı, American Society of Mechanical Engineers tarafından yayınlandı. Kitaptan güzel bir pasaj için şuraya bakabilirsiniz.

Kitabın yapısı ve metni dönem hissine yol açsa da (“… işyerinde argodan kaçının…” veya “ erkekler traş alışkanlarına, bıyık ve sakallarını kısaltmaya özellikle dikkat etmelidirler…”), teknik olmayan beklentiler, sorumluluklar ve bir mühendislik organizasyonunun iç işleyişini hem yöneticilerin hem de kıdemli mühendislerin davranış şekilleri itibariyle ve ana hatları ile güzel ifade etmiştir.

Olgun Mühendislerde Olması Gereken Temel Nitelikler

Arzulanan nitelikleri anlatmaya çabalayan her yazıda bir sürü maddenin yer alması gerekir ve mühendislik sahası da bunların büyük bir kısmına sahiptir. Dolayısıyla, birazı bana ait, birazı çeşitli kaynaklardan ve epey de yukarıda bahsettiğim Yazılı Olmayan Kanunlar’dan olmak üzere bir miktar yazacağım.

Olgun mühendisler tasarımları için yapıcı eleştiri arayışındadırlar.

Tanıdığım bütün başarılı mühendisler bir tasarımı tamamladıklarında veya bir proje hazırlığında, çalışma arkadaşlarına sürekli şu soruları soracaklardır.

· “Neyi unutmuş olabilirim?”

· “Hangi durumda bu çalışmaz?”

· “Lüften bu konudaki fikirlerimi sorgular mısınız?”

· “Teknik olarak mümkün görünse bile, kurumun geri kalanının kullanabileceği, hatalarını giderebileceği ve üzerine bir şeyler ekleyebileceği kadar anlaşılır bir şey mi?”

Çünkü yaptıkları şeylere günün birinde başkalarının ellerinin de değeceğini bilirler ve daha iyi bir tasarım ancak başka bir çalışma arkadaşının gözden geçirmesi ile mümkün olur. Başka bir yerde denildiği gibi, onlar “kötü haber için yalvarırlar.”

Olgun Mühendisler başkaları tarafından görülen teknik olmayan taraflarının da farkındadırlar.

Erlang dilinde bir Bloom Filtresi veya çok threadli bir C programını gözü kapalı bir şekilde yazabilmek yetmez. Eğer kimse sizinle çalışmak istemiyorsa bunlar bir şey ifade etmez. Olgun mühendisler bilirler ki tasarımları ne kadar tam, ne kadar şık ya da üstün olsa da eğer gıcık biri olmaları sebebiyle kimse yanlarında çalışmak istemiyorsa bir işe yaramazlar. Yukarıdan bakma, küçümseme, kendine hayranlık, ego tatmini gibi davranışlar etrafındaki diğer mühendislere (belki üstü kapalı olarak) uzak dur mesajı verir. Mühendislikte mutlu olmanın bir parçası da bir şeyler tasarlarken veya geliştirirken beraber çalıştığın insanlardan memnun olmaktır. Başka birine kolaylıkla geri zekâlı diyebilen birisi kariyerinde ilerlemesi mümkün olmayan birisi demektir.

Bu aynı zamanda olgun mühendislerin kendi iletişim biçimlerinin farkında oldukları anlamına da gelir. Bu bütün olgun mühendisler mükemmel iletişim kurarlar demek değildir, iyileştirebilecekleri yönleri ile ilgili fikirleri olur ve iş arkadaşları ve yöneticilerinden nasıl oldukları konusunda sürekli olarak geri bildirim isterler. Fikirlerini pasif veya saldırgan olmadan ama aynı zamanda çekinmeden anlatmaya çalışırlar.

Başka bir yerde bahsetmiştim, fakat şimdi daha fazla vurgulamam gerekir: başkalarının sizinle birlikte çalışmayı isteme derecesi, bir mühendis olarak kariyerinizde ne kadar başarılı olacağınız doğrudan göstergesidir. Herkesin birlikte çalışmak isteyeceği bir mühendis olun.

Ama birini rahatsız etmekten korkarak ortaya konan iş hakkında (kişiselleştirmeden) yapıcı eleştiri yapmaktan (veya almaktan) da çekinmemelisiniz. Birilerine gerizekalı demek ile kodundaki veya ürünündeki bir hataya işaret etmek aynı şey değildir. Theo bir konuşma sırasında disiplinimizin gelişme gösterebileceği başka muhtemel bir alana işaret etmişti:

“Bir endüstri olarak biz insan karakteri ve durumu hakkındaki eleştirilerden kaçınmalıyız, fakat iş ile ilgili eleştirilerden çekinmemeliyiz. Cildimiz daha dayanıklı olmalı ve kişisel olanları ayıklayan bir mercek yoluyla eleştirileri alabilmeliyiz.

Gıcık insanlar hep olacaktır, onlardan uzak durulmalı. Fakat birisinin kodu onun bebeğidir yaklaşımı artık sona ermeli. Kodun duyguları yoktur, saplantıları olmaz ve sizin genetik özelliklerinizi taşımazlar.”

Ayrıca aşağıda Egosuz Programcılığının On Emirinden 2 ve 10 numaraya bakınız.

Bence bunda Yazılı Olmayan Kanunların doğal bir sonucu var (vurgu bana ait):

Eğer başka departmanlar da bir şekilde ilgiliyse, mektuplarda ve not gibi şeylerde kimlerden bahsettiğinize dikkat edin.

Gençlerin zarar verici veya utandırıcı cümleler içeren bilgi notları birçok fitneye yol açtı. Elbetteki bir çaylağın böyle bir metindeki “dinamiti” farketmesi çok kolay değil fakat, genel olarak birisinin ayağına çok fazla basıyorsa veya ciddi bir kusuru açığa vuruyorsa bir karmaşaya yol açması muhtemeldir. Bir çok kişiye ulaşacaksa ya da üretim veya müşteri problemleri ile ilgiliyse ve çok emin değilseniz patronun onayını almanız iyi olur.

Burada şüphesiz kitabın yazıldığı dönemin havası hissediliyor, fakat içinde bulunduğumuz modern çağda ana fikrin halen geçerli olduğuna inanıyorum. Bakış açısı ve farkındalık bakımından gelişmemiş olduğunuzu, düşmanca hakaretler içeren düşüncesizce atılmış bir tweet kadar iyi ifade eden bir şey yoktur. Karmaşık bir teknolojiye 140 karakterle hakaretler yağdırmak ancak bir çaylak mühendis hatasıdır.

Ben de (Christopher Brown’nın Velocity London konuşmasında bahsettiği gibi) bunun gibi herkese açık yapılmış yorumlarla karşılaştığım zaman hemen bunlara odaklanıyorum. Böylece isimleri not edebilir ve Etsy’ye başvururlarsa işe almayı tekrar değerlendirebilirim.

Olgun mühendisler tahminleme yapmaktan çekinmezler. Aksine sürekli olarak bu konuda kendilerini geliştirmeye çalışlar.

Yazılı Olmayan Kanunlar’dan:

Vaatler, takvimler ve tahminler düzenli bir işte önemli ve olmazsa olmaz araçlardır. Birçok mühendis bunu yeteri kadar idrak edemiyor, ya da alışkanlık olarak taahhütlerde bulunmanın can sıkıcı sorumluluğunu başlarından savuşturmaya çalışıyorlar. Diğer paydaş bölümlerin kendi kısımlarına ait tahminleri ile sizin işin kendi sorumluluğunuzda olan kısmı için yaptığınız tahminlerinize birlikte dayanacak şekilde taahhütlerde bulunmanız gerekir. Hiç kimsenin bu konudaki “bir sürü belirsiz faktör bulunduğu için herhangi bir söz vermemiz mümkün değil” eski formülü ile bu sorumluluktan kurtulmaya çalışmasına izin verilmemelidir.

Tahminleme sorumluluğundan kaçınmak “kritik bir altyapı parçasının geliştirilmesi sorumluluğunu üstlenmeye hazır değilim” demenin başka bir yoludur. Tüm faaliyetler tahminlere dayanır ve bir projede çalışan bütün mühendisler, diğerleri tarafından tahmin edilebilir olma sorumluğuna sahip oldukları anlamına gelen bir Ortak Çalışma’ya dahildirler. Genel olarak olgun mühendisler belli bir miktarda belirsizlik ve risk ile çalışma konusunda rahattırlar.

Olgun mühendislerin doğal bir öngörü hisleri vardır, farkında olmasalar bile.

Bu kod güzel görünüyor, kendimle gurur duyuyorum. Diğerlerinden kodu gözden geçirmelerini rica ettim, ve yorumlarını dinledim. Şimdi: yeniden yazılmasına ne kadar zaman var, kod çalışırken kaynak kullanımını nasıl olur? Ne kadar işlemci/bellek/disk/ağ kaynağı kullanım artışı veya düşüşü bekliyorum? Diğerleri bu kodu anlayabilecek mi? Diğerlerinin bu koda ekleme yapabilmesi veya onu kavrayabilmesini yeteri kadar kolaylaştırdım mı?

Olgun mühendisler bütün projelerinin harika çalışmalar ile dolu olmadıklarını bilirler.

İlk görevleriniz ne kadar basit ve önemsiz görünürse görünsün, elinizden gelen en fazla çabayı sarfedin.

İşleri halletmek demek, belki de hoşlanmadığınız bir sürü işi yapmak demektir. Proje ne kadar çekici olursa olsun her zaman sıkıcı işler vardır. Daha az olgun mühendislerinin kendilerine veya unvanlarına yakışır bulmadıkları işler. Değerli arkadaşım Kellan Elliot-McCrea (Etsy’nin CTOsu) şöyle demişti:

“Bazen sıkıcı bir işin iyi yanı onları hızlıca bitirip bir sonraki işe geçmekte kendini gösteren basitlik ve olgunluktur. Bazen işler yüksek disiplin ve dikkat gerektirdikleri için sıkıcıdırlar. Gariptir ki sadece en kıdemli mühendisler tarafından gerçekleştirilebilen çoğu sıkıcı iş aynı zamanda en korkutucu olabilenlerdir.”

Olgun mühendisler çevresindekilerin becerilerini ve uzmanlıklarını arttırırlar.

Kendi bireysel katkıları ve potensiyellerinin bir yerden sonra tek başına işe yarayamayacağını kabul ederler. Tek bir kişi tarafından yapılabileceklerin sınırı olduğunu ve dünyanın en önemli mühendislik eserlerinin parlak ve yalnız mühendisler tarafından değil takımlar tarafından geliştirildiğini bilirler. Tom Limoncelli bu konuyu yazısında gayet güzel anlatmış.

Etsy’de biz buna “ruhun cümertliği” diyoruz. Ruhun cömertliği bizim en temel mühendislik değerlerimizden biri olmakla birlikte kariyer basamaklarımızdan biri olan Personel Mühendisi pozisyonumuzun da ana sorumluluğudur. Bu mühendisler mesailerini teknolojiye ve süreçlere yabancı tecrübesiz mühendislerinin ne yaptıklarını ve niçin yaptıklarını anladıklarından emin olmak için harcarlar. “Balık tutmayı öğretmek” bu basamakta mecburi bir yetenektir, bu da hem sabır hem de kurumun geri kalanı için yatırım yapma bakış açısını gerektirir.

Dolayısıyla, “peki, kenara çekil, senin yerine halledeyim” demek yerine “hadi biraz birlikte çalışalım. Nasıl yazdığımı, problemi nasıl çözdüğümü sana gösterebilirim. Sonrasında sen de yapabilirsin ve senin bu işi neden/nasıl yaptığımızı bildiğinden emin olabilirim, vs.”

İlgili olarak: Aşağıdaki takdir konusuna bakınız.

Olgun mühendisler bir değerlendirme yaparken veya bir karar verirken feda ettikleri ve karşılığında kazandıkları konusunda şeffaftırlar.

Bütün mühendislik karar, tasarım ve uygulamalarının geniş bir yelpazeye yayılmış olduğunun farkındadırlar; ikili bir dünyada yaşamıyoruz. Başarılı bir yaklaşımın veya çözümün çalışabileceği veya çalışamayacağı şartları hızlıca tarif edebilirler. Aynı zamanda hem verimli hem de eksiksiz olunamayacağını ( ETTO İlkesi), mühendislerin çalıştığı çoğu projenin optimumluk ile kırılganlık ekseninde yer aldığını ve çözdükleri problemin akut mu (sonradan olma — geçici) yoksa kronik mi olduğunu bilirler.

İdeal ve ideal olmayan durumlar yelpazesinde çalıştıklarını bilirler ve bu durumdan rahatsız değildirler. Çünkü ideal ve ideal olmayan durumları tasarımlarında görünür kılmaya çaba gösterirler. Bir tasarımın ilerleyen safhalarında, ilk tasarım artık ölçeklenemez hale geldiğinde veya değiştirilmesi ya da yeniden yazılması gerektiğinde, en başta tasarım kararlarının ne kadar kısa görüşlü olduğunu söylemek yerine “evet şimdiye kadar böyle yapmıştık ve günün birinde değiştirmemiz gerektiğini biliyorduk, anlaşılan o gün gelmiş, hadi işe koyulalım” derler. Aksi, edilgen-saldırgan, gerçek dışı argümanlarla (“bu aptallar ilk seferinde doğru yapmamışlar!”, “bunun çalışmayacağını SÖYLEMİŞTİM” gibi) desteklenmiş, geri bakış eğilimi (hindsight bias) dolu yorumlardan kaçınırlar.

Bu duruma ışık tutan bir sürü özlü söz vardır ve olgun mühendisler felsefe yüklü bu sözlerin de belli sınırları olduğunu bilirler (aşağıya yazdıklarım dahil):

· “Zamanı gelmeden yapılan optimizasyon bütün kötülüklerin başıdır.” Çok fazla istismar edilmiş bir özdeyiş olup bu konuda daha önce yazmıştım. Bunun doğal sonucu belki şu olabilir (buradan alınarak): ‘Zamanın geldiğini anlayabilmek kıdemli mühendis ile çaylak mühendisi birbirinden ayıran şeydir’

· “İş için doğru araç” — istismar edilmiş bir diğer özdeyiş. Buradaki niyet mantıklı: uygun olmayan bir aracı kim kullanmak ister? Fakat ender bir bakış açısı şu ki uç durumlarda bakıldığında bu yaklaşım ölümcül olabilir. Bir marangoz, her birinin ayrı ayrı işe yarayacağı durumlarla karşılaşıyor olsa bile, farklı boyut ve türlerdeki tüm çekiçlerle kendisini donatmaz. Neden? Bir sürü çekici oradan oraya götürmenin, bakımıyla uğraşmanın da bir maliyeti var. Sonuç olarak bu eksendeki kararlarda bir fayda-maliyet hesabı vardır.

Uzun lafın kısası herkes bütün projelerde zaman zaman kolaya kaçar. Olgun olmayan mühendisler durumu sonradan farkeder, tiksinir. Olgun mühendisler ise proje başlangıcında bunları dile getirir, kabul eder ve iyi mühendisliğin bir parçası olarak görür.

(İlişkili yazı: Senin Kodun Müthiş Olabilir, Ama Benimki Çalışıyor)

Olgun mühendisler kendi kıçını kurtar politikası gütmez.

Kendi yazdığı bir kodun (veya bir altyapının) sistemin diğer parçalarıyla nasıl etkileşeceği üzerinde kafa yormamak için resmi süreçleri bahane etmek her zaman kaybettirir. Kendi kıçını kurtarmaya çalışmak sizin, yaptığınız bir işte hata olduğunu ima edecek en küçük bir durumla karşılaştığınızda diğerlerini (takımınızdakiler? şirketinizdekiler? topluluğunuzdakiler?) o meşhur otobüsün altına atmayı isteyecek biri olduğunuz mesajını etrafınıza yayar. Olgun mühendisler ayağa kalkar ve kendilerine verilen sorumluluğa sahip çıkar. Eğer işlerden sorumlu tutulabilecek kadar yetkilerinin olmadığını görürlerse bunu düzeltecek yollar ararlar.

Bu duruma örnek olarak “bu benim hatam değil, onlar bozdu, yanlış kullandılar. Benden istendiği şekilde geliştirdim, onların hataları veya eksik tarif sebebiyle ben sorumlu tutulamam” sözleri gösterilebilir.

Olgun mühendisler empati kurarlar.

Karmaşık projelerde genellikle birçok paydaş bulunur. Herhangi bir projede, tasarımcıların, ürün yöneticilerinin, operasyon mühendislerinin, geliştiricilerin ve iş geliştirme uzmanlarının hepsinin hedef ve bakış açıları vardır ve olgun mühendisler bu hedef ve bakış açıların farklı olabileceğini bilirler. Bu anlayışları sebebiyle çalışmalarında etkin bir şekilde yol alırlar. Bu manada empati kurabilmek demek projeyi diğerlerinin bakış açısı ile görebilmek ve bunu kendi çalışmalarında göz önünde bulundurabilmek demektir.

Hedeflerin çatışması tüm mühendislik projelerinin doğasında vardır ve bunlardan (başarının bir önşartı olarak benimsemek yerine) şikayet etmek olgun bir mühendis olmamanın işaretidir.

İçi boş şikayetlerde bulunmazlar.

Aksine, hükümlerini somut kanıtlara dayalı olarak verirler ve beraberinde kendi çözüm önerilerini de sunarlar. Beğendiğim bir yöneticim patronuna yanında en az bir (birden fazla olsa daha iyi) çözüm önerisi olmadan bir şikayetle asla gitme demişti. Hatta problem üzerinde kendi başınıza çalıştığınızı ama bir şey elde edemediğinizi göstermeniz bile kuru şikayetten iyidir.

Olgun mühendisler bilişsel eğilimlerin[1] farkındadırlar

Bu bütün olgun mühendislerin psikolojide derecesi olmalı demek değildir, fakat bilişsel eğilimler bir mühendisin kariyer gelişiminin belli bir noktada takılmasına yol açabilir. Dışarıya nasıl yansıdıklarının veya bunlarla nasıl mücadele edebileceklerinin detaylarını bilmeseler bile, tanıdığım çoğu olgun mühendiste bu eğilimlere (herkes gibi) elverişli olduklarını görecek kadar en azından bir farkındalık var.

Kültürel olarak, mühendisler günlük işlerinde deneysel bulgular ile çalışırlar. Basitçe: bana veriyi göster. Bilişsel eğilimler ile ilgili mesele şu ki bizler verileri kendi beynimizde deneysel bulguların aksine yorumladığımızın farkında olmayabiliriz ve bunun iş yapış şeklimiz ve takımlarımız üzerinde şaşırtıcı etkileri olabilir.

Bunlardan uzunca bir liste Wikipedia’da mevcut, fakat (kendim dahil) yazılımcıların tuzağına düştüğünü gördüğüm bazıları şunlar:

· Kendine Hizmet Eğilimi — temel olarak: eğer bir şeyler iyi gidiyorsa, büyük ihtimalle benim yaptığım veya düşündüğüm birşeydir. Eğer kötü gidiyorsa büyük ihtimalle başka birinin işidir.

· Temel Atfetme Hatası — temel olarak: eğer başkalarının işleri kötü giderse bu onların kişisel olarak nasıl biri oldukları (aptal, sakar, dikkatsiz) ile ilgiliyken eğer benim işlerim kötü giderse içinde bulunduğum şartlar, baskı altında olmam gibi şeylerden kaynaklanıyordur.

· Geri Bakış Eğilimi — (modern psikoloji tarihinde üzerinde en çok çalışan olgunun bu olduğu söylenir) temel olarak: nahoş veya olumsuz bir olaydan sonra (kritik bir hata, bir kesinti, vs) “en başından beri biliyordum” demek. Geçmişi gerçekte olduğundan daha basit görmek çok güçlü bir eğilimdir. Bir konuşmanın içerisinde “öyle olmasaydı böyle olmazdı…” veya “şöyle yapmaları gerekirdi” veya “bunu nasıl göremediler, çok açık!” gibi ifadeler geçiyorsa orada Geri Bakış Eğilimi olduğunu söyleyebilirsiniz.

· Sonuç Eğilimi — diğerleri gibi bu da beklenmedik veya kötü bir olaydan sonra görülür. Eğer bu olayın sonuçları çok ağırsa, temizlemesi maliyetli ise veya çok kritik ise bu olaya götüren kararlar veya hareketler çok aptal, düşüncesiz ve ihmalkar olmakla itham edilir. Suçlama miktarı olayın kötülük derecesi ile orantılıdır.

· Planlama Yanılgısı — (yukarıda bahsedilen belirsizlik altında tahminleme yapmak ile ilgili) temel olarak: belli bir projenin ne kadar süreceğini tahmin sırasında daha fazla iyimser olmak.

Kişisel olarak etkileyici bulduğum ve daha fazla öğrenirken içinde kaybolabileceğim başka birçokları mevcut. Kendi verimliliğinizi nasıl limitliyor olabileceğiniz hakkında öğrenmeye biraz meraklıysanız mutlaka okumanızı tavsiye ederim.

Egosuz Programlamanın On Emri

Eski bile olsa halen geçerli. 1971 yılında yazılmış The Psychology of Computer Programming’de atıf yapıldığını görmüştüm fakat metinde göremiyorum. Herneyse, işte size @wyattdanger babasından aldığı tavsiyelerle yazdığı blog yazısında bulunan Egosuz Programlamanın On Emri:

1. Hata yapacağını anla ve kabul et. Önemli olan onları üretim ortamına çıkmadan önce erken bulabilmek. Neyseki, JPL’de roket güdümleme yazılımı yapan küçük bir azınlığımız dışında, yaptığımız hataların nadiren ölümcül sonuçları olur. Öğrenip, gülüp geçebiliriz, geçmeliyiz.

2. Sen kodun değilsin. Unutma ki gözden geçirmenin asıl amacı hataları bulmaktır ve hatalar bulunacaktır. Birisi bulunduğunda bunu kişiselleştirme. (Allspaw’un notu — ilgili: aşağıda, 10 numara, ve de Theo’un yukarıda işaret ettikleri.)

3. Ne kadar “karate” bilirsen bil, senden daha fazla bilen biri vardır. böyle birisi eğer istersen sana yeni hareketler öğretebilir. Başkalarından birşeyler öğrenmeye çalış, özellikle ihtiyaç olmadığını düşündüğünde.

4. Danışmadan kodu baştan yazma. “Kodu düzeltmek” ile “baştan yazmak” arasında ince bir çizgi var. Farkı gözet ve şekilsel değişiklikleri bir kod gözden geçirme çerçevesinde içerinde yürüt, tek başına zorlayan biri olarak değil.

5. Senden daha az bilgi sahibi insanlara karşı saygı, hürmet ve sabırla davran. Yazılımcılarla düzenli ilişki içerisindeki teknik olmayan insanların neredeyse tamamı yazılımcıların en iyi halde nazlı, en kötü halde ise mızmız oldukları görüşüne sahiptir. Bu basmakalıp bakışı öfke ve sabırsızlıkla güçlendirme.

6. Dünyada değişmeyen tek şey değişimdir. Değişime açık ol ve onu gülerek karşıla. İhtiyaçlar, platform ve araçlardaki her bir değişikliğe savaşılması gereken rahatsız edici bir durum olarak değil yeni bir meydan okuma olarak bak.

7. Doğru otoritenin kaynağı yalnızca bilgidir, pozisyon değil. Bilgi otoriteyi doğurur, ve otorite saygıyı doğurur. Dolayısıyla egonun olmadığı bir ortamda saygı istiyorsan bilgiye yatırım yap.

8. İnandığın şeyler için mücadele et ama yenilgiyi güzellikle kabul et. Bazen fikirlerinin aksine kararlar alınacağını unutma. Haklı olsan bile, asla intikam peşinde olma veya “ben demiştim” deme. Benimsenmemiş bir fikrini verdiğin yüce bir kayıp olarak görme.

9. “Dipteki kodcu” olma. Karanlık ofisteki sadece soda için ortaya çıkan kişi olma. Dipteki kodcu gözlerden, temastan ve kontrolden uzaktır. Bu kişinin açık, işbirliği yapılan bir ortamda hiçbir sözü yoktur. Muhabbete dahil ol ve ofisteki sosyal ortamın bir ferdi ol.

10. İnsanları değil, kodu eleştir — koda karşı değil kodcuya karşı nazik ol. Elinden geldiği kadar olumlu ve kodu iyileştirmeye yönelik yorumlar yapmaya çalış. Yorumlarını standartlar, programın özellikleri ve performans artışları gibi şeylerle ilişkilendir.

Kirli sır: olgun mühendisler başkalarının (bazen rasyonel olmayan) duygularının önemini bilirler.

İnsanların teknolojiler, teknik kararlar ve teknik gidişat hakkında nasıl hissettikleri işin detaylarındaki gerçekler kadar önemlidir. Olgun mühendisler bunu bilir ve gerektiği şekilde kendini ayarlar. Tekrar diyorum ki empati kurmanız, neden bu şekilde hissetiklerini aktarmaları için uygun bir vakit bulamasalar bile, takımınızdaki başka birinin teknik kararlar hakkında ne hissettiğini anlamanıza yardımcı olur.

İnsanın yazılım, mimari ve yöntemlerdeki özgüveni ağırlıklı olarak geçmiş tecrübelerinden etkilenir ve bunları kullanmaya karşı olumlu veya olumsuz tepkilere yol açabilir. mod_perl’ün yoğun olarak kullanıldığı ve bir sürü esrarengiz kesintinin yaşandığı bir şirkette mi çalıştınız? Öyleyse, kullanılma biçimi ve bu konudaki uzmanlık tamamen farklı olsa bile, başka bir şirkette onu kullanmaya gönülsüz olmanıza şaşırmamalısınız. Tek hatırladığınız mod_perl’ün bir sürü baş ağrısına yol açtığıdır ve herhangi bir yerde onu tekrar kullanırken çok temkinli olursunuz.

Olgun mühendisler -bir takım sıkıntılarıyla beraber gelen- bir teknolojinin kullanılmasını istediklerinde, irrasyonel olsa bile, yaşanacakları anlayışla karşılarlar. İnsanların kendilerini rahat hissetmedikleri araçları veya teknikleri kullanmaya ikna etmek basit bir iş değildir. “İş için doğru araç” özdeyişinin bir parametresi de (bazen ölçülemese de) bu araçla kendini rahat hissedebilmektir.

İnsanların hislerinin teknik kararları ve fikirleri nasıl yönlendirdiğine bir örnek olarak, herhangi bir konudaki ateşli tartışmaları oku

“Takdir edilenin kim olduğunu umursamazsanız harika şeyler başarabilirsiniz”

Bu alıntı genellikle Harry S. Truman’a atfedilse de, sanki ilk olarak bir Cizvit papazı tarafından başka bir şekilde söylenmişe benziyor. Herneyse, bu da sizin olgun bir mühendisle çalıştığınızın başka bir göstergesi: onlar projenin başarısını bu proje sonunda elde edebilecekleri muhtemel kişisel övgüden daha yukarıda tutarlar. Övgünün ve takdirin atfedilmesi bir mühendislik şirketinde huzursuzluk kaynağı olabilir ve inanıyorum ki bu çoğu zaman mühendisin başarısı işin başarısının karşısında görünmez oluşundan kaynaklanır.

Ana fikir serbestliktir ve anlaşılıp içselleştirildiğinde, bir sürü ilerleme ve yenilikçi düşünce yeşerebilecek. Çünkü mühendisler yaptıkları işleri kendi kariyer başarılarına eşitlemeye çalışmayı çok fazla umursamazlar.

Son Değil

Şuan Etsy’de bir çok olgun mühendisle birlikte çalıştığım için çok mutluyum ve bu oldukça gurur verici. Yazılım gerçekten yeni bir alan ve bana göre diğer mühendislik alanlarından bu konuda öğrenebileceğimiz çok şey var. Web, bilginin dünya çapında yayınlanması ve paylaşılması kavramlarıyla derinden ilişkili. Alanımızın gerçek bir disiplin olmaya doğru gelişmesini istiyorsak “kıdemli” ve “olgun” mühendisliğin ne anlama geldiği konusuna eğilmeye devam etmemiz gerekiyor.

Etys’deki Operasyon takımına, bu yazının taslaklarını gözden geçiren Mike Brittain, Kellan Elliott-McCrea, Marc Hedlund, ve Theo Schlossnagle’a çok teşekkürler. Hepsi benim daha olgun bir mühendis olmama yardımcı oldular.

[1] ‘Cognitive Bias’ terimi Türkçe’ye daha önce bilişsel yanılgı, bilişsel tuzak, bilişsel yanlılık, algısal sapma, düşünsel tuzak gibi farklı şekillerde çevirilmiş ama bu konuda bir mutabakat olmayışı ve temelde zihnimizin dış dünyadan gelen verileri belli yönlere doğru yorumlayama daha eğilimli oluşu kastedildiği için ‘bilişsel eğilim’ çevirisini tercih ettim [ÇN].