Maslow’un piramidi kavramı ile tanıdığımız Abraham Maslow’un daha az bilinen ama çarpıcı bir metaforu daha var… Maslow’un çekici!
Bu çekiç aracılığıyla Maslow bize kısaca şunu söylüyor: Elinde çekiç olan, her şeyi çivi görür. (1*)
Maslow her ne kadar insanlığın bu ortak davranışını tespit ederken bunu bir eleştiri mahiyetinde söylüyor olsa da, haklılık payı var.
Ben de bir yazılımcı olduğum için, işimi daha iyi yapabilmek için kullandığım bazı araçları hayatı yaşarken de daha iyi bir hayat inşa etmek için kullanabilir miyim diye düşünerek, yazılım felsefesi adını verdiğim bu yeni yazı dizisine başlama kararı verdim.
Bu ilk yazıda teknik borç kavramına ve bu borcun doğurduğu yeniden yazma (refactoring) ihtiyacının hayata uygulanabilir olup olmadığına bakacak; buradan kendimize bir fayda devşirebilir miyiz bunun yollarını arayacağız.
Hazırsanız gelin başlayalım…
Yazılım derken kastettiğim şeyi bir web sitesi, bilgisayar ya da mobil uygulama gibi düşünebiliriz. Her zaman kullandığımız bir banka, alışveriş ya da sosyal medya uygulaması aslında bir yazılımdır.
Bu yazılım oluşturulduktan sonra durmaksızın güncellenir; her adımda yeni bir özellik eklenir. Bu süreç içerisinde yazılımcılar izne gider, işten ayrılır, yenileri gelir… Zamanla bu yazılımı oluşturan kodlar öyle bir bozunuma uğrar ki, bir noktadan sonra bu bozuklukları düzeltmeye ayıracak zaman kalmaz ve sonradan düzeltilmek üzere teknik borçlar birikmeye başlar.
Tüm bu anlattıklarımı hayata uyguladığımızda şunu görürüz:
Yaşadığımız bazı döngüsel ve hoşumuza gitmeyen durumları “şu an düzeltemem” diyerek bir kenara atar, adeta teknik bir borç gibi biriktiririz.
Fakat bu döngüyü bir şekilde kırmaz, kendimiz için daha uygun bir döngüyle değiştirmezsek, bu borçlar boynumuzu büker.
Nasıl ki çok fazla teknik borcu olan projeler geliştirilmez hâle gelirse, hayatımız da zamanla yaşanması zor, tıkanık ve depresyona meyilli bir hâle gelebilir.
Bu duygusal / zihinsel borçlar davranışlarımızı, ilişkilerimizi ve üretkenliğimizi altüst edecek seviyeye gelebilir.
Yıllarca dokunmadığımız kodu refactor etmek (yeniden yazmak) ne kadar zorsa, yıllarca konuşmadığımız, paylaşmadığımız, anlamadığımız duygular da o kadar ağırlaşır.
Bu yazıda hayatımızı tıkayan duygusal, mental, ruhsal borçları fark etmenin ve refactor etmenin (yeniden yazmanın) yollarına bakacağız.
Felsefi ve Bilimsel Arka Plan
Felsefi Bakış Açısı
Kendini Yeniden Yazmak
Teknik borcu anlamak için nasıl yazılımın geçmiş versiyonlarına bakıyorsak, insanın içsel “versiyon geçmişi” de felsefede sık sık masaya yatırılmıştır.
İnsanın kendini yeniden yazması…
Kendini aşması…
Kendini arındırması…
Bu temalar farklı uygarlıklarda, farklı dillerde hep aynı gerçeğe işaret eder:
İnsan, kendisini statik bir varlık sanır; ama aslında sürekli refactor edilmeyi bekleyen bir canlı koddur.
Nietzsche: Kendini Aşmak İçin İçsel Bir Yeniden Yazma
Nietzsche’ye göre insan, varlığı boyunca iki seçenek arasında gider gelir:
Ya kendi eski koduna bağımlı kalır, ya da kendini aşarak yeni bir sürüme dönüşür. (2*)
Nietzsche’nin “Übermensch” (üstinsan) fikri aslında sanıldığı kadar uzak ya da mistik bir fikir değildir. Bir insanın kendi kalıplarını, kendi alışkanlıklarını, kendi tortularını fark ettiğinde sorduğu basit bir sorudur:
“Ben, kendimin daha iyi bir versiyonu olabilir miyim?”
Nietzsche’ye göre insanın asıl savaşı dışarıda değildir; karamsar yanıyla, ataletiyle, tortularıyla, eski alışkanlıklarının gölgesiyle kendi içindedir.
Bu savaş, bir yıkım değil; bir yeniden yazma çağrısıdır.
Nasıl yıllanmış bir kod bloğu artık işe yaramaz noktaya gelebiliyorsa, insanın zihnindeki yıllanmış inançlar, otomatik davranışlar, gereksiz korkular insanı işe yaramaz hale getirebilir.
Nietzsche’nin “kendini aşma” öğretisi tam olarak şunu söyler:
Eski kendini kırmadan yeni bir sen yaratamazsın.
Bu, bir karakter güncellemesidir.
Bir içsel refactor.
Ama zorla değil; cesaretle.
Stoacılık: Düzenli İç Muhasebe Günlük Yeniden Yazmayla Mümkün
Stoacıların öğrettiği şey aslında bir tür sürdürülebilirlik pratiğidir.
Her gün yapılan küçük iç düzenlemeler…
Stoacılar akşamları kendilerine şu üç soruyu sorardı… (3*)
- Bugün neyi doğru yaptım?
- Neyi geliştirebilirim?
- Neyi tekrar etmemeye niyet ediyorum
Bu, tam anlamıyla sistemde yazılı olan koda bakıp teknik borçları anlamak için yaptığımız incelemeyi andırıyor. Ama bu kod kendi içimizde.
İyi bir yazılımın en büyük düşmanı nedir?
Kendi ile tutarsız, dokunduğunda kırılacak kodların “birikmesine” izin vermek.
Stoacılar da aynı şeyi insan için söyler…
Düzenli bir biçimde iç muhasebe yapmazsan, duygusal borçların birikir. Biriken borçlar ise benliğini zamana yayacak şekilde kilitler.
Stoacılık, cezalandırıcı bir disiplin değildir.
Nazik ama kararlı bir iç bakım sistemidir.
Her gün ufak bir temizlik…
Her gün minik bir düzen…
Her gün küçük bir farkındalık…
Yazılımda olduğu gibi:
Küçük kod güncellemeleri büyük çöküşleri önler.
Bilgelik Gelenekleri: Arınma / Hafifleme, Eski Kodun Törpülenmesi
Taoizm’den Sufizme, Budizm’den Stoacılığa kadar dünyanın pek çok bilgelik geleneğinde aynı mesaj tekrar tekrar karşımıza çıkar.
İnsan, taşıdığı gereksiz yükleri bırakmadıkça ilerleyemez. (4*)
Bu geleneklerde “arınma”, “temizlenme”, “hafifleme” kavramları genelde metaforiktir ama bugünkü psikoloji ve nörobilimle şaşırtıcı biçimde uyumludur.
İnsan zamanla gereksiz inançlar, başkalarından öğretilmiş korkular, artık işe yaramayan stratejiler, otomatik tepkiler, eski acıların gölgeleri tarafından kuşatılır.
Bu, tam olarak legacy code (eskimiş kod) gibidir.
Zamanında işe yaramıştır ama bugün verimliliği düşürür, sistemi yavaşlatır, hataya açık hale getirir.
Bilgelik geleneklerinin söylediği şudur:
İlerlemek için önce hafiflemen gerekir.
Yeni bir sen yaratmak için, eski kodun fazlalıklarını törpülemen gerekir.
Bunu, duygusal bir versiyon temizliği, zihinsel bir yeniden yapılandırma ve bütünsel bir refactor olarak düşünebiliriz.
Bilimsel Bakış Açısı
Beynin “Yük” Algısı
Yazılımda teknik borç birikir, sistem ağırlaşır ve performans düşmeye başlar.
İnsan beyni de benzer şekilde çalışır…
Biriken stres, ertelenen duygular ve işlenmemiş deneyimler zihinsel bir borç oluşturur. Ve tıpkı çökme noktasına gelen bir proje gibi, beynin de bir yerden sonra benzer bir noktaya gelebilir.
Bilim bize şunu söylüyor:
Zihinsel yük arttıkça, beynin işlem gücü dramatik biçimde düşer.
Kümülatif Stres, Sistemde Performans Düşüşü Yaşamamıza Sebep Olur
Günlük hayatta yaşadığımız küçük stresler (biriyle tartışmamız, bir duygumuzu baskılamamız, bir sorumluluğu ertelememiz, kararsızlık yaşamamız, suçluluk duymamız, minik hayal kırıklıkları yaşamamız) beynimizin belleğinde birikir. Tek başlarına masum görünen bu stres parçaları, zamanla kümülatif yük oluşturur.
Beyin bunu bir “yük artışı” olarak algılar.
Yük artınca dikkatimiz dağılır, karar vermemiz yavaşlar, yaratıcılığımız düşer, motivasyonumuz sönümlenir ve duygusal dayanıklılığımız azalır.
Bu, birebir performans düşüşüdür. Tıpkı işlemcinin %100 ile çalışmasını sağlayan bir kod bloğu gibi.
Sistem çalışır ama verimsizdir, gürültülüdür, hata eğilimlidir.
Duygusal Birikim, Amigdala Hiperaktivasyonu İle Kod Çakışmasına Yol Açabilir
Beynimizin tehdit algısını yöneten merkez olan amigdala, işlenmemiş duygular biriktikçe hiperaktif hâle gelir, çok geveze bir hal alır, sürekli bir tehlike varmış benzeri bir davranış sergilemeye başlar. (5*)
Biz bu duyguyu sonra çözerim, şimdi üzerine gitmeyeyim, bu duyguyu hissetmemeliyim dediğimiz her anda, aslında duyguyu bastırmıyor, sadece istifliyoruz.
Ve istiflenen duygu, beynin tehdit devrelerini sürekli tetiklemeye başlıyor.
Sonuç olarak amigdalamız aşırı uyanık, sürekli tetikte, prefrontal korteksimiz (mantık, planlama, irade) devre dışı hale geliyor. Bunu da sistemde yaşanan kod “çakışmalarına” benzetebiliriz.
Bu nörobiyolojik çakışma günlük hayatta ne gibi sıkıntılara yol açar?
- Birden parlarız
- Odaklanmada sıkıntı yaşarız
- Aynı hatayı tekrar tekrar yaparız
- Gereksiz alınganlıklar gösteririz
- Basit şeylerde bile karar veremeyiz
- Aşırı yorgun hissederiz
Bu, yazılımdaki race condition (eşzamanlı çalışan kodlardaki çakışma) gibidir.
Sinyaller çarpışır, akış bozulur, sistem hata verir.
Bastırılan ama işlenmeyen duygular birikir, biriken duygular amigdalanın sesini yükseltir, amigdalanın tonu yükseldikçe “hayat tehlikede” sinyali doğar.
Aslında tehlike yoktur.
Ama sistem öyle sanır.
Rahatlama / Düzenleme İle Prefrontal Korteksin Yeniden Devreye Girişi
Biz buna “sakinleşmek” diyoruz ama nörobilimde adı çok daha spesifik:
Top-down regulation (yukarıdan aşağı düzenleme). (6*)
Yani prefrontal korteks tekrar direksiyona geçiyor.
Peki ne yapınca bu rahatlama yaşanıyor, direksiyonu nasıl prefrontal kortekse verebiliyoruz dersiniz?
- Derin nefesler aldığımızda
- Bir duygumuzu adlandırdığımızda
- Kısa bir mola verdiğimizde
- Bir şeyi açıkça “evet bu oluyor” diyerek kabul ettiğimizde
- İçsel yükümüzü hafiflettiğimizde
- Zihnimizi toparlayacak küçük bir farkındalık anında
Bu küçük mikro eylemler, beynin yöneticisi olan prefrontal korteksin tekrar aktif olmasını sağlıyor.
Sağlıyor da ne oluyor derseniz:
- Düşüncelerimiz netleşiyor
- Duygularımız düzenleniyor,
- İrademiz geri geliyor,
- Davranışlarımız olumlu yönde değişiyor
- “Bug fix” (kod içindeki bir sorunu çözme) kapasitemiz artıyor.
Bunu başardığımızda nöroplastisite devreye giriyor ve beynimiz yeni yollar açmaya başlıyor.
Bu, yazılımda refactor sonrası performans artışına birebir benzer.
Sistem rahat nefes alır.
İşlemci yükü düşer.
Kod akışı toparlanır.
Şişen dosyalar temizlenmiş gibi olur.
Gerçek Problem ve Çözüm Önerileri
Problem
Hayatımızdaki Teknik Borçlar
Hayatta da tıpkı yazılım projelerinde olduğu gibi, fark etmeden biriktirdiğimiz teknik borçlar var. Zaman içinde ufak tefek “şimdilik böyle kalsın” dediğimiz şeyler büyüyor, içsel sistemimizde hatalara, tıkanıklıklara, performans düşüşlerine yol açıyor. Bu borçların çoğu hemen çökmez; tam tersine sessizce birikir, birikir ve ancak kritik bir anda “neden böyle oldum?” diye sorduğumuzda görünür hâle gelir.
Gerçek teknik borç, “kötü kod” değil; ertelenmiş yüzleşmelerdir. Hayatımızdaki de aynı.
Aklıma şunlar geldi:
Ertelediğimiz konuşmalar
İçimizde bir yerde konuşmamız gerektiğini bildiğimiz ama sürekli “şu an sırası değil” diyerek rafa kaldırdığımız diyaloglar… Bunlar tıpkı bir fonksiyonun içine geçici diye yazılan debug logları gibi; zamanla sistemi kirletir, iletişim kanallarımızı tıkar.
Bir türlü yüzleşmediğimiz geçmiş meseleler
Çözmediğimiz her mesele, hafızamızın arka planında çalışan bir gizli görev gibi işlemcimizi tüketir. Kapalı sekme gibi görünür ama hali hazırda işlemciyi yormaya devam eder ve farkında olmayız.
“Beni böyle kabul etsinler” deyip bıraktığımız legacy (eskimiş) davranışlar
Bir zamanlar işimize yaramış olabilirler; belki hayatta kalmamızı sağlamış savunma mekanizmaları bile olabilirler. Ama artık güncel olmadıklarını farkettiğimiz an, yeni bir benlik yaratmaya başladığımız andır. “Legacy code” gibi… Dokunmaktan kaçınıyoruz çünkü hem zahmetli hem riskli görünüyor. Ama büyümemizi en çok sınırlayan kalıntılar da genelde bunlar.
Kendimizi aşırı yüklediğimiz ama optimize etmediğimiz sorumluluklar
Sistemimizin kapasitesi belli. Biz ise sürekli yeni özellik ekleyip refaktör etmeyi unutuyoruz. Sonra ne oluyor? Performans kaybı, gecikmeler, bitmeyen yorgunluk. Aslında sorun temelde kapasitede değil; iyi tasarlanmamış bir mimaride.
Geçmiş başarısızlıkların sistemde bıraktığı gizli bug’lar
Dışarıdan görünmezler, çünkü genelde sessizce çalışırlar. Ama trigger’ı geldiğinde davranışımız bir anda değişir. Biz bile “ben niye böyle tepki verdim?” diye şaşırırız. Çünkü bug fix’lenmemiştir, sadece üstüne başka kodlar eklenmiştir. Problem hala orada duruyordur ve biz çözmedikçe de durmaya devam edecektir.
Bunun dışında hem yazılımda hem hayatta gördüğüm benzeşen kavramları şöyle sıraladım:
Hard-coded çözümler / Katı inançlar
Yazdığımız kodlarda bazen bazı değerleri bir değişkene atamak ve o değişkeni kullanmak yerine el ile hızlıca yazıp geçmeyi tercih ederiz ama bu doğru bir davranış değildir çünkü ortam değiştiğinde sabit kod değişmediğinen bizi sıkıntıya açık hale getirir.
Bunlar zamanında hızlı çözüm gibi görünür. Hayatta da katı ve sabit inançlar böyledir. “Böyle inanıyorum çünkü hep böyleydi.” deriz, ama hayat değişir, koşullar değişir. Hard-coded yaklaşım ise sistemin esnekliğini yok eder.
Spagetti code / Duygusal karmaşa
Spagetti code dediğimiz şey kodların birbirine karıştığı, nereden başlayıp nereye gittiğinin belli olmadığı, çözmeye çalıştıkça daha çok dolaşan bir kod yığınıdır. Tıpkı birbirine dolanmış bir spagetti tabağı gibi.
Hayat da bazen böyle olabilir. Bir duygu diğerine bağlanır, o duygu başka bir travmaya bağlanır, o travma eski bir hikâyeye bağlanır… Sorunun ne olduğunu anlamaya çalışsak saatlerimizi alır. Çözüm ise hem kodda hem hayatta aynı. Kodu ve hayatı sadeleştirmek, bağımlılıklarını çözmek, yeniden düzenlemek.
Yetersiz dokümantasyon - Karışık düşünceler
Yazılımda dökümantasyonu yazılan kodların nasıl çalıştığını anlatan kullanım kılavuzu gibi düşünebiliriz. Yetersiz olduğunda herkes kafasına göre aynı işi farklı biçimlerde yapar ve bu da zamanla içinden çıkılmaz kodlarla boğuşmamıza sebep olur.
Ne hissettiğimizi, ne istediğimizi, neyi neden yaptığımızı net yazmadığımız zaman da hayat içerisinde kafa karışıklığımız artar. Tıpkı dokümansız bir projeye yeni başlayan birinin “Bu ne yapıyordu ya?” demesi gibi, biz de kendi iç dünyamıza yabancılaşırız.
Dead code / Artık işe yaramayan alışkanlıklar
Dead code dediğim şey artık hiçbir işe yaramayan ama sistemde durmaya devam eden, kimsenin fark etmediği gereksiz kod parçalarıdır. Evde yıllardır kullanmadığımız ama atmaya kıyamadığımız eşyalar gibi.
Buna benzer şekilde artık işe yaramayan alışkanlıklarımız da içimizde durur, yer kaplar, belki de yeni davranışlarla çakışır ama bir işlevi kalmamıştır. Yıllardır “alışkanlık” diye taşıdığımız ama aslında hayatımıza katkısı olmayan rutinler gibi.
Workaround / Kısa vadeli kaçışlar
Yazılımda da hayatta da kısa vadeli kaçışlar meşhurdur. Yazılımda bir hata varken bazen sadece o hataya yönelik bir düzenlemeyi hızlıca yapmak adına o hatanın ana kaynağına inmez hızlıca bir çözüm ararız. Genelde bu o sorunu çözse de yeni ve çözmesi daha zor sorunlar yaşamamıza yol açar.
Bir sorunu çözdüğümüzü sanırız ama gerçekte sadece geciktirmişizdir. Workaround’lar günlük hayattaki “idare etme” davranışının başka bir versiyonudur: “Sonra düşünürüm”, “Şimdilik böyle olsun”, “Bozmaya gerek yok”…
Ama uzun vadede büyük borç yaratır.
Çözüm Önerileri
Hayatı Refactor Etmek
Teknik borç doğası gereği bize bir şey söyler…
Sorunlar birikerek oluşur, ama çözüm küçük ve düzenli dokunuşlarla gelir.
Hayat da aynı prensiple çalışıyor.
Aşağıdaki adımlar, yazılımda defalarca kullandığımız kavramların psikolojik karşılıklarını gösteriyor. Bir nevi içsel sistemimizi optimize etme rehberi.
“Code Review” yani “Kendini gözlemlemek”
Bir kodu gözden geçirirken yaptığımız şey aslında çok basittir:
Hatayı suçlu aramak için değil, sistemi daha sağlıklı hâle getirmek için buluruz.
Günün sonunda yapılacak kısa bir içsel “code review” da aynı mantıkla çalışır:
Bugün bende hangi duygu tetiklendi?
Bir uyarı penceresi gibi düşünebiliriz: Öfke, kaygı, kırgınlık… Log’a düşmüştür.
Hangi davranış döngüsüne otomatik olarak girdim?
Bir fonksiyon gibi her gün aynı tetikleyiciyle çalışıyor mu?
Neyi neden yaptım?
Ama suçlulukla değil.
Veri olarak…
Sadece “Bu oldu.” diyebilmek bile prefrontal korteksi devreye alır.
Code review’ın hayata uygulanabilir versiyonu şudur:
Kendimizi yargılamadan gözlemleyebilmek.
Yani sistemi suçlamak değil, sistemi anlamak.
Refactor / Küçük Adımlarla Hayatı Yeniden Yazmak
Büyük dönüşümler değil; mikro düzenlemeler…
Refactor hiçbir zaman komple bir yıkım değildir.
“Büyük değişim” fikri güzeldir ama beynin tehdit algısını tetikler.
O yüzden hem yazılımda hem hayatta en etkili yöntem şudur:
Her gün 1 küçücük düzenleme.
- Bir kelimeyi farklı seçmek
- Bir tepkiyi yarım saniye geciktirmek
- Bir nefes arası bırakmak
- Bir alışkanlığı %100 değiştirmek değil, %5 oynatmak
Beyin büyük devrimleri sevmez ama mikro değişimlere aşık olur.
Çünkü güvenlidir, sürdürülebilirdir ve nöroplastisiteyi tetikler.
Değişim devrimle değil, ufak gelişimlerin tekrarı ile olur.
Ölü kodu ve gereksiz alışkanlıkları silmek
Artık işe yaramayan alışkanlıkları bırakmayı öğrenmek…
Dead code yazılımda nasıl tanımlanır?
Artık çalışmayan, işe yaramayan ama sistemde yer işgal eden kod parçaları…
Hayatta bunun karşılığı çok nettir:
- Kullanmadığımız ama hala sahip olduğumuz savunma mekanizmaları
- Çocukken işimize yarayıp yetişkinlikte bizi geren otomatik tepkilerimiz
- Bize bir zamanlar güven veren ama bugün bizi kısıtlayan alışkanlıklarımız
- “Ben hep böyleyim.” diye taşıdığımız ama aslında işlevi bitmiş davranış kalıplarımız
Dead code’u silmediğinde sistemde gizli çakışmalar yaşarız.
Silince?
Hafifleriz.
Bu adımın hayat versiyonu çok basit bir düsturla başlar:
“Bu davranış hâlâ işimize yarıyor mu?”
Eğer cevap “hayır”sa, bir sonraki iterasyonda o kodu silmenin zamanı gelmiştir.
Modüler Düşünmek
Sorunları küçük parçalara bölmek ve önceliklendirmek…
Yazılımın altın kurallarından biri:
Bir modül çok karmaşıksa, küçük parçalara böl ki yönetebilesin.
Hayatta karmaşık gelen şeylerin büyük kısmı, tek bir blok gibi ele alınmasından kaynaklanır.
Sorunu modüllere ayırdığımızda zihnimizde şöyle modüller oluşturabiliriz:
- “İlişkiler modülü”
- “Özsaygı modülü”
- “İş alışkanlıkları modülü”
- “Duygusal tetikleyiciler modülü”
Her modülü küçük görevlere bölebiliriz…
Bir anda hepsini düzenlemeye çalışmak sistemin çökmesine yol açabilir.
Önce en çok hata veren modülü ele alabilir ve ondan işe başlayabiliriz.
Yani her şeyi bir anda düzeltmeye çalışmamıza gerek yok.
Önce en çok acı veren parçayı stabilize ederek başlayabiliriz.
Test Et, Gözlemle, Tekrar Et
Her davranışı bir A/B testi gibi görmek…
Bir davranışı değiştirdik diyelim.
Yazılımcı refleksiyle şunu yapabiliriz:
Test ederiz.
Gözlemleriz.
Tekrar düzenleriz.
Diyelim ki yeni bir tepki verdik, hemen sistemin nasıl cevap verdiğine bakabiliriz… Diyelim ki bir alışkanlığı %10 hafiflettik, bunun sonucunda enerjimiz arttı mı bakabiliriz.
Diyelim ki bir sınır koyduk, ilgili modül çakışma verdi mi, yoksa stabil mi bakabiliriz.
Bir bakış açısı değiştirdiğimizde hata log’ları azaldı mı bakabiliriz…
Bu döngü, psikolojinin en etkili değişim prensiplerinden biri olan davranışçı iterasyon ile birebir aynıdır.
Yazılımcı diliyle söylemek gerekirse, hayat da bir CI/CD pipeline gibidir. Biz de her gün mikro güncellemeler alan bir proje gibiyiz.
Tüm bu adımlarda anlatmak istediğim şey şu:
Hayat refactor edilmezse tıkanır.
Refactor edilmeye çalışılırsa güzelleşir.
Çökene kadar beklemek gerekmez.
İçsel sistem, küçük dokunuşlara büyük cevaplar verir.
Sonuç ve Okuyucuya Mesaj
Nasıl ki yazılmış programlar bile zamana yenik düşüyor, insan da hayatın hengamesi, korkular, üzüntüler, travmalar derken zamana yenik düşer, teknik borçlar gibi duygusal ve mental borçlar biriktirirler.
Yazılımda da, hayatta da çözüm yolları benzer, bir anda her şeyi sıfırdan yazmak zor ve uğraşlı olur ama yapılacak küçük düzeltme döngülerini alışkanlık haline getirmek hem yazılımlarımızı hem de hayatlarımızı daha güzel bir noktaya taşımamıza yardımcı olacaktır.
Bu açıdan bakılınca hem yazılımlarımızı hem hayatlarımızı refactor etmek, geçmişimizi silmek değil; geleceğimizi daha okunabilir hale getirmektir.
Her zaman olduğu gibi sizin de sorunuzu unutmadım.
Sizin hayatınızda hangi modül refactor edilmeyi bekliyor? Ya da şöyle sorayım, hangi ufak düzenlemenin tekrarı her şeyin düzelmesini sağlayacak ışığı yakabilir?
Haftaya, yazılım dünyasında doğmuş ama aslında hayatın tam kalbine dokunan bir yaklaşımı konuşacağız.
Agile denen bu yaklaşım, büyük planların ağırlığı altında ezilmek yerine, küçük adımlarla ilerlemeyi; hata yaptığında bunu dünyanın sonu gibi görmek yerine hızlıca öğrenip yola devam etmeyi önerir.
Bir anlamda, ‘hayatı sprint sprint yaşamak’ diyebiliriz: küçük denemeler, küçük düzeltmeler, küçük kazanımlar…
Ve belki de hayat, tam da böyle yaşandığında daha esnek, daha hafif, daha sürdürülebilir olur.
O yüzden bir sonraki yazıda şuna bakacağız:
Hayat gerçekten tek seferde çözülecek dev bir proje mi, yoksa küçük adımlarla sürekli iyileştirilecek bir süreç mi?
O zamana kadar refactor ve sevgi ile kalın.
Kaynakça
- Abraham Maslow - “The Psychology of Science”
- Friedrich Nietzsche – “Böyle Buyurdu Zerdüşt” & “İyinin ve Kötünün Ötesinde”
- Marcus Aurelius – “Meditations” (Kendime Düşünceler)
- Pema Chödrön – Her Şey Dağıldığında
- Joseph LeDoux – “The Emotional Brain”
- Daniel J. Siegel – “Mindsight”
