İlk Satırın Gölgesi: Mimari Kararlar Neden Yıllarca Peşimizi Bırakmaz?

Bir yazılım projesinin ilk günlerinde alınan kararlar çoğu zaman masum görünür: Veritabanını şimdilik tek sunucuda tutalım, kullanıcı kimliğini e-posta adresiyle eşleştirelim, modülleri hızlı ilerlemek için aynı kod tabanında toplayalım. Ekip küçüktür, müşteri acele eder, bütçe dardır. Herkes “sonra düzeltiriz” der. Fakat bilişim dünyasında bazı “sonralar”, yıllar sonra milyonlarca kullanıcının, yüzlerce geliştiricinin ve kritik iş süreçlerinin omzuna çöken birer mimari gölgeye dönüşür.

Geri dönüşsüz karar, teknik olarak asla değiştirilemeyecek karar demek değildir. Çoğu sistem yeniden yazılabilir, veri taşınabilir, servisler ayrıştırılabilir. Ancak değişimin maliyeti zamanla öyle büyür ki karar pratikte geri dönüşsüz hale gelir. Bir apartmanın temelini değiştirmek mümkündür; fakat apartman doluyken, çevresinde trafik akarken ve kiracılar her gün yaşamaya devam etmek zorundayken bu iş yalnızca mühendislik problemi olmaktan çıkar. Yazılım mimarisi de böyledir: Kodun altında çalışan iş kuralları, kullanıcı alışkanlıkları, entegrasyonlar ve kurum hafızası vardır.

Küçük Kestirmeler, Büyük Kilitler

En klasik örnek veritabanı seçimidir. Başlangıçta ilişkisel bir model, sipariş ve müşteri kayıtları için son derece mantıklıdır. Ancak sistem zamanla sosyal etkileşim, gerçek zamanlı analiz, belge depolama veya devasa olay akışları üretmeye başladığında ilk model zorlanabilir. Sorun, seçimin “yanlış” olması değildir. Sorun, ilk tercihin bütün uygulamanın varsayımlarına sızmasıdır. Sorgular, raporlar, yetkilendirme kuralları, yedekleme stratejileri ve ekip yetkinlikleri o seçime göre şekillenir. Böylece veritabanı bir araç olmaktan çıkar, sistemin görünmez anayasasına dönüşür.

Monolit mimarisi de benzer bir hikâye anlatır. Erken aşamada monolit çoğu zaman doğru karardır: Dağıtımı basittir, hata ayıklaması daha kolaydır, ekip tek bir bağlamda çalışır. Ne var ki ürün büyüdüğünde küçük bir ödeme değişikliği ile bildirim sisteminin aynı sürüm paketi içinde yaşaması, her yayınlamayı yüksek riskli hale getirebilir. Bu noktada mikroservisler sihirli değnek değildir. Monoliti plansız biçimde parçalara ayırmak, tek bir büyük düğüm yerine yüzlerce küçük düğüm üretmek anlamına gelir. Asıl mesele teknoloji modası değil, bağımlılıkların bilinçli yönetimidir.

Teknik Borç Faizle Çalışır

Teknik borç benzetmesi sık kullanılır, çünkü acı verici biçimde doğrudur. Hız kazanmak için alınan kısa vadeli kararların gelecekte bakım maliyeti vardır. Fakat bu borcun faizi yalnızca kod karmaşıklığı değildir. Yeni geliştiricilerin sistemi anlaması uzar, test yazmak zorlaşır, güvenlik açıkları daha geç fark edilir, ürün fikirleri “altyapı izin verirse” şartına bağlanır. Bir noktadan sonra şirketin stratejisini pazar değil, geçmişte yazılmış kod belirlemeye başlar. İşte mimari kararların en büyük etkisi burada ortaya çıkar: Gelecekte hangi fikirlerin uygulanabilir olduğunu sessizce seçerler.

Bu nedenle iyi mimari, geleceği kusursuz tahmin etme sanatı değildir. Böyle bir tahmin zaten mümkün değildir. İyi mimari; değişmesi muhtemel alanları izole etmek, veri sahipliğini açık tanımlamak, gözlemlenebilirlik kurmak ve geri alma maliyetini erken hesaplamaktır. Bir karar kayda geçirilmelidir: Neyi seçtik, hangi alternatifi neden elemedik, hangi varsayımlara güveniyoruz ve hangi işaretler geldiğinde bu kararı yeniden değerlendireceğiz? Mimari karar kayıtları, gelecekteki ekiplere bırakılmış küçük ama çok değerli zaman kapsülleridir.

