Kariyerimin en pahalı hatası bir kod satırı değildi; bir “evet”ti. Yirmi yıl önce, henüz kariyerimin başındayken, önüme çıkan her fırsata “evet” diyerek ilerliyordum. Oysa şimdi geriye dönüp baktığımda, o “evet”lerin bazılarının aslında “hayır” olması gerektiğini biliyorum. Bu yazı, 2006’daki bana, hatta şimdiye kadar pek çok teknoloji profesyoneline rehberlik etmiş olabilecek, tavsiye değil, bizzat yaşadığım yara izlerini taşıyan 7 dersi aktarıyor.
Bu yolculuk, sadece teknik becerilerle değil, aynı zamanda insan ilişkileri, doğru projeyi seçme ve kendi sınırlarını tanıma ile dolu. Hiçbir zaman kuru bir nasihat listesi olmadı bu yazdıklarım; her biri, üzerinde saatlerce düşündüğüm, yüzlerce kez gözden geçirdiğim ve nihayetinde kariyerimi şekillendiren tecrübelerdir. Hazırsanız, o zamanlar bilmediğim ama şimdi her satırında hakikati gördüğüm bu yedi derse birlikte bakalım.
1. “Ev Et” Demek, Her Zaman İleri Gitmek Değildir
Gençken, her yeni proje, her yeni teknoloji heyecan vericiydi. Bir üretim ERP’sinin backend’ini yazarken, aklımda hep daha fazla özellik, daha karmaşık çözümler vardı. Bir yandan iSCSI tabanlı tedarik zinciri entegrasyonu yaparken, diğer yandan operatör ekranları için yeni UI elementleri tasarlıyordum. O dönemde, bir fırsata “evet” demek, kariyerimde bir adım daha atmak anlamına geliyordu. Ancak bu, bazen beni doğru yöne değil, sadece daha meşgul bir yola sokuyordu.
Bu durum, özellikle kurumsal yazılım geliştirme tarafında kendini gösterdi. Sürekli yeni özellikler eklemek yerine, mevcut kod tabanını iyileştirmek, performansı optimize etmek veya güvenlik açıklarını kapatmak da en az yeni özellik geliştirmek kadar değerliydi. Ancak o zamanlar, bu tür “arka plan” işleri pek cazip gelmiyordu. Sonuç olarak, yıllarca pek çok projede “biraz daha fazla ekle” döngüsüne girdim.
2. Her Teknik Derinlik, Değerli Değildir
Network altyapısı tasarlarken, her zaman en karmaşık ve en verimli çözümü arardım. VLAN segmentasyonu yaparken, sadece temel ağları değil, her bir departman için özel subnet’ler ve hatta her bir sunucu için ayrı VLAN’lar oluşturmayı düşünürdüm. Bu derinlik, bazı durumlarda harika olsa da, genellikle yönetimi aşırı derecede karmaşıklaştırdı. Switching ve routing konfigürasyonlarında, her paketin izlediği yolu en ince ayrıntısına kadar anlamak, zamanımın büyük bir kısmını alıyordu.
Örneğin, bir şirketin çıkışında (gateway) 3 farklı ISP varsa, DSCP marking’in doğru yapılmaması durumunda ses paketlerinin patlaması kaçınılmazdır. Bu tür ince ayarlar, bir yandan ağ performansını optimize ederken, diğer yandan da doğru konfigürasyon yapılmazsa ciddi sorunlara yol açabilir. O dönemde, bu ince detaylara odaklanmak bana bir uzmanlık hissi veriyordu, ancak gerçekte sadece daha fazla hata payı yaratıyordum.
3. Kendi “Yan Ürün”lerinizi Yaratmak, Öğrenmenin En Hızlı Yolu
Kendi VPS’imde finansal hesaplayıcılar geliştirmek, Android için bir spam engelleyici yapmak veya anonim bir veri platformu kurmak… Bunlar, kariyerimin ilk yıllarında pek çok defa yaptığım şeylerdi. O zamanlar, bunları sadece kişisel projeler olarak görüyordum. Ancak şimdi anlıyorum ki, bu “yan ürünler”, bana en çok şeyi öğretenler oldu. Bir üretim ERP’sinde çalışırken öğrendiklerim değerliydi, ama kendi başıma sıfırdan bir sistem kurarken karşılaştığım sorunlar bambaşkaydı.
PostgreSQL veritabanı ayarlarını kurcalamak, Redis’in OOM (Out Of Memory) eviction policy’lerini denemek, Nginx’i reverse proxy olarak konfigüre etmek veya Docker Compose ile basit orchestrasyon yapmak… Tüm bu denemeler, bana sistem yönetimi konusunda eşsiz bir deneyim kazandırdı. Bir kurumsal projede bu kadar özgürce deneme yapma şansınız olmayabilir.
4. Güvenlik, Bir Modül Değil, Mimari Bir Zorunluluktur
Kariyerimin başlarında, güvenliği genellikle projelerin sonuna doğru eklenen bir “yama” gibi görüyordum. Bir uygulama geliştirdikten sonra, “şimdi bunu nasıl güvence altına alalım?” diye düşünürdüm. Kernel module blacklist (örneğin CVE-2026-31431 gibi zafiyetlere karşı), fail2ban kuralları yazmak veya JWT/OAuth2 pattern’lerini anlamak gibi konuları, sonradan eklenen detaylar sanırdım. Ancak bu yaklaşımın ne kadar yanlış olduğunu kısa sürede anladım.
Gerçekten de, switch hardening (DHCP snooping, DAI, IP source guard gibi özelliklerle), routing authentication (OSPF/IS-IS gibi protokollerde), veya Zero Trust Architecture (ZTNA) gibi konular, en baştan planlanması gereken mimari kararlardır. Bir ağ segmentasyonu tasarlarken, VLAN sayılarının yetersiz hesaplanması gibi hatalar, sonradan düzeltilmesi çok daha maliyetli olan güvenlik zafiyetleri yaratır. Güvenlik, gerçekten de baştan sona düşünülmesi gereken bir katmandır.
5. Hatalarınızdan Ders Çıkarmak, En İyi Öğretmendir
Bir keresinde, bir sistemdeki WAL bloat sorununu çözmeye çalışırken, yanlışlıkla autovacuum ayarlarını değiştirdim ve sistem neredeyse durma noktasına geldi. Saat 03:14’te WAL rotation alarmı çalmıştı ve ben ne yapacağımı bilemez haldeydim. Bu tür anlar, kariyerimin en öğretici anları oldu. Kendi yarattığım sorunları çözmek, bana bir başkasının yazdığı kodu debug etmekten çok daha fazla şey öğretti.
Başka bir örnek olarak, bir keresinde sleep 360 komutunu yanlış yerde kullanarak OOM-killed oldum. Bu basit hata, bana polling-wait mekanizmasının önemini öğretti. Bu tür somut deneyimler, soyut teorik bilgilerden çok daha kalıcıdır. Hangi semptomun, hangi hatanın, ne zaman ve nasıl ortaya çıktığını anlamak, gelecekteki problemleri öngörmenize yardımcı olur.
6. Organizasyonel Akış, Yazılımdan Daha Önemlidir
Bir üretim firmasının ERP’sini geliştirirken, en çok zorlandığım şeylerden biri, yazılımın kendisi değil, şirketin işleyiş akışını doğru anlamaktı. Satın alma, üretim, sevkiyat ve faturalama süreçlerinin yazılıma nasıl yansıtılacağı, çoğu zaman yazılım mimarisinden daha karmaşık bir organizasyonel problemdi. Bir veritabanı index stratejisi seçmek kolaydı, ama “bir siparişin üretim planına nasıl dahil olacağını” belirlemek çok daha zordu.
Bu nedenle, yazılım geliştirme projelerinde başarılı olmanın anahtarı, sadece kod yazmak değil, aynı zamanda iş mantığını ve organizasyonel dinamikleri de kavramaktır. Bir “monolith vs microservice” kararından daha kritik, “bu yeni özelliği mevcut iş akışına nasıl entegre edeceğiz?” sorusudur. Bu, benim için özellikle üretim ERP’si tarafında büyük bir aydınlanma oldu.
7. Kendi Sınırlarınızı Bilmek ve Yardım İstemek
Kariyerimin başlarında, her şeyi kendi başıma çözebileceğimi sanırdım. Bir network probleminde, bir veritabanı performans sorununda veya bir güvenlik zafiyetinde, ilk tepkim hemen kendim dalmaktı. Ancak bazen, bir sorunu çözmek için dışarıdan bir gözün veya farklı bir uzmanın bakış açısına ihtiyaç duyduğumu fark ettim. Özellikle karmaşık sistemlerde, örneğin bir BGP routing kararının neden yanlış olduğunu anlamak, tek başıma saatlerce sürebiliyordu.
Bu, özellikle “Zero-Trust” gibi modern güvenlik mimarilerinde de geçerli. Tahminsel veya anomali tabanlı izleme sistemleri kurarken, sadece kendi bildiklerimle yetinmek yerine, farklı yaklaşımları araştırmak ve uzmanlarla konuşmak, çok daha iyi sonuçlar verdi. Kendi yeteneklerimi ve bilgilerimin sınırlarını kabul etmek, beni daha iyi bir mimar ve daha etkili bir problem çözücü yaptı.
Yirmi yıl önce kendime bu yedi dersi verebilseydim, eminim ki yolum biraz daha düzgün olurdu. Ancak bu yara izleri, aynı zamanda benim bu günlere gelmemi sağlayan en değerli derslerim. Her biri, üzerinde düşünülmüş, yaşanmış ve kanıtlanmış gerçekler.
Şimdi size soruyorum: Kariyerinizde geriye dönüp baktığınızda, 20 yıl önceki kendinize hangi 3 şeyi söylerdiniz? Ya da sizin en büyük “yara izi”niz ne oldu? Yorumlarda paylaşın, tartışalım.