Teknik Borç ve Kariyer: Stack mi, Beceri mi Belirliyor?
"Legacy kodda çalışıyorum, kariyerim mahvoluyor mu?" - bu soruyu her ay onlarca yazılım geliştiriciden duyuyoruz. Refactor projesi, teknik borç temizliği, eski monolitin mikro servise dönüşümü: hepsi kariyer puan kaybı gibi hissettiriyor.
Hissettiriyor, ama gerçek farklı.
Teknik Borç Nedir, Gerçekten?
Teknik borç, kısa vadeli kararların uzun vadeli maliyetidir. Hızlı teslim için yazılan yama kod, test edilmemiş kritik modül, belgesiz servis - bunlar birikince sistemin her değişikliği daha pahalıya çıkar.
Bir sistemde teknik borç varsa bu şu anlama gelir: o kod tabanı değerli. Kimse önemsiz bir ürünü yıllarca ayakta tutmaz.
"Refactor Projesi Kariyer Zararı" Efsanesi
En yaygın yanlış inanç: yeni özellik geliştiren geliştiriciler terfi alır, teknik borç temizleyenler görünmez kalır.
Bu inanç kısmen doğru, kısmen yanlış.
Görünmez kalan şey şu değil:
- Ne iş yaptığın
- Hangi teknolojiyi kullandığın
Görünmez kalan şey şu:
- Etkinin nasıl anlatıldığı
- Kimin hangi sorunu çözdüğünü bilip bilmediği
Türkiye'deki birçok şirkette mühendislik ekipleri, refactor çalışmasını "temizlik" olarak çerçeveler. Oysa aynı çalışma "sistemin deploy süresini 45 dakikadan 8 dakikaya indirdik" veya "bug hızını aylık 40'tan 6'ya düşürdük" diye anlatılabilir.
Rakamla anlatılan teknik iş, performans değerlendirmede görünür olur.
Stack Gerçekten Maaşı Belirliyor mu?
getSalary 2026 verilerine göre yazılımcıların maaş dağılımı incelendiğinde, aynı kıdem seviyesinde stack'e göre önemli farklar çıkıyor. Ama bu fark sanıldığı kadar net değil.
Yüksek taleple öne çıkan stack'ler:
- Go, Kotlin, Rust - piyasada az ama talep yüksek
- React, TypeScript - talep geniş ama arz da geniş
- Python (ML/veri yolunda) - maaş etkisi kıdeme ve uzmanlığa bağlı
Düşük ücret + yüksek teknik borç kombinasyonu gördüğümüz alanlar:
- PHP ağırlıklı eski e-ticaret monolitleri
- Bakımsız Java EE uygulamaları
- React Native'in ilk nesil kodları
Dikkat: Bu liste "şu dili bilirsen kazan, şunu bilirsen kazanamazsın" demek değil. Aynı Java bilgisi ile birisi 80.000 TL alırken diğeri 200.000 TL alıyor. Fark stack'te değil, problem çözme kapasitesinde ve görünürlükte.
Refactor Projesi Seni Nasıl Öldürür - Nasıl Büyütür?
Öldüren senaryo
Şirket, eski sistemi yenisiyle değiştirmeye karar verdi. Seni "teknik borç ekibine" koydular. 18 ay boyunca kimsenin görmediği kodu yeniden yazdın. Bir özellik eklenmiyor, sadece mevcut şeyler taşınıyor. Yöneticin diğer ekipteki "yeni özellikleri" biliyor ama senin katkını anlamıyor. Terfi sıranda değilsin.
Bu senaryo gerçek. Ama suçlu teknik borç değil, anlatım eksikliği.
Büyüten senaryo
Aynı proje. Ama bu sefer:
- Her hafta ekip içinde "bu hafta kaldırdığımız teknik borç X etkisi yarattı" diye paylaşıyorsun
- Kalibrasyon sürecinde yöneticine somut metrikler veriyorsun: test kapsamı %12'den %68'e çıktı, ortalama hata düzeltme süresi 4 günden 6 saate indi
- Teknik tasarım kararlarını yazılı belgeliyorsun (RFC, ADR) - bu belgeler senin teknik liderlik kanıtın oluyor
Aynı proje, iki farklı kariyer sonucu. Fark tamamen anlatımda.
"Benim Stack'im Eski, Değişmeliyim" Baskısı
Türkiye yazılım sektöründe sık görülen bir panik: "Şirket hala Java 8 kullanıyor, gidip React + Node öğrenmeli miyim?"
Cevap: Belki değil.
Şu soruları sor:
1. Mevcut alanda tavan var mı?
Bulunduğun teknoloji yığınında Senior ve üstü pozisyonlar açılıyor mu? İş ilanlarına bak. Eğer 5 yıllık Java geliştiricisi için ilanlar varsa piyasa canlı.
2. Yatırım getirisi ne kadar?
Yeni bir stack öğrenmek 3-12 ay ciddi zaman ister. Bu sürede kaybettiğin kariyer ivmesi, geçiş sonrası kazanacağından fazla olabilir.
3. Geçişin amacı ne?
Gerçek ilgi mi, panik mi? Panikle yapılan geçişler genellikle yarım kalır veya "sıfır deneyimli" bandında başlatır.
Stack değişimi kariyer stratejisi olabilir - ama varsayılan çözüm değil.
Teknik Borçlu Sistemde Büyümek: 4 Pratik Adım
1. Kaldırdığın borcu sayısal ifadeye dök
"Test ekledi" değil, "test kapsamını %X artırdı, Y tür hatayı önledi." Kalibrasyon sezonunda elinde veri olsun.
2. Mimari kararları yaz
RFC veya ADR yaz. Sadece kod değil, neden o kararı aldığını belgele. Bu belgeler teknik liderlik kanıtıdır.
3. Teknik borcun iş etkisini çevir
Mühendislik dili ile iş dili farklı. "Deploy pipeline'ı hızlandırdım" yerine "yeni özellik teslim hızını 2 katına çıkardık" söyle.
4. Görünürlük için yöneticini eğit
Yöneticin her sprint detayını bilmek zorunda değil. Ama çeyrek sonunda "ekip şu etkiyi yarattı" demesi gerekiyor. Bu cümleyi ona önceden ver.
Peki Ya Gerçekten Kariyer Zarar Görüyorsa?
Bazı şirketler teknik borç çalışmasını gerçekten değersizleştiriyor. Performans sistemleri sadece yeni özellikleri sayıyor, bakım ve altyapı görünmez kalıyor.
Bu durumda yapılacak şey:
- 2 kalibrasyon dönemini bekle, değişim yoksa sinyal almış olursun
- Şirket dışında portföy oluştur: teknik yazı, açık kaynak katkı, konuşma
- Refactor deneyimini mülakata taşı: "X ölçekli sistemi Y sonuca götürdüm" hikayesi güçlü bir mülakat materyali
Performans değerlendirmede görünürlük stratejisi için ayrı bir rehber hazırladık.
Özet: Stack mi, Beceri mi?
Eğer seçmek zorunda olsaydın:
| Stack Değiştirmek | Beceri Derinleştirmek | |
|---|---|---|
| Kısa vadeli maaş etkisi | Düşüş riski (sıfır deneyimli başlama) | Artış riski (uzman fiyatı) |
| Uzun vadeli | Yüksek (talep değişirse avantaj) | Yüksek (derinlik piyasada ödüllendiriliyor) |
| Kariyer hızı | 6-18 ay yavaşlama | Sürekli ivme |
| Tavsiye | Gerçek ilgi + piyasa sinyali varsa | Varsayılan strateji |
Sonuç: Teknik borçlu bir sistemde çalışmak kariyer zararı değil. Ama o çalışmayı görünür kılmamak kariyer zararı. Stack belirleyici değil; problemi çözme kapasitesi ve onu anlatma becerisi belirleyici.
Maaşını artırmak için hangi stratejilerin işe yaradığını gösteren analizimize bakabilirsin.