En sağlıklı yaklaşım, her bileşeni esnek yapmaya çalışmak değildir; bu da pahalı ve karmaşık bir yanılsamadır. Bunun yerine geri dönüşü zor alanları erkenden tanımak gerekir: kimlik yönetimi, veri modeli, güvenlik sınırları, dış entegrasyon sözleşmeleri ve dağıtım altyapısı. Bu alanlarda yavaş düşünmek, diğer alanlarda hızlı denemeler yapmayı mümkün kılar. Yazılımda özgürlük, hiç bağ kurmamakla değil, hangi bağların bir gün çözülmesinin pahalı olacağını bilmekle başlar.

Kodun Gösterişi Değil, Zarafeti Kazanır: Neden Daha Az Çoğu Zaman Daha İyidir?

Bir yazılım projesinde karmaşıklık çoğu zaman zekânın kostümü gibi görünür. On iki katmanlı soyutlamalar, her sınıf için ayrı bir arayüz, küçük bir işlem için devasa bir tasarım deseni koleksiyonu… Bunlar ilk bakışta etkileyicidir. Fakat bilişimde etkileyici olmak ile iyi olmak aynı şey değildir. Zarafet ilkesi, çözümün gösterdiği kas gücünden çok, problemi ne kadar doğrudan, anlaşılır ve güvenilir biçimde çözdüğüne bakar. İyi kod, geliştiricinin ne kadar çok şey bildiğini değil; neyi gereksiz yere kullanmadığını da gösterir.

Zarafet: Az Kod Değil, Az Gereksiz Karar

Zarif bir çözüm mutlaka en kısa çözüm değildir. Tek satıra sıkıştırılmış, yalnızca yazarı tarafından çözülebilen bir ifade zarif sayılmaz; o, çoğu zaman şifrelenmiş bir egodur. Zarafet; okunabilirlik, doğru soyutlama, öngörülebilir davranış ve düşük bilişsel yükün birleşimidir. Bir fonksiyonun ne yaptığını anlamak için zihinde beş farklı dosya, üç tasarım deseni ve geçmişte alınmış iki mimari karar taşımak gerekiyorsa, orada bir sorun vardır. Kod bilgisayara değil, gelecekte onu değiştirecek insana da hizmet eder.

Örneğin bir listedeki tekrar eden öğeleri kaldırmak için özel bir sınıf hiyerarşisi, olay dinleyicileri ve yapılandırılabilir stratejiler kurmak mümkündür. Ama ihtiyaç yalnızca benzersiz öğeler elde etmekse, uygun bir veri yapısı kullanmak çoğu kez yeterlidir. Buradaki mesele tembellik değildir; problemin gerçek sınırını görme disiplinidir. Henüz ortaya çıkmamış ihtiyaçlar için mimari inşa etmek, yağmur ihtimaline karşı apartmanın çatısına deniz feneri dikmeye benzer.

Karmaşıklığın Gizli Faturası

Her ek katman bir maliyet üretir: Daha fazla test senaryosu, daha fazla hata olasılığı, daha uzun hata ayıklama süresi ve daha zor onboarding süreci. Bir sistemin karmaşıklığı yalnızca satır sayısıyla ölçülmez. Bağımlılıkların yönü, durumların sayısı, bileşenler arasındaki görünmez anlaşmalar ve istisnaların birikimi de bu faturaya dahildir. Özellikle dağıtık sistemlerde küçük bir gereksiz soyutlama, ağ gecikmesi, tutarsız veri veya başarısız yeniden deneme gibi gerçek dünya sorunlarıyla birleştiğinde büyük bir belirsizliğe dönüşebilir.

Bu yüzden iyi mühendislik, önce en basit doğru çözümü kurar; sonra ölçer; ancak kanıt varsa karmaşıklaştırır. Performans darboğazı gerçekten nerede? Güvenlik gereksinimi hangi sınırı zorunlu kılıyor? Sistemin hangi parçası değişken? Bu sorular yanıtlanmadan yapılan optimizasyon ve genelleştirme, çoğu zaman teknik borcun kibar adıdır. Donald Knuth’un erken optimizasyon uyarısı hâlâ canlıdır: Ölçmeden hızlandırmaya çalışmak, haritasız biçimde kestirme aramaktır.

