Yazılımcı Olmak Sadece Kod Yazmak Değil

İş dünyasında yazılımcı olarak uzun süre kalmak istiyorsan bir şeyi erken öğrenmen lazım: şirket seni yazdığın satır sayısı için değil, çözdüğün iş problemi için tutuyor. Bu cümle kulağa bariz geliyor ama fiyata bakınca çok sayıda developer'ın hayatının büyük kısmını "kaç satır yazdım" metriğiyle geçirdiğini görüyorsun.

Oysa seni junior'dan senior'a, senior'dan staff'a götüren eşik kodun kalitesi değil — kodun neden var olduğunu anlaman.

"Bana ne söylerlerse onu yaparım" tuzağı

Bir developer olarak en kolay yol bu: product manager bir bilet açar, sen yaparsın, test yazarsın, push edersin, bir sonraki bilete geçersin. Hiç yanlış yapmıyormuşsun gibi hissettirir, çünkü teknik olarak doğru iş üretiyorsun.

Sıkıntı: bu akışta yanlış özelliği doğru şekilde yapma ihtimalin inanılmaz yüksek. Bilet sana ulaşana kadar zaten 3-4 kademe fikir kaybı olmuştur. Kullanıcı "A istiyorum" der, product ekibi "B'yi A olarak modelleriz" diye yorumlar, sana gelirken "C'yi B'nin altına koy" bileti düşer. Sen C'yi harika yaparsın. Kullanıcı hâlâ A'yı istiyordur.

Bunu kırmanın yolu biletin üstüne çıkmak. "Neden?" diye sormak. "Kim kullanacak?" diye sormak. "Başarı nasıl ölçülecek?" diye sormak.

Business'a hakim olmak ne demek

Kimse senden MBA beklemiyor. Bunlar yeterli:

• Şirketin nasıl para kazandığını — hangi kanal, hangi müşteri, hangi metrik.
• Senin ekibinin bu kazanca nasıl katkıda bulunduğunu — latency mi önemli, conversion mı, retention mı.
• Kullanıcı kimliğini — persona, kullanım senaryoları, temel acı noktaları.
• Rakiplerin ne yaptığını — "biz niye bu kadar karmaşık kuruyoruz?" sorusunun cevabı çoğu zaman buradan çıkar.

Bunları öğrenmenin yolu bariz: ürün ekibiyle konuşmak, analytics panelini açmak, müşteri desteğine oturmak, rakip ürünleri kullanmak. 2 ayınızı bu tür işlere ayırdığında kod yazarken verdiğin kararlar bambaşka olur.

Gerçek bir örnek

Yıllar önce bir oyun platformunda çalışırken "matchmaking'i optimize et" biletine benziyordu görevimiz. Teknik olarak doğru iş: tuttuğumuz queue'ları azalt, işlemi asenkronize et, latency'yi düşür.

Bir öğleden sonra analytics'e baktım. Sorun latency değildi — match kalitesi idi. Oyuncular "hızlı bulunmuş" kötü eşleşmelerden şikayet ediyordu. Latency düşürmek istenilen şey değil, aksine biraz yükseltip daha iyi eşleştirme yapmak istenilen şeydi.

Teknik olarak biletten sapan bir karar aldım ve o tarafı iyileştirdim. Sonuçta müşteri memnuniyeti yukarı gitti, oyuncu ömrü uzadı, şirket daha fazla gelir elde etti. Hiçbir zaman "latency optimizasyonu yaptım" diye yazamadım değerlendirmeye — ama asıl yapılması gereken işti ve yaptığım için kimse şikayet etmedi.

Bu seviyeye nasıl geliyorsun

Üç basit alışkanlık:

1. Her özellik için metrik bul. Gemini bu veri yok diyorsa, geçici bir yol bul. Ölçmeden kodlanan bir şey iyi kodlanmış değildir, sadece yazılmıştır.
2. Ürün ekibine gerçek sorular sor. "Bu özelliği niye yapıyoruz?" değil — o rahatsız edici — "bu özelliği ölçmek için neye bakacağız?" Aynı cevabı çıkarır ama kibarca.
3. Şirket demolarına katıl. CEO'nun sunumu seni ilgilendirmiyor gibi gelebilir. Çok yanlış. Şirket stratejisini duyduğunda bir hafta önce verdiğin bir refactor kararının neden yanlış olabileceğini anlarsın.

Sonuç

Kod yazmak, yazılımcı işinin en kolay kısmı. AI çağında artık daha da kolay. Fark yaratan yer, kodun varolma nedenini anlamak. Bu muhabbet çoğu junior için garip gelir ama 3-5 yıl içinde seni kalabalıktan ayırıyor.

Senior developer'lar keskin zekâlı oldukları için değil, iki dili birden konuştukları için bu ünvana sahip: kod ve iş. İkisini aynı anda konuşabilen her zaman değerlidir.