İşin aslı şu ki, bir noktadan sonra “en iyi kodu yazan kişi” olmak kulağa havalı geliyor ama kariyer tarafında biraz ters tepebiliyor. Bunu ilk kez — en azından ben öyle düşünüyorum — 2019’un sonlarında, İstanbul’da bir fintech projesinde fark etmiştim; ekibin en hızlı PR kapatan kişisi bendim,. Toplantılarda etkisi en az olan da yine bendim (kendi tecrübem). Acı ama gerçek.
Eh, O dönem kafamda tek ölçü vardı: temiz kod, az hata, şık mimari, tertemiz testler… Yani neredeyse kodu cilalayıp vitrine koyacaktım. Fakat müşteri tarafında sorun bambaşka yerdeydi; raporlar geç geliyordu, operasyon ekibi manuel işten bunalmıştı ve ürün sahibi “bu ekran niye var?” diye soruyordu. Ben ise hâlâ refactor peşindeydim. Açık konuşayım, bayağı yanlış yere bakıyormuşum.
Kodun Parlaması Yetmiyor
Senior olmak ile sadece çok iyi programcı olmak arasında ciddi fark var. Gerçekten ciddi. Hatta bazen ikisi birbirine çarpıyor. Ortaya oldukça garip bir tablo çıkıyor; çünkü teknik mükemmeliyet tek başına değer üretmiyor, asıl mesele o teknik gücü somut iş sonucuna dönüştürebilmekte yatıyor.
İtiraf edeyim, Geçen yıl Ankara’da bir e-ticaret ekibiyle konuşurken bunu yine gördüm. Ekipteki kıdemli geliştirici arkadaşımız tam üç gün boyunca bir servis katmanını baştan sona yeniden düzenlemişti; kod gerçekten güzeldi, hatta insanın içi rahat ediyordu, bakınca “vay be” dedirtiyordu. Gel gelelim satış ekibi hâlâ stok hataları yüzünden kampanya patlatıyordu. Müşteri için önemli olan şey “bu fonksiyon ne kadar zarif yazıldı?” değil, sipariş akışı çalışıyor mu, para kaybediyor muyum — işte buydu soru.
Kendi deneyimimden konuşuyorum, Burada kritik nokta şu: Senior geliştirici çoğu zaman en karmaşık problemi çözen kişi değildir; doğru problemi seçen kişidir. Kimi zaman kirli görünen ama hızlı ilerleten bir çözüm gerekir. Kimi zamansa sağlam temel kurmak şarttır. Yani her şeyi “best practice” diye yontmaya kalkınca iş uzuyor da uzuyor, uzuyor da uzuyor…
Mükemmel Kod mu, Doğru Zamanlama mı?
Bazen kodun güzel olması değil, zamanında teslim edilmesi daha değerlidir. Bilhassa startup ortamında bu iyice belirginleşiyor; küçük ekiplerde bir özelliği haftalarca parlatmanın maliyeti gerçekten büyük olabiliyor,. O sırada rakip ürün pazarı kapar gider (şaşırtıcı ama gerçek). Hızla. Sessizce.
“En iyi kod” bazen en doğru karar değildir; iş hedefini taşıyan yeterince iyi çözüm çoğu zaman daha kıymetlidir.
Senior Developer Aslında Bir Çevirmen Gibidir
Garip gelecek ama, Bence kıdemli geliştiriciyi tanımlayan en net özelliklerden biri çevirmenliktir. Düşünün bir dakika. Teknik dili iş diline çevirir, iş hedefini de teknik önceliğe dönüştürür — bu beceri dışarıdan çok parlak görünmez ama şirket içinde altın değerindedir, gerçekten (ki bu çoğu kişinin gözünden kaçıyor)
Evet, doğru duydunuz.
Şöyle ki, 2023’te Bursa’da üretim odaklı bir projede bunu birebir yaşadım. Fabrika yöneticisi bize “sistem neden bu kadar yavaş?” diye geldiğinde ilk refleksimiz veritabanı indexlerini kurcalamak olmuştu — klasik, değil mi? Sonra sahaya indik ve esas darboğazın ağ bağlantısı zayıf bölgelerde veri senkronizasyonu olduğunu gördük. Yani problem kodda değilmiş gibi davranıyorduk, problem tamamen saha gerçekliğiymiş. Aylar boyunca yanlış yere bakıyorduk işte.
Küçük Startup ile Kurumsal Şirket Aynı Değil
Vallahi, Küçük startup’ta seni büyüten şey hızdır; enterprise tarafta ise sürdürülebilirlik ve risk yönetimi öne çıkıyor. Startup’ta “ilk çalışan versiyon” bazen kahramanlık sayılırken kurumsalda aynı yaklaşım güvenlik açığına dönüşebiliyor. Bağlam her şey, yani.
| Senaryo | Neye Öncelik Verilir? | Kritik Risk |
|---|---|---|
| Küçük startup | Pazar doğrulama, hız, deneme-yanılma | Aşırı mühendislik yüzünden gecikme |
| Büyüyen ölçekli ekip | Süreklilik, gözlemlenebilirlik, bakım kolaylığı | Tek kişinin bildiği sistemler |
| Enterprise seviye | Uyumluluk, güvenlik, dokümantasyon | Küçük değişikliğin zincirleme hasar yaratması |
“Hero” Kompleksi Sessizce Fren Yapar
Eğer sistemi yalnızca siz düzeltebiliyorsanız orada bir başarı yok; aksine, gizli bir kırılganlık var (ciddiyim). Bir süre sonra takım sizden bağımsız hareket edemez hale geliyor ve bu da ölçeklenmenin önüne ciddi biçimde set çekiyor. Daha fazla bilgi için OPPO Find X9 Ultra Basın Görselleri: Devasa Kamera Detayı yazımıza bakabilirsiniz.
Küçük bir detay: Açıkçası ben de buna düşmüştüm. Slack’te gece yarısı gelen mesajlara anında koşan kişi olunca kendinizi vazgeçilmez sanıyorsunuz… ta ki tatildeyken herkesin size bakıp beklediğini fark edene kadar! O anda anladım; benim kahramanlığım takımın öğrenmesini engelliyormuş. Tam anlamıyla. Apple’ın İlk Akıllı Gözlüğü: Tasarımda Neler Belli Oldu? yazımızda bu konuya da değinmiştik.
Bölmek Yerine Paylaştırmak Daha Akıllıca
Kıdemli geliştirici dediğin kişi dokümanı okunduğunda anlaşılır hale getirir; junior’ın akşam saat dokuzda size yazmasına gerek kalmaz, ekip nefes alır. Bir de şu var: bilgiyi saklayan değil paylaşan kişi terfi ediyor gibi görünmeyebilir ama uzun vadede lider olarak öne çıkıyor. Her seferinde. ABD’de Veri Merkezi Freni: Eyaletler Neyi Tartışıyor? yazımızda bu konuya da değinmiştik.
- Sade dokümantasyon yazmak işleri hızlandırır.
- Ekran görüntüsü yerine kısa örnek akış vermek daha işe yarar.
- Tek kişinin bildiği ayarları azaltmak riski düşürür.
Teknik Borç Sadece Kod Meselesi Değil
Teknik borcu genelde tembellikle karıştırıyoruz. Haksız da sayılmayız aslında, görünüşü öyle (evet, doğru duydunuz). Ama çoğu zaman bilinçli alınmış finansal bir karardır bu. Hele bir de eski sistemlerde mesele “niye modern değil?” sorusu değildir; çoğu kez “bu sistem bugün şirkete para kazandırıyor mu?” sorusudur. Yani legacy sistemi küçümsemek kolaydır ama maaşı ödeyen de bazen tam olarak odur…
Ve işler burada ilginçleşiyor.
Daha geçen ay İzmir’de danışmanlık yaptığım küçük bir lojistik firmasında bunu konuştuk. Eski ERP sistemi yirmi yıllıktı ve herkes ondan şikâyet ediyordu. Fakat siparişlerin %80’i hâlâ — kendi adıma konuşayım — onun üzerinden dönüyordu — tamamen söküp atmak yerine araya ince köprüler kurduk; önce entegrasyon katmanı, sonra raporlama API’si. İşi bitiren şey şuydu: duygusal tepki değil, ekonomik mantık.
Bu yüzden senior seviyede düşünmek biraz muhasebeci gibi düşünmeyi de gerektiriyor; hangi borcu şimdi alırsın, hangisini ertelersin, hangisini hiç ellememek gerekir? İşte asıl oyun burada başlıyor.
// Basit karar kontrol listesi
if (feature_speeds_up_revenue) {
ship_quickly();
} else if (tech_debt_blocks_team) {
refactor_targeted();
} else {
leave_it_for_later();
}Peki Ne Yapmalı?
Lafı gevelemeden söyleyeyim: daha fazla algoritma ezberlemek seni otomatik olarak senior yapmaz. Yapmıyor. Daha iyi soru sormak, işi anlamak ve iletişim kurmak yapıyor. Bilhassa ürün yöneticisiyle aynı masaya oturduğunuzda bunu hemen hissediyorsunuz; biri kullanıcı yolculuğunu anlatıyor, diğeri latency konuşuyor… İkisini bağlayabilen kişi yükseliyor, her zaman.
Ben kendi pratiğimde şu dönüşümü faydalı buldum: önce problemi cümleye dökuyorum, sonra teknik seçenekleri sıralıyorum, ardından her seçeneğin maliyetini yazıyorum. Çok basit görünüyor, biliyorum. Ama işe yarıyor; kafa karışıklığını ciddi biçimde azaltıyor.
Bir de dürüst olayım: her şeyi düzgün yapmak zorunda değilsiniz. Bazen “beklediğim kadar değildi” dediğiniz çözüm bile sizi ileri taşıyor çünkü piyasada öğrenme hızı hâlâ saf estetikten değerli. Tartışmasız.
Neyse uzatmayayım — eğer kariyeriniz tıkandıysa kendinize şu soruyu sorun: “Ben gerçekten problemleri mi çözüyorum, yoksa sadece temiz dosyalar mı üretiyorum?” Cevap can sıkıcı olabilir ama faydalıdır.
Ha, bu arada aşağıdaki iki içerik de tam bu zihniyet değişimine denk düşüyor:
Portfolyonuz Mükemmel Görünse de Neden Eski Kalır?
Ve başka bir açıdan bakmak isterseniz:
Yapay Zekâya Akıl Kiralamadan Bakmanın İki Sağlam Yolu
Sıkça Sorulan Sorular
///
Senior developer olmak için en önemli şey nedir?
Sadece çok iyi kod yazmak yetmez… İş hedefini anlayıp doğru çözümü seçebilmek daha önemli.
Mükemmel kod yerine hızlı teslimat ne zaman tercih edilmeli?
Eğer amaç pazar testi yapmak ya da acil iş sorununu çözmekse hızlı teslimat genelde daha doğrudur.
Kusursuzluk için beklemek bazen fırsatı kaçırır.
Teknik borç her zaman kötü müdür?
Hayır.
Bilinçli alınmış teknik borç çoğu projede normaldir; önemli olan onu takip etmek ve kontrolden çıkarmamaktır.
Kendimi code hero olmaktan nasıl çıkarırım?
Cevap basit:
Daha çok paylaşın,
daha az sahiplenin,
dokümantasyonu önemseyin ve işi ürün sonucu üzerinden değerlendirin.
Kaynaklar ve İleri Okuma”>
Martin Fowler — Technical Debt üzerine notlar][Microsoft Learn — DevOps rehberi][Refactoring.Guru — Tasarım desenleri ve pratik açıklamalar]
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
