İyi mühendislik; sadece framework bilmek değil, karar kalitesini artırmaktır. Kitaplar da bu kararı besleyen uzun vadeli yatırımdır.
Yıllardır kendi sunucularımı yönetiyor, SerayERP’i geliştiriyor ve ofis altyapısından dağıtık sistemlere kadar epey farklı katmanda iş çıkarıyorum. Geriye dönüp baktığımda, kariyerimi en çok büküp şekillendiren şeyler tek tek framework’ler değil; birkaç kitabın bende açtığı düşünme alışkanlıkları oldu. Aşağıdaki on kitap, “trend olduğu için” değil, gerçekten masamdaki kararları değiştirdiği için bu listede. Her biri için neden önemli olduğunu ve benim işime nasıl dokunduğunu kısaca yazdım.
1. The Pragmatic Programmer — Andrew Hunt & David Thomas
Bu kitabı listenin başına koymamın sebebi, bir teknolojiyi değil bir tavrı öğretmesi. “DRY”, “broken windows”, “tracer bullets” gibi kavramları günlük dilime soktu; ama asıl kalıcı etkisi, koda “geçici bir karar” gözüyle bakmayı bırakıp her satırın gelecekteki bir maliyet ya da yatırım olduğunu görmek oldu. SerayERP’te bir modülü ikinci kez yamamak zorunda kaldığımda hep bu kitabın “kırık camlar” bölümünü hatırlarım. Yeni başlayan birine tek kitap önereceksem, hâlâ bu.
2. Clean Code — Robert C. Martin
Clean Code’u tartışmasız bir kutsal metin gibi sunmayacağım; bazı kuralları (özellikle aşırı küçük fonksiyon ve agresif “yorum yazma” karşıtlığı) topluluk içinde haklı olarak tartışılıyor ve ben de hepsine katılmıyorum. Ama bu kitabın bana kazandırdığı asıl şey, isimlendirme ve okunabilirliği “estetik” değil ekonomik bir konu olarak görmek oldu: kodu sen bir kere yazarsın, ekipçe yüzlerce kez okursunuz. Ekip içinde “bu fonksiyon ne yapıyor anlaşılmıyor” tartışmalarına ortak bir dil verdiği için değerli. Eleştirel okumanı öneririm — kuralları ezberleme, niyetini al.
3. Refactoring — Martin Fowler
Refactoring, “kötü kodu nasıl tanırım ve riske girmeden nasıl düzeltirim” sorusunun en olgun cevabı. Fowler’ın “code smell” kataloğu ve küçük, test korumalı adımlarla ilerleme disiplini, bende kod tabanına dokunma korkusunu büyük ölçüde söndürdü. Eskiden büyük bir refactor’a girişmek nefesimi tutmamı gerektirirdi; bu kitaptan sonra refactoring’i ayrı bir “proje” değil, her gün yaptığım küçük ve sürekli bir bakım işi olarak görüyorum. Testlerin neden refactoring’in ön koşulu olduğunu da en net burada anladım.
4. Designing Data-Intensive Applications — Martin Kleppmann
Bu kitap benim için bir eşik. Replikasyon, partitioning, consistency modelleri, log-yapılı depolama, consensus… hepsini dağınık blog yazılarından değil, tutarlı bir çerçeveden öğrenmek paha biçilemezdi. SerayERP’in veri katmanında “tek veritabanı yeter mi, ne zaman bölmeli, hangi tutarlılık garantisini veriyorum” gibi kararları artık sezgiyle değil, bu kitaptaki kavramlarla veriyorum. Bir teknolojiyi anlatmıyor; teknolojilerin altındaki değişmeyen ödünleşmeleri (trade-off) anlatıyor — o yüzden eskimiyor. Bence son on yılın en önemli mühendislik kitabı.
5. Release It! — Michael Nygard
Üretim ortamında bir şeyin ilk kez gece yarısı çökmesini yaşadıysan, bu kitap sana yazılmış. Circuit breaker, bulkhead, timeout, “stability vs. capacity” gibi kavramları sistemleştiren ilk kaynak benim için buydu. Kendi sunucularımı yönetirken öğrendiğim çoğu acı dersi — kaskat çöküşler, biten bağlantı havuzları, retry fırtınaları — Nygard çoktan isimlendirip kalıba dökmüş. Kod yazarken “happy path” dışına çıkıp “bu bağımlılık yavaşlarsa ne olur” diye düşünmeyi bana en çok bu kitap öğretti.
6. Site Reliability Engineering — Google (Beyer, Jones, Petoff, Murphy)
SRE kitabı, “sistemi çalışır halde tutmak” işini bir his olmaktan çıkarıp mühendisliğe dönüştürüyor. SLO, error budget, toil, blameless postmortem gibi kavramlar benim küçük ölçekli homelab’imde bile düşünce şeklimi değiştirdi: %100 uptime peşinde koşmak yerine “ne kadar hata bütçem var ve onu nereye harcıyorum” diye sormak. Her bölümü Google ölçeğinde geçerli olmasa da, incident yönetimi ve operasyonel olgunluk bölümleri tek başına kitabı hak ettiriyor. Operasyonu ciddiye alan herkesin başucu kaynağı.
7. The Phoenix Project — Gene Kim, Kevin Behr, George Spafford
Teknik bir kitap değil, bir roman — ve gücü tam olarak burada. DevOps’un neden “araç” değil “akış ve kültür” meselesi olduğunu, bir IT yöneticisinin kâbusa dönen hikâyesi üzerinden anlatıyor. Darboğaz (bottleneck) düşüncesini, görünmeyen işin (unplanned work) yıkıcılığını ve teslimat akışını bu kadar somut anlatan başka bir kitap bilmiyorum. Tek başına çalışan biri olarak bile, kendi “iş yığınımı” ve sürekli böldüğüm odağımı bu kitaptan sonra çok daha net görür oldum. Bir oturuşta bitip insanı düşündüren nadir kitaplardan.
8. Accelerate — Nicole Forsgren, Jez Humble, Gene Kim
Accelerate, DevOps tartışmasını “hislerden” çıkarıp veriye oturtuyor. Deployment frequency, lead time, MTTR, change failure rate — bu dört metriğin (DORA) yüksek performanslı ekipleri gerçekten ayırdığını araştırmayla gösteriyor. Bende yarattığı asıl değişim, “hızlı gitmek” ile “istikrarlı olmak” arasında bir ödünleşme olduğu inancını kırması oldu: doğru yapıldığında ikisi birlikte gelir. Süreç önerilerimi artık sezgiyle değil, bu kitaptaki kanıta dayandırıyorum. İnce ama yoğun.
9. Thinking in Systems — Donella Meadows
Bu, listedeki “yazılım dışı” kitap; ama belki de mühendis kafamı en çok genişleten oydu. Geri besleme döngüleri, stok-akış dengesi, gecikmeler ve “kaldıraç noktaları” (leverage points) kavramları, bir bug’ı tek bir satırda değil, onu doğuran sistemde aramayı öğretti. Bir incident’ın kök sebebine inerken ya da bir sürecin neden sürekli aynı yere takıldığını sorgularken sürekli bu kitabın diline dönüyorum. Yazılımdan ekibe, altyapıdan kişisel alışkanlıklara kadar her yere uyguladığım nadir bir düşünce çerçevesi.
10. The Staff Engineer’s Path — Tanya Reilly
Senior seviyesine geldikten sonra “şimdi ne olacak” sorusunun en dürüst cevabı bu kitap. Yönetici olmadan teknik etkiyi nasıl büyütürsün; yön belirleme, başkalarını çarpan etkisiyle güçlendirme ve görünmeyen “tutkal işini” (glue work) nasıl bilinçli yaparsın — hepsini net anlatıyor. Tek kişilik bir operasyon yürütürken bile, hangi işin gerçekten kaldıraç yarattığını ve hangisinin sadece meşguliyet olduğunu ayırmamda bana çok yardımcı oldu. Kariyerinin ortasındaysan, bu kitap haritayı netleştiriyor.
Sonuç
Bu on kitabın ortak yanı, sana balık vermeyip oltayı tutmayı öğretmesi: hiçbiri belirli bir framework’e bağlı değil, hepsi düşünme biçimini büyütüyor. Bu yüzden de raf ömürleri uzun — beş yıl sonra da geçerli olacaklar.
Okuma alışkanlığım konusunda tek bir tavsiyem var: kitabı bitirmeyi değil, uygulamayı hedefle. Yıllar içinde fark ettim ki bir kitabı baştan sona okuyup hiçbir şey yapmamaktansa, ondan tek bir fikri alıp bir hafta boyunca işime sokmak çok daha kalıcı. Ben artık çoğu teknik kitabı yanımda bir not defteriyle okuyorum; her bölümde “bunu yarın nerede deneyebilirim” diye soruyorum. Liste uzasın diye okumayın; bir sonraki kararınız daha iyi olsun diye okuyun.