Basitlik Bir Başlangıç Değil, Sürekli Bir Seçimdir

Zarafet ilkesi, her şeyi tek dosyaya koymak veya mimariyi reddetmek anlamına gelmez. Büyük sistemler modüllere, açık sınırlara ve dikkatli soyutlamalara ihtiyaç duyar. Ancak iyi soyutlama, karmaşıklığı saklamak için değil, onu yönetmek için vardır. Bir modülün içi karmaşık olabilir; dışarıdan ise mümkün olduğunca yalın bir sözleşme sunmalıdır. Kullanıcının ya da başka bir geliştiricinin anlaması gereken ayrıntı sayısı azaldıkça sistem daha sağlam hale gelir.

Sonuçta bilişimde zarafet, estetik bir süs değil, operasyonel bir erdemdir. Daha basit çözüm daha kolay test edilir, daha rahat anlatılır, daha güvenli değiştirilir ve arızalandığında daha çabuk onarılır. En iyi çözüm, en çok parçaya sahip olan değildir; doğru sayıda parçayla doğru işi yapan çözümdür. Kod yazarken sorulacak en değerli soru şudur: Bu karmaşıklık gerçekten problemi mi çözüyor, yoksa yalnızca problem çözüyor gibi mi görünüyor?

Kodun İçindeki Kör Nokta: Usta Programcılar Neden Kendi Hatalarını Göremez?

Bir programcının en tehlikeli cümlesi çoğu zaman şudur: “Bu kodun çalışması lazım.” Bu cümle, teknik bir tahminden çok zihinsel bir sözleşmedir. Yazılımcı, çözümü tasarlarken belli varsayımları görünmez biçimde doğru kabul eder; sonra da hata ayıklarken dünyayı bu varsayımları doğrulayacak şekilde okumaya eğilim gösterir. Loglar, test sonuçları ve kullanıcı raporları önündedir ama zihin çoktan bir hikâye yazmıştır: sorun veritabanındadır, ağ gecikmesindedir, kullanıcı yanlış girdi yapmıştır. Oysa hata, çoğu kez o hikâyenin ilk cümlesindedir.

Metakognisyon: Düşünceyi İzleyen Düşünce

Metakognisyon, en yalın hâliyle, ne düşündüğümüzü değil nasıl düşündüğümüzü fark edebilme becerisidir. Bir algoritmanın karmaşıklığını hesaplamak başka, “Neden bu algoritmayı seçmeye bu kadar istekliyim?” diye sormak başkadır. İlk iş teknik yetkinliktir; ikincisi zihinsel denetimdir. Deneyimli programcılar ilkinde genellikle çok iyidir. Fakat uzmanlık arttıkça ikinci beceri otomatik olarak güçlenmez. Hatta paradoksal biçimde, uzmanlık zihinsel kör noktaları daha iyi gizleyebilir.

Bunun bir nedeni, ustalığın büyük ölçüde otomasyon üretmesidir. Tecrübeli geliştirici, binlerce örüntüyü saniyeler içinde tanır: yarış koşulu, null referansı, sınır değeri, yanlış önbellekleme, kötü soyutlama. Bu hız değerlidir; ancak zihin örüntü tanırken bazen araştırmayı erken bitirir. Tanıdık görünen bir hata, gerçekten tanıdık olmayabilir. Eski bir çözüm, yeni bağlamda zarif değil tehlikeli olabilir. Kısacası sezgi, güçlü bir derleyicidir ama zaman zaman yanlış kaynaktan derlenmiş sonuçlar üretir.

Programcı Yanılgısının Yakıtı: Sahiplik ve Onaylama

Programcı kendi yazdığı koda yalnızca satırlar bütünü olarak bakmaz; o kod, harcanmış zamanın, çözülmüş gecelerin ve zekâ yatırımının izidir. Bu nedenle kod eleştirildiğinde teknik bir öneri bile kişisel bir tehdit gibi algılanabilir. Sahiplik etkisi burada devreye girer: İnsan, ürettiği şeyin değerini sistematik olarak olduğundan yüksek görme eğilimindedir. “Bu modül karmaşık ama gerekli” cümlesi bazen mimari bir gerçek değil, emeği savunma refleksidir.

