Kariyerimin ilk yıllarında, bir geliştirici olarak en büyük sorunum hep bir if koşulu ya da PostgreSQL’deki karmaşık bir JOIN sorgusu olurdu. Gözümde en büyük başarı, karmaşık bir algoritmayı hatasız yazıp çalıştırmaktı. Şimdilerde ise, yirmi yıl sonra dönüp baktığımda, kod yazmanın işin en kolay kısmı haline geldiğini görüyorum.
Bu, kodun önemsiz olduğu anlamına gelmiyor elbette. Ancak bir projenin gerçek zorlukları, genellikle klavye başında yazdığımız satırların çok ötesinde yatıyor. Artık asıl mücadele, insanlarla, süreçlerle ve organizasyonel akışla.
Kodun Kolaylaşan Yüzü ve Yeni Zorluklar
Bugün, FastAPI ya da Vue/React gibi modern framework’lerle bir uygulamanın iskeletini kurmak veya AI destekli araçlarla rutin kod bloklarını oluşturmak hiç olmadığı kadar hızlı. Neredeyse her ihtiyaca yönelik hazır kütüphaneler ve çözümler mevcut. Bu durum, teknik olarak kod yazma eylemini basitleştirdi.
Bir üretim ERP’sinde yeni bir operatör ekranı tasarladığımda, frontend ve backend kodunu yazmak işin kısa süren tarafı. Ama o ekranın operatörün gerçek ihtiyacını karşılaması, üretim planlama AI’sından gelen veriyi doğru işlemesi ve diğer iSCSI tedarik zinciri entegrasyonlarıyla sorunsuz çalışması, asıl düşünmem gereken şeyler oluyor. Kod sadece bir araç, asıl iş bağlamı anlamak ve onu dönüştürmek.
Görünmez Engeller: İnsan, Süreç ve Politikalar
Gerçek zorluklar, kodun ötesindeki dünyadan geliyor. Bir müşteri projesinde, güvenlik ekibinin yeni bir firewall politikası yüzünden VPN bağlantıları gece saatlerinde kesiliyordu. Kodda bir hata yoktu, ama sistemin entegrasyon akışı duruyordu ve bu sorunu çözmek hayli zaman aldı.
Benzer şekilde, teknik olarak dört dörtlük tasarlanmış bir kimlik doğrulama (OAuth2) akışında bile, farklı departmanların birbiriyle çelişen güvenlik beklentileri rate limiting gibi basit kararları uzayıp giden bir uzlaşma sürecine çevirebiliyor. Böyle dönemlerde ne bir satır kod yazarsınız ne de bir bug düzeltirsiniz; iş, insanları dinlemek, ikna etmek ve ortak nokta bulmaktan ibaret olur.
Mimari Kararların Ağırlığı
Sistem mimarı olarak, bir yazılım mimarisi tasarlarken monolith mi microservice mi kararını vermek, ORM tuzaklarından kaçınmak ya da transaction outbox desenini uygulamak, kod yazmaktan çok daha fazla düşünce gerektiriyor. Bu kararlar, projenin geleceğini, bakım maliyetlerini ve ölçeklenebilirliğini doğrudan etkiliyor. PostgreSQL’de doğru index stratejilerini seçmek, connection pool’u ayarlamak ya da WAL bloat sorununu öngörmek, saf kodlama becerisinden çok daha fazlasını istiyor.
Son zamanlarda AI uygulamaları üzerinde çalışıyorum. Prompt engineering veya RAG mimarilerini kurmak, modelin kendisinden çok, doğru veriyi bulmak, kullanıcı intent’ini anlamak ve çoklu provider fallback stratejileri geliştirmekle ilgili. Burada da kod sadece bir aracı, asıl zorluk sistemin tamamını tasarlamak ve yönetmek.
Gerçek Maliyet ve Çıkarılan Dersler
systemd unit’lerinde çalışan bir background process’e cgroup memory.high limiti koymayı unuttuğunuz bir an düşünün. Kod hatası değil, basit bir konfigürasyon eksikliği. Sonuç: gece yarısı OOM-killed olan bir servis ve uzun bir debug seansı. Bu tür durumlar, asıl meselenin kodun değil, sistemin bütününe hakim olmak olduğunu bir kez daha gösteriyor.
Kariyerimde öğrendiğim en önemli derslerden biri şu: En pahalı hatam, çoğu zaman bir kod satırı değil, bir toplantıda “evet” dediğim ama sonuçlarını tam öngöremediğim bir karardı. Ya da bir requirement’ı sorgulamadan kabul etmemdi. Bu hataların maliyeti, haftalarca süren refactor’lar, rollback’ler ya da kaçırılmış son teslim tarihleri olabiliyor.
Kod yazmak artık en kolay kısım. Asıl ustalık, o kodun nefes aldığı ekosistemi anlamakta, yönetmekte ve optimize etmekte yatıyor.
Peki senin kariyerinde kodun kolay, çevresinin zor olduğu anlar hangileriydi? En pahalı “evet” dediğin karar neydi? Yorumlarda duymak isterim.