Neden bu konuda yazıyorum?
Stoacılık ile Marcus Aurelius’ın hayatını araştırırken tanıştım. Merakım, Seneca ve Epiktetos ile devam etti. Aslına bakarsanız Stoacılık ile ilgili araştırmalarım ve okumalarım hâlâ devam ediyor. İş böyle, okumalarımı yaparken, Stoacı Felsefe’nin yazılımcı ve günlük yaşamdaki karakterlerimin arasındaki tutkal olabileceğini fark ettim. Bu konuya odaklanıp bir güzel irdeledikten sonra, çıktılarımı, “iyi bir yazılımcı olmak için Stoacı Felsefe’yi nasıl kullanırız” başlığı altında derlemeye karar verdim. Okumaya değer bulduğunuz için şimdiden teşekkür ederim.
Stoacılık ne diyor?
Bir şeyi gönül rahatlığıyla söyleyebilirim ki; “kaliteli bir yazılım üretmek için bir yazılımcı, çelik gibi bir irade, savaşçı bir ruh ve yüksek seviyede duygularını kontrol etme yeteğine sahip olmalı.”
Çelik gibi bir irade, yazılımcının yolunu, öğrenmek ve gelişmek konusunda açacak. Savaşçı bir ruh ise, yazılımcıya problemler karşısında yılmama ve en zorundan hiç korkmama özelliklerini katacak. Yüksek seviyede duygularını kontrol etme ise, kaliteli bir stres yönetimi ve çatışmaları uzmanca çözme özelliklerini kazandıracak.
Bu 3 özelliğe ulaşmak için kullanabileceğimiz, Stoacılık’ın bize söylediği bir kaç bilge söz var. Gelin bunların her birini detaylıca inceleyelim ve bu savları yazılım dünyasına nasıl uyarlayabileceğimiz konusunda biraz fikir yürütelim.
- Belirsizliği kabul et.
- Yolculuğun kendisi, varacağımız yerden daha önemlidir.
- Karşımıza çıkan zorluklar, bizi eğitir, güçlendirir.
- Kötü duyguların seni kontrol etmesine izin verme.
- Erdemli bir yaşam için sürekli öğren.
- Bilgeliği aktar.
Belirsizliğin Kabulu Üzerine
Stoacı felsefe, yalnızca düşünce ve eylemlerimizi kontrol edebileceğimizi söyler. Bir Stoacı için gelecek bilinmezdir. Kendi konrolünde olmayan şeyler için debelenip iç huzurunu kaybetmek yerine, erdemli bir yaşam için, her ne işle uğraşıyorsa uğraşsın, o işi elinden gelenin en iyi haliyle yapmak, bir Stoacı için idealdir.
Burada sınırları biraz aşacağım ve belirsizliği kabul etmeyi dilim döndüğünce yorumlayacağım. Belirsizliği kabul etmek, ona boyun eğmekten çok, onu anlamak ve onu iç huzurumuzu bozacak bir etken olmaktan men etmek demek.
Yazılıma gelelim şimdi. Belirsizlik… Aklımıza gelen ve anlamamız gereken ilk belirsizlik, bence yazılımın bir ürün haline gelmesinin en büyük temeli olan “isterler“… İsterler, her ne kadar belirliymiş gibi dursa da, onları değişmeye itecek bir çok değişkene bağlılar. Demem o ki; çok tecrübeli bir takım tarafından da oluşturulsalar, isterler, projenin ilerleyen aşamalarında toplanan bir son kullanıcı datasına dayanarak dahi değişime uğrayabilirler. İşte tam da burada, isterlerin yalnızca geliştirilmesi işleminin biz yazılımcıların kontrolünde olduğunu, isterlerin değişmesinin ise bizim kontrolümüzde olmadığını kabul etmemiz gerekir.
Peki isterlerin belirsizliğini kabul eden bir takım ne yapar? Kodun sık değişimlere karşı korunmasını, Unit ve integration testler yaparak sağlarlar. Ürün takımlarına, isterleri kabul etmeden önce daha fazla soru sorarlar ve isterlerin olabildiğince olgunlaşmasını sağlarlar. Sistemlerini, bağları kolayca koparılıp tekrar kurulabilecek şekilde yazarlar ve böylece değişen isterler, kodun yalnızca izole edilmiş alanlarına dokunurlar. Kısacası, köklü bir değişime uğramış isterlerden etkilenen ve yaşamları sonlanan modüller, bir kaç satır silinerek projeden sağlıklıca çıkarılabilirler. Tüm bunların sonunda, isterlerin değişebileceğinin sürecin bir parçası olduğunu kabul eden yazılımcı, içinden büyük bir motivasyon düşmanını sürgün etmiş olur. Günün sonunda isterler değişir, ürün takımları da bu değişimlerin etkilerini en aza indirir.
Bir diğer kabul edilmesi gereken belirsizlik ise, üçüncü parti yazılımlar. Bu tür yazılımları kullanıyoruz, kullanacağız ve biz de geliştirip kullandıracağız. Çok basit bir örneği ele alalım, Facebook SDK… Facebook ile login olunmasını sağlamak için mecburen uygulamamıza entegre etmek zorundayız. Bir üçüncü parti yazılımı uygulamamıza bir kere aldıktan sonra, onunla kurduğumuz bağ kadar güçlü oluyoruz. Sözü çok uzattım; “üçüncü partilerin uygulamamıza etkileri belirsiz ve bizim kontrolümüz dışındadır.” demek istiyorum. Peki, buradaki belirsizliği anlayan bir yazılımcı ne yapar, gelin oraya odaklanalım. Üçüncü partileri uygulamalarına ekleyen yazılımcılar, üçüncü partiyi tek bir uzaktan değiştirilebilir değişkenle anında kapanabilir yazarlar. Üçüncü partiler ile gerekirse aralarına bir wrapper yazarlar ki, kriz anlarında üçüncü partiyi çok kolayca değiştirebilirler. Biraz daha açacak ve daha derin bir örnek verecek olursak, bir reklam servisi üçüncü partisi, uygulamamıza eklenirken, kendi yazdığımız bir reklam servisi modülüne bağlanırlar. Günün sonunda, uygulama reklam göstermek için bize ait olan servisin reklam göster fonksiyonunu, bu reklam göster fonksiyonu da eklediğimiz üçüncü partinin reklam göster fonksiyonunu tetikler. Üçüncü parti reklam servisi değiştiğinde, bir kaç satır kod değişir ve uygulamanın hayatı devam eder.
Yazılımın bir diğer önemli ve anlaşılması gereken belirsizliği ise, aynı zamanda diğer belirsizliklerin de temelinde yer alan insan faktörüdür. Takımlarla çalışırız. Birbirini tanımayan onlarca insandan, aynı hedefe koşmalarını ve sağlıklı bir ürün çıkarmalarını bekleriz. Bu birbirini tanımayan insanların, hedefe giden yolda aralarındaki çatışmaları çözmelerini, birbirlerini desteklemelerini bekleriz. İnsan… Belki de belirsizliğini kabul etmemiz gereken en önemli unsur… Peki insanın bir belirsizlik olduğunu kabul eden yazılım takımları ne yaparlar? Sürekli tekrar eden işleri otomatize ederek, insanın hata payını düşürürler. İnsanların kendini daha iyi hissedeceği bir iş fırsatı ile takımdan ayrılabileceğini ve bunun ne zaman olacağının kestirmesi zor bir belirsizlik olduğunu bilerek, bilgiyi takımdaki bireyler arasında dağıtır, alan uzmanları yaratmazlar. İnsanlar arası çatışmaları çözmek için standartlar oluşturur ve bir çok çatışmayı daha doğmadan çözerler. Atılan tüm bu adımlar, takımların dengelerini en kolayca bozan etken olan suçlama kültürünü de ortadan kaldırmaya başlar.
Yukardaki savımı gerçek bir örnekle pekiştirmek isterim. Gelin build alma sürecini ele alalım. Projenin build alınması ve release çıkılmasından Code takımının sorumlu olduğunu hayal edin lütfen. Build alma sorumluluğu çoğunlukla Nihat’ta olsun. İlk senaryomuzda, Nihat build alırken sürüm kodunu yanlış giriyor. Sürüm kodu bir anda hiç istemediğimiz ve standartlarımıza uymayan bir şekilde artıyor. Eğer sığ bakacak olursak, bu durumdan Nihat’ı suçluyoruz ve ona bir daha yapmaması üzerine geri bildirimlerde bulunuyoruz. Nihat’ın ne kadar kötü hissettiğini tahmin edebiliyorum. Bu durumu engellemek ve insan faktörünü ortadan kaldırmak için build süreçlerimizi otomatize etmeliydik, sürüm de otomatik olarak her release çıktığımızda artmalıydı. İkinci senaryomuzda ise, Nihat hasta oluyor. Nihat’a zorunlu olarak 1 hafta izin veriyoruz. Fakat o da ne! Nihat, takımdaki build almayı bilen tek kişi! Nihat iyileşene kadar release çıkamıyoruz. Nihat ve diğer bütün takım arkadaşlarımızın bu duruma düşmemek için yapmaları gereken tek şey, “nasıl build alınır?” dokümanı yazmaktı. Süreçler otomatize edilse de, edilmese de bilgiyi yaymak ilk ve en öncelikli görevimizdir. Üçüncü senaryomuzda ise Nihat ve takıma yeni gelen Arif arasında bir tartışma yaşanıyor. Code review’da Arif, Nihat’ın koduna bir makale referans göstererek öneride bulunmuş. Nihat da gene bir makale referans göstererek yaptığının doğru olduğunu belirtmiş. Kısacası aralar bozulmuş, çıkmazlara girilmiş. Bu durumu hali hazırda bir Coding Standards dokümanı varsa orada senaryoyu karara bağlamak ya da eğer bir standartlar dokümanı yoksa daha bu günden oluşturmak kaydıyla çatışmayı çözmek gerekir. Günün sonunda, çözülen her sorun, suçlama kültürünü de yok eder.
Yolculuğun kendisi, varacağımız yerden daha önemlidir
Şunu söyleyerek başlamak gerek, prototip aşamasında hızlı ve kirli kod yazılabilir. Aslında önemli olan, hızlı ve kirli kodun nerede ve ne zaman yazılacağının iyi bilinmesi ve bu konuda taviz verilmemesidir. Hızlı ve kirli kod yazmanın da faydalı olduğu yerler var diyerek gelecek bir tartışmayı kapadıktan sonra, yazıya devam ediyorum.
Prototip aşaması dışında hızlı ve kirli kod yazan takımlar, sonuca odaklı gittikleri izlenimine kolayca kapılırlar. Bu tür bir felsefeye inanan takımların “sonuç odaklıyız” savının arkasına sık sık saklandığına şahit oluruz. Bir kere şunu aydınlatmak lazım, sonuç yalnızca uygulamanın markette olması ve para kazandırması değil. Sonuç, ortaya çıkan uygulamanın, çevik bir geliştirme ortamına izin vermesi, yüksek öğrenilebilirlikte olması, stabilitesi ve proje çalışanlarına bakımı yapılabilir bir ortam sağlamasıdır. Uygulama eğer bakım maliyeti yüksek, kırılgan ve hantal ise, masada para bırakıyor ve sonuç hep hüsran oluyor. Burada bir parantez açıp, bakım maliyeti yüksek, kırılgan ve hantal uygulamalarda çalışan yazılımcının hislerine değineceğim. Berbat hissediyorlar! Çalıştıkları kod altyapıları, bazen bir butonu bir pencereye eklerken bile önlerine taş koyabiliyor. Bir ürün yöneticisi, “bu butonu buraya eklemek ne kadar zor olabilir ki” diye her gün karşılarına geliyor ve bu kod altyapısı ile çalışmak zorunda olan yazılımcılar, gene bu haklı sözün karşısında çaresizce suçlanmış hissediyorlar. Yani, ana ürünü geliştirirken hızlı ve kirli kod yazan ve böylece sonuç odaklı gittiğini sanan takımlar, sonuca etki eden en önemli değişkenin, geliştirme sürecinin kalitesinin öneminin farkında olamıyor ve bir illüzyonun etkisinde savruluyorlar.
Bu durum karşısındaki savımsa şu, yolculuğun kendisine, yani geliştirme sürecinin kalitesine odaklanmak, proje üzerinde çalışan geliştiricileri körelten ve onların iç huzurunu katleden uygulamalar üretmemizin önüne geçecek. İçinde çalışması sancısız ve keyifli geliştirme ortamları yarattığımızda da çıkardığımız ürünlerden alacağımız verimi son derece artırmış olacağız. Böyle ortamların bizlere sağladığı rüzgâr sayesinde, zamanla yarıştığımız her geliştirmeyi yüksek verimde ve hızda geliştirmiş olacağız.
Sürece odaklanan yazılım geliştirici takımları nelere odaklanırlar, onlara bir bakalım şimdi. Piyasanın çok acımasız olduğunu bilirler ve bu sebeple de hızlı ve temiz kod geliştirmenin hayati önem taşıdığını anlar, kabul ederler. Bu da onları, projeler arasında paylaşabilecekleri tekrar kullanılabilir ve versiyonlanarak yayınlanabilir modüller yazmaya iter. Yani bir kere ödeme sistemi yazarlar, sonra da onun 1.0.1 versiyonunu A uygulamasında, 1.2.0 sürümünü de geçen ay yayınladıkları B uygulamasında kullanırlar. Code review yaparlar. Olabildiğince unit ve integration test yazarlar. Yeni teknolojileri takip eder ve kendilerini güncel tutarlar. Eğitimlerine önem verirler, bilgiyi aralarında bütün gerçekliğiyle paylaşırlar. Kısacası, çalışma ortamlarını evleri haline getirirler ki, burada öğrenir, burada gelişir ve burada huzurlu hissederler.
Stoacılık, yolculuğun önemini vurgularken, erdemli bir yaşam sürmenin, sürekli olarak gelişmenin ve her anı bilinçli bir şekilde yaşamanın asıl amaç olduğunu öğütlerler. Bu öğüdü bir yazılımcının gözünden analiz ettiğimizde, projenin geliştirme sürecine katkıda bulunmanın erdemli olduğu çıktısına varırız. Projeyi geliştirirken sürekli öğrenmeye odaklanır, yaptığımız hataları birer suçlama malzemesi olarak görmek yerine, onları birer kazanım olarak alırız. Yani, hata toleransımız ve hatalardan öğrenme hızımız artar. Bir diğer taraftan, projenin süreçlerine bu denli odaklanan bir takımın o projeyi benimseyişi ve bu benimsemenin hem projeye hem de takıma yararlarını birer meyve olarak toplarız. Unutmayın, çalıştığı kod altyapısını ve projeyi benimseyen takımlar hem kendi hem de son kullanıcının sorunlarına çözüm önerirler. Bu çözümleri önermekle kalmayıp, bir sabah masanıza bitirmiş olarak getirirler. Projesini benimsemeyen, motivasyonu düşük bir takımsa sadece ona ne deniyorsa onu yapmaya çalışır, kendinden bir şey katmanın tadına bir türlü varamaz. Günün sonunda da eleştirilerin, suçlanmaların ve işten çıkarılma tehditlerinin odağında olurlar.
Karşımıza çıkan zorluklar, bizi eğitir, güçlendirir
The Beatles grubu, kariyerinin başlarında çok da kalite ayırt etmeden, Almanya’daki bir dünya barda çalmış ve bu ayırt etmeden sahne alma süreci onlara korkunç bir tecrübe kazandırmış. Cesaretlendirici ve ilham verici bir hikâyeleri var. Düşünüyorum da, belki de ancak 7-8 kişilik seyirci gruplarının olduğu bir sürü barda çıkmış ve buraları kendilerine bir eğitim sahnesi gibi kullanmışlardır. Bu tür mekânların kendileri için bir eğitim fırsatı olduğunu hissettiklerine inanmak, içimdeki Stoacı’ya da dayanarak, bana bir hayli mantıklı geliyor. Aslında, Stoacılık da bunu söylüyor. Örneğin öfkelenmek, Stoacılık’ta çok hoş karşılanan bir durum değil. İnsanın öfkelenmesine sebep olabilecek bir durumda kalmasıysa, gene o insan için bir eğitim sahnesi ve dolayısıyla büyük bir şans.
Şimdi gelin bu savı biz yazılımcıların dünyasına uyarlayalım. Eğer ki karşımıza çıkan kritik hataları, krizleri ve aşılması zor teknolojik sorunları bir fırsat ve gelişim için birer şans olarak algılar ve gözlerimizi her sabaha buna hazır bir zihinle açarsak, karşımıza çıkan her zorlukta daha bir güçlenecek, daha bir öğreneceğiz.
Karşımıza çıkan zorlukları birer fırsat olarak gören takımlar, hata yapmaktan korkmazlar. Bu başlık altında savunduğumuz anlayışın en keyifli meyvelerinde birinin de hata yapmaktan korkmamak olduğunu belirtmeden geçmemek gerek.
Diyelim ki kullanıcılarımız satın alma yaparken sadece Android platformunda uygulamanın aniden kapanması ile karşı karşıya kalıyorlar. Kartlarından para çekiliyor, ancak satın aldıkları ürün oyunlarına yansımıyor. Böyle bir problem, Google Play Billing sisteminin detaylarına inmek, kullanıcının son davranışlarını ve crash raporlarını incelemek ve hatayı reproduce etmek konusunda bu sorunu çözecek bir takım için muhteşem bir öğrenim fırsatı olacaktır. Ancak şuna da dikkat etmek gerek, bu tür sorunlarla sürekli uğraşmak getirdiği stres gereği tüketici olabilir. Bu tüketici durumdan kurtulmanın en kolay yolu ile takım olarak sorunları paylaşmak ve böyle sorunlarla olabildiğince destekleşerek savaşmaktır.
Kötü duyguların seni kontrol etmesine izin verme
Stoacılar, öfke, korku, kıskançlık, endişe, üzüntü gibi olumsuz duyguların bizi mantıklı düşünmekten ve erdemli bir şekilde yaşamaktan alıkoyduğuna inanırlar. Bu duyguları dışlamazlar bu arada, aksi takdirde Stoacılık, duygusuz insan olun demiş olurdu. Hatta duygusal dinginliğe erişmek için bu duyguları anlayıp kontrol altında tutmayı amaçlarlar.
Aslında bu alanda daha profesyonel ilerlemek için tüketilmesi kaynakları önererek başlamam lazım. Lütfen buradaki kaynakları olabildiğince hızlı tüketin. Bunları okuduğumuzda, duygularımızı kontrol etmek serüvenini daha keyifli sürmüş olacağız. Önümüzdeki paragraftan sonra kendi yorumlarımı sizlerin takdirine sunacağım.
Bir takımın ya da şirketin canına ot tıkayabilecek en büyük kötü duyguya değineceğim şimdi, “bulaşıcı ve zehir mutsuzluk”. Buna, bulaşıcı ve zehirli mutsuzluk dememin en büyük sebebi, öğle yemekleri ve takım etkinlikleri olmak üzere her birliktelikte hızla yayılmaları ve şirketleri, takımları ve dolayısıyla da her bir çalışanı birer birer zehirlemeleri. Bu duygu, hiyerarşiler arasında bilginin doğru akmaması, şeffalığın azalması ve bunun bir getirisi olarak ürünü sahiplenmenin dibe vurması, takımdaki bireyler arasındaki çatışma yönetiminin doğru yapılamaması ve şirketin ödül mekanizmasının körelmiş olması gibi bir çok sebeple dünyaya geliyor. Dünyaya geldikten sonra da, çalışan ayrılıkları, dedikodu kültürü ve projenin çalışanlar tarafından benimsenmesinin düşüşü gibi çıktılara sebep oluyor. Bu tür bir duygunun bizi ele geçirmesine izin vermek, günümüzün en az 8 saatini geçirdiğiniz bir yerde, mutsuzluk girdabına kendi isteğimizle girmek demek oluyor. Peki söylenmeyeceğiz de ne yapacağız diyeceksiniz. Kendimizi bol bol sorgulayacağız; “yöneticilerimle bu durumu konuştum mu, bu takımda çalışırken öğreniyor muyum, gelişiyor muyum, burada muyum, söylenmenin bana kazandırdığı şey ne, bu kadar mutsuzluğa katlanmak yerine neden başka bir iş bulmuyorum”… Bunun gibi soruları kendimize sormak ve cevaplarına göre aksiyon almak, bizi bu bulaşıcı ve zehirli mutsuzluk duygusunun dibe çekici sendromlarından koruyacaktır. Tabi bu duygudan korunmak için herkesin kendine göre bir metod geliştirmesi gerektiği bir kaçınılmaz gerçek. Varmak istediğim yer, bu duygunun sektördeki potansiyeli yüksek arkadaşlarıma büyük zarar verdiği ve onların bir şekilde bu duygudan korunması gerektiği…
Bu arada kötü duyguyu sadece dedikodu ve söylenme olarak kısıtlamamak gerek. Takım arkadaşlarımızı kıskanmak da bir hayli kötü bir duygu. Bu duygudan kaçmamızın en kolay yolu ise, kendi gelişimimiz ve serüvenimize odaklanmak. Başkalarının başarılarını kıskanmak yerine, onların başarılarını takdir etmek ve kendi serüvenimize odaklanmak, bizleri içsel huzursuzluklardan koruyacaktır.
Erdemli bir yaşam için sürekli öğren
Stoacılar, erdemli bir yaşam için sürekli öğrenmenin elzem olduğundan bahsederler. Biz yazılımcılar için de, kaliteli bir kariyer ve kendimizi daha iyi hissedeceğimiz bir bugün için, planlı ve sürekli bir öğrenmek döngüsü yaratmak elzemdir.
Sürekli öğrenmek, bizleri kendi serüvenlerimize odaklanmaya iter. Bu da kıskançlık duygusundan olabildiğince arınmamızı sağlar. Kıskançlık duygusundan arınmaksa, erdemli bir yaşamın kapılarını bir karış daha aralamamıza öncülük eder. Sadece kendi ile yarışan bir yazılımcı düşünün, bu insan başkalarıyla rekabet etmenin yorucu ve çiğ tadı yerine, en üst seviye zorlayıcılık ve sonsuzluktaki kendi ile yarışma cesaretini gösterir. Başarısını ölçmek için tek bir ölçütü vardır böyle insanların, “bugün, dünkünden daha çok şey biliyor muyum?“. Bu soruya evet dediği sürece gelişir, öğrenir ve iç huzurunu korur.
Bilgeliği aktar
Stoacılar, bilgeliği aktarmanın bir görev olduğuna inanırlar. Bilgeliği aktarmak onlar için, toplumun ve bireyin gelişimine katkıda bulunmak demektir.
Biz yazılım gelişticiler bu pencereden bakacak olursak, komünite’den öğrendiklerimizi, üzerine bir kaç şey de olsa ekleyerek gene komüniteye teslim etmek, komünitenin gelişimine katkıda bulunacağımız en erdemli davranış olacaktır.
Bilgiyi paylaşmanın bir diğer yararı da, topluluğa bilgiyi eleştirel olarak irdeleme yeteneği katması bence. Paylaşılan bir bilginin alıntılanıp, yorumlanması ve huzurlara sunulması, doğal ve seviyeli bir tartışma yaratır. Bu tür tartışma ortamları ve dolayısıyla bu tartışma ortamından çıkan sonuçlar, topluluğun gelişimi için elzemdir.
Daha Fazlası İçin
Stoacılık felsefesine hızlı bir giriş yapmak için aşağıdaki podcast’i dinleyin lütfen.