Onaylama yanlılığı da bu refleksi besler. Geliştirici, hipotezini doğrulayan log satırlarını öne çıkarır; onu çürüten belirtileri ise istisna, gürültü veya geçici anomali sayar. Bir testin geçmesi, tasarımın doğru olduğunu kanıtlamaz; yalnızca testin sorduğu soruya kabul edilebilir bir cevap verildiğini gösterir. Üstelik testleri de insan yazar. Yanlış soruyu mükemmel test etmek, yanlış güveni otomatikleştirmektir.

Deneyim Neden Bazen Engeldir?

Acemi programcı “Bilmiyorum” demeye daha yakındır; uzman ise çoğu zaman neyi bildiğini çok iyi bilir. Sorun, bilinenlerin yeni bir olasılığı görünmez kılmasıdır. Deneyim, karar maliyetini düşürür fakat keşif alanını da daraltabilir. Bir kıdemli geliştirici geçmişte mikroservislerin işe yaradığı on projeyi hatırlayıp on birinci projede monolitin daha doğru seçenek olabileceğini geç fark edebilir. Çünkü zihnin arama motoru, en sık tıklanan sonuçları üst sıraya taşır.

Bu yüzden iyi ekipler sadece kod incelemesi yapmaz; düşünce incelemesi de yapar. “Bu karar hangi varsayıma dayanıyor?”, “Bizi haksız çıkaracak kanıt ne olur?”, “Bu çözümü neden seviyoruz?” soruları birer nezaket ritüeli değildir. Bunlar, zihinsel hata ayıklama araçlarıdır. Kırmızı takım değerlendirmeleri, karar günlükleri, önceden başarısızlık analizi ve farklı kıdem düzeylerinden eleştiriler bu nedenle değerlidir.

En olgun programcı, en az hata yapan kişi değildir. Hatalarının hangi koşullarda görünmezleştiğini bilen kişidir. Kodun derlenmesi yetmez; varsayımların da derlenmesi gerekir. Çünkü yazılımda en inatçı bug bazen bir fonksiyonda değil, o fonksiyonu yazan zihnin “Ben bunu zaten anladım” satırında saklanır.

Kodun Gizli Politikası: Nesneler mi Yönetir, Fonksiyonlar mı Özgürleştirir?

Programlama paradigmaları ilk bakışta yalnızca teknik tercihler gibi görünür: sınıf mı yazacağız, saf fonksiyon mu? Fakat kod yazma biçimimiz, dünyayı düzenleme biçimimiz hakkında da ipuçları taşır. Nesne yönelimli programlama ile fonksiyonel programlama arasında kurulabilecek siyasi benzetme, elbette “bir paradigma doğrudan şu ideolojidir” kadar kaba değildir. Yine de her ikisinin de güç, sorumluluk, değişim ve sınır kavramlarını farklı biçimde ele alması dikkat çekicidir.

Nesne yönelimli dünya: Yetki, sınır ve hiyerarşi

Nesne yönelimli programlamada dünya, kimliği olan varlıklardan oluşur. Bir BankaHesabı nesnesinin bakiyesi vardır; bu bakiye dışarıdan gelişigüzel değiştirilemez. Para yatırma ya da çekme gibi işlemler, nesnenin kendi kuralları içinden geçmelidir. Bu yaklaşımın temel kavramları olan kapsülleme, kalıtım ve çok biçimlilik; yetkinin belirli merkezlerde toplanmasını, sorumluluğun rollere bölünmesini ve üst-alt ilişkilerinin modellenmesini mümkün kılar.

Buradaki hiyerarşi her zaman kötü bir şey değildir. Bir hava trafik kontrol sisteminde ya da karmaşık bir oyun motorunda, hangi bileşenin neyi yönetebildiğinin açık olması büyük bir avantajdır. Nesneler, kendi durumlarının bekçisi olur. “Bu veriye kim dokunabilir?” sorusu, mimarinin merkezine yerleşir. Siyasi dilde buna kurumlar, yetki alanları ve temsil mekanizmaları diyebilirdik. Düzen, serbestçe dolaşan veriden değil; sınırları tanımlanmış aktörlerden doğar.

Ancak bu düzenin bedeli vardır. Nesneler birbirlerinin durumuna bağımlı hale geldikçe sistemin görünmeyen ipleri çoğalabilir. Bir metodun sonucu, çağrıldığı anda nesnenin hangi ruh halinde olduğuna bağlı olabilir. Küçük bir değişiklik, uzak bir sınıfta beklenmedik bir sonuç yaratabilir. Bürokratik bir kurumda olduğu gibi, sorumluluk nettir ama karar süreçleri zamanla ağırlaşabilir.

