Son yirmi yıldır sektörde gördüğüm en büyük değişimlerden biri, yazılımcının “tuğla dizen” rolünden “ustabaşı” pozisyonuna evrilmesi oldu. Artık sadece kod yazmak, spesifik bir feature’ı bitirmek yetmiyor; sistemin bütününü, iş akışlarını ve hatta organizasyonel dinamikleri anlamak zorunda kalıyoruz. Bu değişim, bize daha fazla sorumluluk yüklüyor ama aynı zamanda daha büyük bir etki alanı sunuyor.
Bugün, modern yazılım geliştirme ortamında, bir feature’ı tasarlarken sadece teknik implementasyonunu değil, aynı zamanda bunun hangi iş sürecini hızlandıracağını, hangi departmanın hayatını kolaylaştıracağını ve sistemin genel performansına veya güvenliğine nasıl etki edeceğini de düşünmem gerekiyor. Eskiden sadece kod yazıp bitirirken, şimdi neredeyse bir mimar veya danışman gibi hareket ediyorum. Bu, benim gibi sahada uzun yıllar geçirmiş biri için hem zorlayıcı hem de heyecan verici bir dönüşüm.
Eskiden Ne Yapıyorduk? (Tuğla Dizmek ve Odak Noktamız)
Yirmi yıl önce, bir yazılımcı olarak benim temel görevim, bana verilen spec’lere uygun kodu yazmaktı. Odak noktam, genellikle belirli bir modülün veya fonksiyonun doğru çalışmasını sağlamaktı. Bir üretim ERP’sinde çalışırken, mesela, depo giriş-çıkış modülündeki bir raporun performansını optimize etmekle meşguldüm. Orada, 2000 satırlık bir SQL query’yi 30 saniyeden 3 saniyeye indirmek, günümün en önemli olayıydı.
O zamanlar, sistemin genel mimarisi veya diğer modüllerle olan etkileşimleri hakkında çok fazla kafa yormazdım. Bir N+1 problemiyle karşılaştığımda, sadece o anki query’yi optimize ederdim; bu hatanın sistemin başka yerlerinde de olabileceğini veya daha temel bir mimari sorundan kaynaklandığını pek düşünmezdim. Benim için “tuğla dizmek”, yani kod yazmak ve test etmek, işimin büyük bir parçasıydı. O zamanlar, bir PostgreSQL sunucusunun WAL bloat problemi yaşayabileceği veya Redis’in OOM eviction policy’sinin ne anlama geldiği gibi konular, genellikle sistem yöneticilerinin sorumluluğundaydı. Ancak bu sınırlar zamanla silikleşti.
Otomasyon ve AI: Elimizdeki Tornavidalar Değil, İnşaat Makineleri
Günümüzde, otomasyon ve özellikle yapay zeka (AI) araçları, iş yapış şeklimizi kökten değiştirdi. Artık sıkıcı ve tekrarlayan görevleri makinelere bırakabiliyoruz. CI/CD pipeline’ları, otomatik testler ve infrastructure as code (IaC) sayesinde, bir uygulamanın deployment sürecini saatlerden dakikalara indirdim. Bir ara kendi yan ürünümün CI/CD pipeline’ını kurarken, her seferinde elle sunucuya SSH yapıp deploy script’ini çalıştırmaktan bıkmıştım. Sonra GitLab CI/CD ile otomatize ettim ve deploy süreçlerinin güvenirliği %90 arttı.
AI’ın hayatımıza girmesiyle birlikte, kod yazma süremiz de azaldı. Kendi projelerimde, prompt engineering teknikleriyle AI’dan kod snippet’leri, hatta bazen tüm fonksiyonlar bile alıyorum. Bu, bana daha çok zaman kazandırıyor ve ben de bu zamanı, sistemin mimarisi, farklı component’lerin entegrasyonu ve iş akışlarının iyileştirilmesi gibi daha üst düzey konulara ayırabiliyorum. Bir AI destekli operasyon pipeline’ı tasarlarken, Groq ve Gemini Flash gibi farklı provider’ları bir araya getirip, latency ve maliyet trade-off’larını yönetmek, artık benim için kod yazmaktan daha önemli hale geldi.
# Basit bir FastAPI endpoint'i örneği, AI ile üretilebilir ama mimarisi bizim işimiz
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
app = FastAPI()
class Item(BaseModel):
name: str
description: str | None = None
price: float
tax: float | None = None
@app.post("/items/")
async def create_item(item: Item):
if item.price < 0:
raise HTTPException(status_code=400, detail="Price cannot be negative")
# Veritabanına kaydetme veya başka bir iş mantığı buraya gelir
return {"message": "Item created successfully", "item": item}Ustabaşı Zihniyeti: Bütünsel Bakış ve Sistem Mimarisi
Ustabaşı zihniyeti, sadece bir tuğlayı doğru yere koymak yerine, tüm binanın nasıl ayakta duracağını düşünmeyi gerektirir. Bir yazılımcı olarak artık bir feature’ı geliştirirken, onun sistemdeki diğer modüllerle nasıl etkileşime gireceğini, hangi veritabanı tablolarını etkileyeceğini ve hatta network katmanında nasıl bir yük oluşturacağını hesaba katmak zorundayım. Bir üretim ERP’sinde çalıştığımda, bir operatör ekranı tasarlarken sadece UI/UX’i düşünmedim. Aynı zamanda o ekranın hangi sensör verilerini çekeceğini, üretim planlama motoruyla nasıl entegre olacağını ve iSCSI entegrasyonuyla tedarik zincirine nasıl yansıyacağını da planladım.
Bu, Monolith vs Microservice mimarisi seçimleri gibi büyük kararlar almayı da kapsıyor. Bir projede, hızlı MVP için monolith ile başlayıp, daha sonra kritik modülleri microservice’lere dönüştürme kararı aldık. Bu karar, tamamen maliyet, geliştirme hızı ve ölçeklenebilirlik trade-off’larına dayanıyordu. Event-sourcing ve CQRS pattern’lerini uygularken, idempotency’yi sağlamak için transaction outbox pattern’ını nasıl kullanacağımızı tasarladım. Bu tür kararlar, artık sadece mimarların değil, deneyimli yazılımcıların da masasında.
İş Akışını Anlamak: Koddan Önce Organizasyon
Yazılım mimarisinin, çoğu zaman organizasyonel akışın bir yansıması olduğunu tecrübe ettim. Sadece kod yazmakla kalmayıp, iş süreçlerini ve organizasyonel yapıyı anlamak, doğru çözümleri üretmenin anahtarı. Bir üretim firmasının ERP’sinde, gecikmiş sevkiyat raporları sürekli hatalı geliyordu. İlk başta veritabanı sorgularında veya kodda bir hata aradım, ancak root cause bambaşka bir yerdeydi. Depo çalışanları, sevkiyat bilgilerini sisteme manuel olarak, belli bir gecikmeyle giriyordu. Sorun yazılımda değil, iş akışındaydı.
Bu durumda, benim rolüm sadece kodu düzeltmek değil, aynı zamanda depo operasyonları ekibiyle konuşup süreci otomatize etmek için yeni bir entegrasyon tasarlamaktı. Bu, IFRS entegrasyonlarını veya tedarik zinciri optimizasyonlarını da içeriyordu. Yazılımcının artık bir “iş analisti” gibi düşünmesi, hatta bazen bir “organizasyon danışmanı” gibi hareket etmesi gerekiyor. Kodun ötesine geçip, gerçek dünya problemlerini anlamak ve çözmek, bugünkü işimizin ayrılmaz bir parçası.
graph TD
A["Gecikmiş Sevkiyat Raporu Hatalı"] --> B{"Kod/DB Hatası mı?"}
B -- Hayır --> C["Depo Operasyonları İncelenir"]
C --> D["Manuel Veri Girişi Gecikmesi Tespit Edildi"]
D --> E["Otomasyon İhtiyacı Belirlendi"]
E --> F["Yeni Entegrasyon Tasarımı (API/MQ)"]
F --> G["Depo Ekibiyle Süreç İyileştirme"]
G --> H["Rapor Doğruluğu Arttı"]
B -- Evet --> I["Kod/DB Optimize Edilir"]
Güvenlik ve Operasyon: Duvarların Sağlamlığı ve Bakımı
Eskiden, güvenlik ve operasyonel işler genellikle ayrı ekiplerin sorumluluğundaydı. Ben sadece kodu yazardım, gerisini sistem yöneticileri veya güvenlik uzmanları hallederdi. Ancak, günümüz dünyasında bu ayrım ortadan kalktı. Artık yazdığım kodun güvenliğini ve uygulamanın operasyonel sağlığını da düşünmek zorundayım. Bir kernel module blacklist (örneğin, algif_aead için CVE-2026-31431 gibi güvenlik açıkları), fail2ban paternleri veya SELinux profilleri gibi konular, artık sadece sistem yöneticilerinin değil, benim de takip etmem gereken şeyler.
Geçen ay, bir container’ın sleep 360 komutuyla OOM-killed olduğunu gördüm çünkü cgroup memory.high limiti doğru ayarlanmamıştı. Bu basit bir hataydı ama uygulamanın downtime’ına neden oldu. Sonra polling-wait mekanizmasına geçerek bu sorunu çözdüm. PostgreSQL’de WAL bloat’ı veya Redis’te OOM eviction policy’leri gibi konuları yakından takip ediyorum çünkü bu durumlar direkt olarak uygulamamın performansını ve kararlılığını etkiliyor. Bu yüzden, yazdığım kodun sadece functionality’sini değil, aynı zamanda systemd unit’lerini, journald loglarını ve cgroup limitlerini de yönetmem gerekiyor.
# Bir sistemde memory limit'leri kontrol etmek için kullanılabilecek komut
# Bu, container'ların veya servislerin bellek kullanımını anlamak için kritik.
cat /sys/fs/cgroup/memory/memory.max
# journald rate limit'lerini yapılandırmak, log spam'ini önlemek için önemlidir.
# /etc/systemd/journald.conf içinde ayarlanır.
# RateLimitIntervalSec=30s
# RateLimitBurst=1000Geleceğin Yazılımcısı: Mühendislikten Orkestrasyona
Geleceğin yazılımcısı, artık sadece bir mühendis değil, aynı zamanda bir orkestra şefi. Kod yazma yeteneğimiz hala temel olsa da, asıl değerimiz artık farklı sistemleri, teknolojileri ve insanları bir araya getirme becerimizde yatıyor. Problem çözme, tasarım, entegrasyon ve iletişim becerileri, teknik yeteneklerimiz kadar önemli hale geldi. Bir yan ürünümün backend’inde, farklı AI provider’larını (Gemini Flash, Groq, Cerebras) OpenRouter üzerinden nasıl bir araya getirdiğimi ve olası kesintilere karşı bir fallback stratejisi geliştirdiğimi hatırlıyorum. Bu, sadece kod yazmaktan çok, bir sistemin farklı parçalarını bir araya getiren bir orkestrasyon işiydi.
Bu dönüşüm, sürekli öğrenmeyi ve kendimizi geliştirmeyi zorunlu kılıyor. Sadece yeni programlama dilleri veya framework’ler öğrenmekle kalmıyor, aynı zamanda network güvenliği (ZTNA egress kontrol, segmentasyon), veritabanı optimizasyonları (PostgreSQL index stratejileri, replikasyon) ve CI/CD süreçleri gibi alanlarda da bilgi sahibi olmamız gerekiyor. Kendi Android spam blocker uygulamamı geliştirirken, Flutter ile native paket entegrasyonu yapmak veya Play Store yayınlama süreçlerini yönetmek, benim için sadece birer teknik görev olmanın ötesinde, bütünsel bir ürün geliştirme deneyimiydi.
Yazılımcının rolü, artık sadece talimatları uygulayan bir “tuğla dizen” değil, projeyi bütünsel olarak gören, farklı uzmanlık alanlarını bir araya getiren ve işin her aşamasında aktif rol alan bir “ustabaşı” oldu. Bu, daha fazla sorumluluk demek, evet, ama aynı zamanda yaptığımız işin etkisini artırmak ve daha tatmin edici kariyerler inşa etmek için de büyük bir fırsat sunuyor. Bu değişime ayak uyduranlar, sektörde kalıcı ve değerli olacak.