Kıdemli bir yazılım mühendisi olmanın yalnızca iyi kod yazmaktan ibaret olmadığını zamanla daha net görürsünüz.
Deneyim arttıkça şirketler sizden teknik problemleri çözmenin yanında kimin sürece dahil edilmesi gerektiğini, her kişinin hangi bilgiye ihtiyaç duyduğunu, ne kadar ayrıntı vermeniz gerektiğini ve ne zaman eskalasyon yapılacağını anlamanızı bekler.
Production crash’i, belirsiz gereksinim, geciken teslimat, API hatası veya geliştiriciler arasındaki görüş ayrılığı; birbirinden farklı iletişim stratejileri gerektirir.
Doğru problem, doğru kişiye, doğru ayrıntı seviyesinde ve doğru zamanda ulaşmalıdır.
Temel İletişim Modeli
Bir sorun ortaya çıktığında kıdemli mühendis şu beş soruyu düşünmelidir:
- Gerçek problem tam olarak nedir?
- Bu alanın sahibi kimdir?
- Kimlerin bundan haberdar olması gerekir?
- Her kişinin hangi bilgiye ihtiyacı var?
- Sadece problemi mi iletiyorum, yoksa seçenek ve öneri de getiriyor muyum?
“Bir bug var” demek yerine “Sorunu yeniden ürettim, muhtemel nedeni buldum, kullanıcı etkisini değerlendirdim ve iki çözüm görüyorum. Release riski daha düşük olduğu için ikinci seçeneği öneriyorum” diyebilmek kıdemli iletişimdir.
1. Production Crash Bulduğunuzda
Checkout sırasında kullanıcıların crash yaşadığını düşünelim. Önce teknik araştırmayı yapın: sorunu yeniden üretin, logları ve stack trace’i toplayın, beklenen ve gerçek davranışı ayırın.
Sorumlu geliştiriciyle iletişim
Crash’i yeniden ürettim. Payment callback sonrasında response null olduğunda oluşuyor ve stack trace PaymentCoordinator’ı gösteriyor.
Geliştiricinin ihtiyacı olan bilgi; reproduction adımları, loglar, stack trace, ilgili kod, beklenen ve gerçek davranıştır.
Tech Lead ile iletişim
Tech Lead daha geniş resmi bilmek ister: etki, önem derecesi, teknik risk ve önerilen aksiyon.
Bu sorun checkout akışını etkiliyor ve yüksek etkili görünüyor. Muhtemel kök nedeni buldum; bir sonraki release’ten önce düzeltmeyi öneriyorum.
Product ile iletişim
Product Manager’a Swift sınıfının adını değil, kullanıcı ve ürün etkisini anlatın:
Bu durumla karşılaşan kullanıcılar checkout’u tamamlayamıyor. Bu nedenle yüksek öncelik verilmesini öneriyorum.
QA ile iletişim
QA kesin reproduction adımlarına, test ortamına, beklenen sonuca ve gerçek sonuca ihtiyaç duyar. Aynı teknik problem, farklı kişilere farklı bilgi paketleriyle aktarılır.
2. Gereksinim Belirsizse
“Cancelled payment’leri ele al” bir implementasyon gereksinimi değildir. Kıdemli mühendis önce belirsizliği görünür kılar:
Kullanıcı ödemeyi iptal ettiğinde shopping cart korunmalı mı, yoksa sıfırlanmalı mı?
Bu bir ürün veya iş kuralı sorusudur; Product Manager, Product Owner veya Business Analyst’e yönelmelidir.
“Bunu Coordinator mı yoksa NavigationStack ile mi implement etmeliyiz?” sorusu ise teknik karardır ve başka bir geliştirici, Senior Engineer, Tech Lead veya Staff Engineer ile konuşulmalıdır.
Product ne yapılacağını, Engineering nasıl yapılacağını belirler.
3. Başka Bir Geliştiriciyle Görüş Ayrılığı
Teknik görüş ayrılıkları normaldir. İlk adım çoğu zaman yönetime gitmek değil, diğer mühendisle doğrudan konuşmaktır.
Approach A’nın maintainability açısından riskli olduğunu düşünüyorum. A ve B’yi complexity, test edilebilirlik, coupling ve gelecekteki değişiklikler üzerinden karşılaştıralım mı?
Kararı kişisel tercihten çıkarıp maintainability, complexity, performance, scalability, testability, teslim süresi ve teknik borç gibi ölçütlere taşıyın.
İki seçenek de makulse Tech Lead’e şöyle gidin:
İki makul yaklaşımımız var. Trade-off’ları çıkardık ve ilerlemeden önce görüşünüze ihtiyacımız var.
Bu sağlıklı eskalasyondur; “diğer geliştirici yanılıyor” demek değildir.
4. Deadline’a Yetişmeyecekse
Beklenmeyen bir backend dependency’si keşfettiğinizde “bitiremeyeceğiz” demek yeterli değildir.
İlk tahmin üç gündü; ancak implementasyon sırasında backend API’ye ek bir dependency keşfettik. İki seçeneğimiz var: kapsamı daraltıp Cuma release’ini korumak veya tüm özelliği Pazartesiye taşımak. Kapsamı daraltmayı ve kalan kısmı sonraki iterasyona bırakmayı öneriyorum.
Bu iletişim modeli şudur: Problem → Neden → Seçenekler → Öneri.
İlgili kişilere göre Tech Lead teknik riski, Product kapsamı, Engineering Manager ise kapasite ve teslimat riskini değerlendirir.
5. Backend API Hata Veriyorsa
POST /payments isteği paymentMethod null olduğunda HTTP 500 dönüyorsa ilk konuşma çoğu zaman API’den sorumlu backend mühendisiyle yapılmalıdır.
POST /payments, paymentMethod null olduğunda HTTP 500 dönüyor. Request payload’ı, response’u ve reproduction senaryosunu ekledim.
Backend Engineer request, response, log ve API contract ister. Product Manager’a ise özelliğin bloklandığını ve kullanıcı etkisini anlatmak gerekir.
6. Tasarım Teknik Olarak Zorsa
Bir animasyon eski cihazlarda frame drop yaratıyorsa “SwiftUI performansı kötü” demek faydalı değildir.
Animasyon görsel olarak iyi çalışıyor; fakat eski cihazlarda frame drop oluşturup etkileşimi yavaş hissettiriyor. Aynı deneyimi koruyarak animasyonu sadeleştirebilir miyiz?
Hedef Engineering ve Design’ın birbirine karşı olması değil, kullanıcı problemini birlikte çözmesidir. Kıdemli mühendis teknik kısıtları kullanıcı deneyimi diline çevirmeyi öğrenir.
7. Feature Yayınlandı ama Kullanılmıyorsa
Bir feature teknik olarak başarılı şekilde yayınlanabilir; ancak neredeyse hiç kullanılmayabilir. Bu durumda Product Manager, Data Analyst ve UX Researcher ile konuşmak gerekir.
Feature adoption beklenenden düşük. Kullanıcıların funnel’da nerede düştüğünü birlikte inceleyebilir miyiz?
Data Analyst activation, conversion, retention ve funnel verilerini inceleyebilir. Engineering ise analytics event’lerinin doğru çalıştığını doğrulamalıdır.
Teknik olarak kusursuz teslimat, her zaman başarılı bir ürün sonucu anlamına gelmez.
8. Güvenlik Açığı Bulduğunuzda
Bir authentication token’ın belirli koşullarda açığa çıkabildiğini fark ederseniz bunu normal backlog maddesi gibi bekletmeyin. Etkiye göre Security Engineer, Tech Lead, Engineering Manager, SRE ve ilgili sistem sahipleri hızla dahil edilmelidir.
Mesajınız etkilenen sistemi, açığın nasıl tetiklendiğini, istismar edilip edilemeyeceğini, müşteri verisinin etkilenip etkilenmediğini, etkilenen sürümleri ve olası mitigation’ı içermelidir.
Hassas güvenlik konuları geniş bir Slack kanalında paylaşılmamalı; doğru iletişim kanalı seçilmelidir.
9. Junior Geliştiricinin Kodu Zayıfsa
Bir merge request’te aynı mantığın üç yerde tekrarlandığını gördüğünüzde “Bu geliştirici kötü kod yazıyor” demek yerine code review’u mentorluk fırsatına çevirin.
Bu implementasyon çalışıyor; ancak aynı mantık üç yerde tekrar edilmiş. Bunu shared component’e ayırmayı öneriyorum. Aksi halde gelecekteki değişikliklerde üç ayrı yolu güncellemek gerekecek.
İyi geri bildirim yalnızca neyin değişeceğini değil, neden değişmesi gerektiğini de açıklar. Amaç diğer mühendisi size bağımlı kılmak değil, benzer problemleri gelecekte bağımsız çözebilmesini sağlamaktır.
İletişim Araçlarını Doğru Seçmek
Slack veya Microsoft Teams
Kısa sorular, async koordinasyon ve hafif teknik tartışmalar için uygundur. Yetmiş mesajlık bir mimari tartışma oluştuğunda kısa bir görüşme yapıp sonucu dokümante etmek daha verimli olabilir.
Zoom veya Teams görüşmeleri
Konu karmaşıksa, birden fazla kişinin hizalanması gerekiyorsa veya yanlış anlaşılma artıyorsa kullanılır. Görüşmenin sonunda karar ve aksiyonlar yazılı hale getirilmelidir.
Jira
İyi bir ticket context, problem, reproduction adımları, beklenen ve gerçek davranış, priority, dependency ve acceptance criteria içermelidir.
GitHub veya GitLab
Pull request’ler yalnızca kod onaylama yeri değildir; correctness, architecture, maintainability, test coverage, edge case, security ve performance hakkında mühendislik iletişimidir.
Dokümantasyon ve ADR
Chat kaybolur; önemli mimari kararlar kaybolmamalıdır. Architecture decision, API contract, operational procedure ve incident learning gibi bilgiler uzun vadeli dokümantasyonda yaşamalıdır.
Eskalasyonu Anlamak
Kıdemli mühendislik becerilerinden biri ne zaman eskalasyon yapmamak gerektiğini bilmektir.
Küçük bir implementasyon detayında iki geliştirici önce kendi arasında çözüm aramalıdır. Anlamlı bir mimari karar çözülemiyorsa Tech Lead dahil edilir. Sorun teslimat riski oluşturuyorsa Product ve Engineering Management bilgilendirilir. Production down ise SRE ve ilgili sistem sahipleri hemen devreye girer.
Sağlıklı eskalasyon, problemi başkasına atmak değil; karar, yetki, bilgi veya koordinasyon ihtiyacının mevcut kapsamınızı aştığını görünür kılmaktır.
Farklı Roller Farklı Bilgi İster
- Developer: teknik ayrıntılar, kod, API, implementasyon ve test.
- Tech Lead: teknik karar, trade-off ve risk.
- Product Manager: kullanıcı etkisi, öncelik, kapsam ve ürün davranışı.
- Engineering Manager: teslimat, kapasite, dependency ve ekip riski.
- QA: reproduction, beklenen davranış ve regression kapsamı.
- DevOps / SRE: deployment, environment, observability ve availability.
- Designer: interaction, usability ve accessibility.
- Data: event, funnel, adoption, retention ve conversion.
En yaygın iletişim hatalarından biri herkese aynı bilgi paketini vermektir.
Kıdemli Mühendis Zihniyeti
- Problem ne tür bir problem? Teknik, ürün, iş, süreç, altyapı veya insan problemi mi?
- Problemin sahibi kim? Otomatik olarak yöneticinize gitmeyin; probleme en yakın kişiyi bulun.
- Kim bilmeli? Problemi çözen kişi ile problemden etkilenen kişi farklı olabilir.
- Bu kişinin hangi bilgiye ihtiyacı var? Product Manager stack trace istemez; Backend Engineer isteyebilir.
- Bir öneri getirebilir miyim? “Bir problemimiz var” yerine “Araştırdım, seçenekler bunlar ve şunu öneriyorum” seviyesine ulaşmaya çalışın.
Kıdemli İletişim Daha Çok Konuşmak Değildir
Kıdemli mühendis toplantılarda en çok konuşan kişi olmak zorunda değildir. Gerçek kıdem; problemi doğru tanımlamak, doğru kişiyi bulmak, doğru bağlamı vermek, teknik ve iş kararlarını ayırmak, riski erken iletişim kurmak, anlaşmazlıkları profesyonelce çözmek, doğru zamanda eskalasyon yapmak, kararları dokümante etmek ve yalnızca problem değil çözüm de getirmektir.
Soru artık yalnızca “Bu problemi çözebilir miyim?” değildir.
Ekibin problemi anlamasına, doğru kararı vermesine ve çözüme ilerlemesine yardımcı olabilir miyim?
Kıdemli yazılım mühendisliğinin önemli bir bölümü budur.