Fonksiyonel dünya: Saflık, eşitlik ve izlenebilirlik

Fonksiyonel programlama ise başka bir teklif sunar: Veriyi dönüştür, fakat gizlice değiştirme. Aynı girdiye aynı çıktıyı veren saf fonksiyonlar, programın davranışını daha öngörülebilir kılar. Bir fonksiyonun sonucu, küresel bir değişkene, gizli bir sayaç değerine veya başka bir nesnenin o anki durumuna bağlı değilse, onu test etmek ve anlamak kolaylaşır.

Bu yapının siyasi benzerliği, merkezi otoriteden çok kuralların şeffaflığına dayanan bir düzen fikrinde bulunabilir. Fonksiyonlar birbirine emir vermez; girdi alır, çıktı üretir. Veri çoğu zaman değiştirilemez kabul edilir. Böylece bir işlem, ortak kaynağı sessizce tüketmek ya da bozmak yerine yeni bir değer üretir. Yan etkisizlik, burada teknik bir temizlik takıntısı değil, güven üretme yöntemidir: Bir parçanın ne yaptığını görmek için bütün sistemi gözetlemek zorunda kalmazsınız.

Fakat fonksiyonel yaklaşım da ütopya değildir. Gerçek dünya yan etkilerle doludur: Dosya yazılır, ağ isteği atılır, ödeme alınır, sensör okunur. Saflığın dışına çıkmak kaçınılmazdır. Fonksiyonel tasarımın başarısı, yan etkileri yok saymasında değil, onları sınırlandırıp görünür hale getirmesindedir. Bir bakıma mesele iktidarı ortadan kaldırmak değil, iktidarın nerede devreye girdiğini kayıt altına almaktır.

Asıl soru: Hangi düzen hangi probleme uygun?

Bu iki paradigma arasındaki seçim, ideolojik bir sadakat testi olmamalıdır. Karmaşık ve uzun ömürlü varlıkların davranışlarını modelleyen bir alanda nesne yönelimli yaklaşım doğal gelebilir. Veri akışlarının, paralel hesaplamaların ve güvenilir dönüşümlerin öne çıktığı yerde fonksiyonel araçlar daha güçlü olabilir. Modern yazılımın en verimli tavrı çoğu zaman hibrittir: Nesneler sınırları ve iş kurallarını taşır; fonksiyonlar bu sınırlar içinde hesaplamayı sadeleştirir.

Yine de bu benzetme bize değerli bir soruyu hatırlatır: Kodumuzda güç nerede toplanıyor? Hangi bileşen değişiklik yapabiliyor, hangisi yalnızca hesaplıyor, hangi etkiler görünmeden yayılıyor? İyi mimari, yalnızca çalışan kod üretmez. Yetkiyi anlaşılır, değişimi denetlenebilir ve sonuçları izlenebilir kılar. Belki de programlamanın en politik yanı budur: Düzen kurarız; sonra o düzen, bizim yerimize karar vermeye başlar.

Tanımadığın İnsanlar İçin Kod Yazmak: Çağımızın Sessiz Erdemi

Bir insan neden hiç tanımadığı, yüzünü görmediği, teşekkür bile etmeyecek birileri için gecenin ikisinde hata düzeltir? Neden hafta sonunu ailesiyle piknik yapmak yerine bir kütüphanenin belgelendirmesini iyileştirmeye ayırır? Açık kaynak dünyasının merkezindeki soru teknik değil, ahlakidir. Burada mesele yalnızca kod değildir; insanın, görünmez ötekine karşı nasıl bir karakter geliştirdiğidir.

Klasik erdem etiği, ahlakı kurallardan çok karakter üzerinden düşünür. Aristoteles için iyi insan, doğru davranışı korkudan ya da ödül beklentisinden değil, iyi olmayı alışkanlık haline getirdiği için yapar. Açık kaynak katkıcısı da benzer bir figürdür: Dijital çağın agora meydanında, elindeki bilgiyi saklamak yerine ortak masaya koyar. Bu kişi yalnızca bir programcı değil; sabır, cömertlik, tevazu ve dayanıklılık pratikleri yapan modern bir erdem işçisidir.

Karşılıksızlık gerçekten karşılıksız mı?

Elbette burada naif olmamak gerekir. Hiçbir insan tam anlamıyla çıkar dışı bir varlık değildir. Açık kaynak katkısı prestij kazandırabilir, iş fırsatı yaratabilir, bir topluluk içinde statü sağlayabilir. Fakat bu, eylemin ahlaki değerini otomatik olarak düşürmez. Çünkü erdem etiği açısından önemli olan tekil niyetin laboratuvar saflığı değil, zaman içinde oluşan karakter yönelimidir. İnsan başlangıçta CV için katkı yapabilir; ama süreç içinde paylaşmanın, öğretmenin, düzeltmenin ve birlikte inşa etmenin dönüştürücü zevkini keşfedebilir.

Burada Jungiyen bir gölge de vardır: Açık kaynak, egonun hem parladığı hem sınandığı yerdir. Bir yandan herkesin görebileceği katkılar kişiye sembolik bir ölümsüzlük sunar. Öte yandan kodun eleştirilir, önerin reddedilir, hatan ifşa olur. Kapalı odada dahi gibi görünmek kolaydır; açık depoda kusurlu bir insan olduğunu kabul etmek zordur. Bu yüzden açık kaynak, yalnızca üretim alanı değil, egonun terbiye edildiği bir dojo gibidir.

Bilginin mülkiyeti ve ahlaki cesaret

Modern dünya bilgiyi çoğu zaman bir kale gibi görür: Duvar ör, lisansla, paketle, sat. Açık kaynak ise başka bir metafor önerir: Bilgi bir nehir gibidir; aktıkça temizlenir, paylaşıldıkça çoğalır. Bu yaklaşım, mülkiyeti tümden reddetmek zorunda değildir; ama mülkiyetin mutlak bir kutsal olmadığını hatırlatır. Bir güvenlik açığını yamamak, bir çeviriyi tamamlamak, görme engelliler için erişilebilirliği artırmak; bunların her biri, görünmez insanların hayatına dokunan küçük ama gerçek ahlaki eylemlerdir.

Açık kaynak ahlakının en kışkırtıcı tarafı, iyiliği romantik bir duygu olmaktan çıkarıp altyapıya dönüştürmesidir. Birinin yazdığı ücretsiz bir araç, başka birinin şirket kurmasını sağlar. Bir öğrencinin kullandığı açık ders yazılımı, onun kader çizgisini değiştirir. Bir sağlık araştırmacısı, açık bir veri işleme kütüphanesiyle daha hızlı ilerler. Burada erdem, soyut bir vaaz değil; çalışan, derlenen, indirilen, çatallanan bir gerçekliktir.

Yine de açık kaynak dünyası azizler topluluğu değildir. Tükenmişlik, görünmeyen emek, şirketlerin gönüllü emeği sömürmesi, toksik iletişim ve bakım işinin değersizleşmesi gibi karanlık bölgeleri vardır. Modern erdem etiği burada saf fedakarlığı değil, bilgece sınır koymayı da içermelidir. Kendini yakarak başkalarına ışık olmak kulağa şiirsel gelir; fakat sürdürülebilir değildir. Gerçek erdem, hem vermeyi hem tükenmemeyi öğrenir.

Dijital çağın şövalyeliği

Eski çağların erdemli insanı kılıç taşır, sözünü tutar, zayıfı korurdu. Bugünün erdemli üreticisi belki bir terminal penceresi taşır; ama sınavı benzerdir. Gücü var: bilgi, beceri, erişim, zaman. Soru şudur: Bu gücü yalnızca kendini yüceltmek için mi kullanacak, yoksa ortak dünyanın onarımına mı katacak?

Açık kaynak ahlakı, insanın tanımadığı kişilere karşı sorumluluk hissedebileceğini kanıtlayan sessiz bir devrimdir. Bu devrim pankartlarla değil, küçük commitlerle ilerler. Her katkı şunu fısıldar: İnsan, yalnızca tüketen ve rekabet eden bir canlı değildir; aynı zamanda armağan veren, iz bırakan ve ortak akla güvenen bir varlıktır. Belki de modern erdem dediğimiz şey, tam olarak budur: Kimsenin bakmadığını sandığın yerde bile dünyayı biraz daha çalışır, anlaşılır ve adil hale getirmek.