Neden En İyi Developer'lar En Basit Soruları Sorar?
Kendine güvenen bir developer olmanın 8 temel disiplini.
Yazılım dünyasında kendine güveni genellikle "her şeyi çözebilecek bir zeka" veya "bitmek bilmeyen bir teknik bilgi" ile karıştırıyoruz. Çoğu zaman bir developer’ın kendine güvenmesi için son framework’ü ezberlemesi, en karmaşık algoritmaları tek seferde yazması veya kusursuz bir mimari kurması gerektiğine inanıyoruz. Ancak sahada işler böyle yürümüyor. Teknik kapasitesi çok yüksek olduğu halde ilk ciddi krizde dağılan veya “imposter sendromu” ile boğuşan yüzlerce yetenekli insan var.
Bunun temel sebebi, özgüveni teknik bir “bilgi birikimi” sanmamız. Oysa gerçek mesleki özgüven, her şeyi bilmekten değil; sürtünme noktalarını yönetebilme becerisinden ve belirsizliğin ortasında sergilenecek duruştan beslenir.
Gözlemlediğim bir şey var: Gerçekten kendine güvenen developer’lar, en gürültülü teknik tartışmalarda en “basit” soruları soran, karmaşıklığın arkasına saklanmaya ihtiyaç duymayan ve zayıf noktalarını masaya koymaktan çekinmeyen kişilerdir. Onları ayıran şey, kullandıkları kütüphaneler değil; iş yapış biçimlerine yerleştirdikleri imzalardır.
Peki, bu duruşu nasıl inşa ederiz? Sadece kod yazarak değil, kodun etrafındaki kültürü, odağı ve iletişimi de mühendislik disipliniyle ele alarak. İşte “kendine güvenen bir developer” olmanın yolunu açan, teknik ve kültürel birkaç temel pratik.
1. Basitlik Takıntısı: Karmaşıklık Bir Zeka Göstergesi Değildir
Sektörde tuhaf bir sessiz mutabakat var: Bir çözüm ne kadar katmanlıysa, ne kadar çok güncel terim (mikroservisler, event-driven yapılar, en yeni framework’ler) içeriyorsa, onu yazan kişi o kadar “yetkin” kabul ediliyor. Oysa sahada durum çoğu zaman tam tersi. Bir sistemin içine çok fazla teknoloji boca edilmiş olması, genellikle o sistemi kuran kişinin çözümden emin olmamasının bir sonucudur.
Kendine güvenen bir developer’ın en belirgin imzası, yazmadığı kodda saklıdır.
Junior seviyesindeyken her problemi en komplike tasarım kalıplarıyla çözmeye çalışabiliyoruz; çünkü “doğru olanın” bu olduğuna ikna edilmişizdir. Ancak projeler büyüdükçe ve o sofistike kodların içinde kaybolup rework (yeniden işleme) döngüsüne girdiğimizde asıl gerçeği anlıyoruz: Basitlik, hala yazılım dünyasının en çok göz ardı edilen ama en kritik erdemidir.
Mesele en yeni teknolojiyi kullanmak değil, minimum dış bağımlılıkla maksimum problemi çözebilmek. İyi bir developer, 100 satırlık karmaşık bir mantığı silip yerine 10 satırlık, herkesin okuyunca “Bunu ben de yazardım” dediği o sade kodu bıraktığında asıl profesyonel duruşunu sergiler. Çünkü basit yazmak, hatayı saklayacak bir karmaşıklık perdesi bırakmadığı için aslında bir cesaret işidir.
Günün sonunda, kodun okunabilirliğini bir tercih değil, bir mühendislik standardı olarak görmek gerekiyor. Karmaşıklık bir zeka göstergesi değil, yönetilmesi gereken bir teknik borçtur.
2. Yazmak Bir Düşünme Biçimidir: İyi Bir Dokümantasyoncu Ol
Developer’lar olarak kod dışındaki metinleri yazmaktan pek haz etmeyiz. Dokümantasyonu “asıl işten” sonra gelen, yapılsa iyi olur ama yapılmasa da olur bir angarya gibi görme eğilimimiz var. Ancak teknik kariyer yolu kıdemlendikçe, klavyeden çıkan kod satırı azalırken üretilen metin miktarının arttığını görürüz.
Yazmak, zihindeki bulanıklığı temizlemenin en kısa yolu. Bir projeye başlamadan önce o iş üzerine teknik tasarım dokümanı veya analiz metni karalamak, henüz tek satır kod yazmadan nerelerde “rework” (yeniden işleme) yapacağımızı gösterir. Kod yazarken zihnimiz dağılsa da bir şekilde ilerleyebiliriz ama bir şeyi yazarak anlatırken odaklanmak zorundayız. Yazı yazmak, düşünceyi derinleştirir ve yapılandırır.
Bu disiplini günlük iletişimde de bir imza gibi kullanmak mümkün:
PR Açıklamaları ve Commit Mesajları: Yapılan değişikliğin sadece “ne” olduğunu değil, “neden” yapıldığını netleştirmek gerekir.
Code Review Süreci: İnceleme yaparken ya da yorumlara cevap verirken üşenmeden açıklama yapmak, bir zaman kaybı değil. Aksine, o konudaki hakimiyetin en doğal kanıtı.
Ekip içindeki yazılı izin netleşmesi, insanların ismini görmese bile o dokümanın ya da PR’ın sana ait olduğunu anlamasını sağlar. Bu, teknik bir beceriden ziyade bir duruş, bir karakter gibidir.
3. Product’a Bir Ürün Sahibi Gibi Kafa Yor
Geliştirici olarak bazen kendimizi sadece kod yazan birer “uygulayıcı” olarak konumlandırma hatasına düşüyoruz. Oysa kendine güvenen bir developer, ekranına düşen task’ın sadece nasıl kodlanacağıyla değil, neden var olduğuyla da ilgilenir.
Ürünü sadece geliştiren değil, onun sahibiymişsin gibi hissetmek bakış açısını değiştirir. Bu, her şeyi en ince ayrıntısına kadar dinlemeyi ve gerekirse “anlamadım” diyerek en temel soruları sorma cesaretini gerektirir. Sektördeki en büyük sürtünme noktalarından biri, developer’ın tam anlamadığı bir özelliği “elbet kodlarken netleşir” diyerek kabul etmesidir.
Gerçek özgüven, kimsenin düşünmediği o ters köşe soruyu sorabilmekte saklıdır. Bu bir beyin jimnastiği gibi; ürüne ne kadar uçtan uca hakim olursan, sistemin açıklarını o kadar erken fark edersin. Sadece developer şapkasını değil, ürün sahibi (product owner) şapkasını da takmak, seni bir “kod yazıcısı” olmaktan çıkarıp çözüm ortağına dönüştürür.
4. Unit Test Yaz: Kendi Kodunla Kavga Et
Unit test yazmayı genellikle başkaları (yöneticiler veya QA ekibi) için yapılan bir zorunluluk gibi görüyoruz. Oysa test yazmak, en başta geliştiricinin kendi koduna duyduğu o “sahte güveni” sarsmak için vardır. Postman’den bir istek atıp sonucun doğru döndüğünü görmek, kodun çalıştığını kanıtlar ama sağlam olduğunu kanıtlamaz.
Gerçek bir test süreci, “Bu kodu nasıl yazarım?” sorusundan “Bu kodu nasıl bozarım?” sorusuna geçtiğiniz an başlar. Kendini bir QA mühendisi yerine koyup kendi yazdığın mantığı zorlamaya başladığında, aslında ne kadar çok açık kapı bıraktığını fark edersin.
Testsiz kod gönderdiğinde içinde uyanan o hafif huzursuzluk, aslında mesleki bir pusuladır. Bir kez test yazarken bulduğun o kritik hataları gördükten sonra, iç huzuruyla “merge” butonuna basmak zorlaşır. Unit test, bir başkasına rapor vermek için değil; akşam bilgisayarı kapattığında “yazdığım şeyin patlamayacağından eminim” diyebilmek içindir.
5. İyi Bir Takvim Kullanıcısı Ol
Günümüzde vaktimizi çalan o kadar çok şey var ki, her şeyi zihinde tutmaya çalışmanın maliyeti sandığımızdan daha büyük. Ajanda kullanmayı sadece toplantı takibi olarak görmemek gerekiyor; bu aslında bir odak yönetimi meselesi.
İş hayatında disiplinli bir takvim kullanıcısı olmak, ekibinle arandaki o sessiz güveni inşa eder. İnsanlar senin takvimine baktığında ne zaman ulaşılabilir olduğunu, ne zaman derin bir odaklanma (deep work) içinde olduğunu bilmeli. Takvimine uymayan, toplantılara mazeretsiz katılmayan veya sürekli “müsaitlik” sorgusu yapılan biri olmak, teknik yeteneğinden bağımsız olarak profesyonel imajını zedeler.
Sadece takvimi doldurmak da yetmez, o takvimin çıktılarını yönetmek gerekir. Eğer bir toplantının sahibi sensen, sonrasında paylaştığın o kısa ve net aksiyon maddeleri senin imzan haline gelir. Kimsenin okumayacağı blok metinler yerine, “kim, neyi, ne zamana kadar yapacak” netliğinde notlar paylaşmak, senin zamanın kadar başkalarının zamanına da değer verdiğini gösterir. Kendi zamanına saygı duymayan birinin, başkalarından saygı beklemesi zordur.
6. Odağını Cüzdanını Korur Gibi Koru
Odağını koruyamadığında, sadece vaktini değil, kendine olan güvenini de kaybedersin. 1 birimlik bir işe 3 birim enerji harcayıp gün sonunda hala bitiremediğini görmek, insanda “yetersiz miyim?” hissi uyandırır. Oysa mesele yetersizlik değil, parçalanmış dikkattir.
Zamanını ve odağını senden çalmaya çalışan çok fazla dış etken var. Slack bildirimleri, e-postalar, “bir saniye bakabilir misin” diye başlayan ani bölüntüler... Bunları kontrol altına almadığında, işlerini hiçbir zaman vaktinde ve istediğin kalitede bitiremezsin.
Kendi odak pencerelerini (focus time) yaratmak ve bunu ekibine dürüstçe iletmek bir bencillik değil, işine duyduğun saygıdır. Bildirimleri kapatıp sadece o anki probleme gömülmek, işi hem daha hızlı bitirmeni hem de çıkan sonucun kalitesinden emin olmanı sağlar. Unutma, bu yıl ve her yıl, senden vaktini çalmak isteyenlerin sayısı artacak. Odağını korumak, aslında teknik kapasiteni korumaktır.
7. Okuma Akışında Ol: Zihni Demlemeye Bırakmak
Gelişim dediğimiz şey sadece klavye başında kod yazarak gerçekleşmiyor. Zihninin bir köşesinde her zaman demlenen bir konu, bir makale veya bir kitap olmalı. Maruz kaldığın bilgi, sen uyurken veya yemek yerken arka planda çalışmaya devam eder.
Sürekli teknik dökümanlar veya ağır kitaplar okumak zorunda değilsin; ancak seni zorlayan, “bu nasıl çalışıyor?” dedirten konularla aranda her zaman bir bağ olmalı. Haftalık bültenleri takip etmek veya sevdiğin yazarların bloglarını okumak, dünyayı sadece kendi projenin sınırlarından görmeni engeller.
Günde sadece yarım saatini bu “maruz kalma” haline ayırdığında, birkaç ay içinde olaylara daha geniş bir çerçeveden bakabildiğini fark edeceksin. Bu geniş bakış açısı, toplantılarda veya teknik tartışmalarda yaptığın yorumların niteliğini değiştirir. Zihnin, ona verdiğin kaliteli malzemeyi işleyerek seni daha donanımlı ve kendine güvenen birine dönüştürür.
8. Pair Programming Yap: Zayıflığı Masaya Koymak
Biriyle yan yana oturup kod yazmak, sadece teknik bir pratik değil; aslında bir eşiği atlama biçimidir. Çoğumuz eksikliklerimizi gizleme eğilimindeyizdir. “Her şeyi bilmemek” bir developer için korkutucu bir açık gibi görünür. Oysa kendine güvenen birinin en ayırt edici özelliği, her şeyi bilmediğini kabul edip bunu başkalarının önünde göstermekten çekinmemesidir.
Biriyle birlikte düşünmek, başkasının o soruna nasıl yaklaştığını izlemek ve en önemlisi kendi hatalarınla yüzleşmek öğrenme sürecini inanılmaz hızlandırır. Başlangıçta omuz başınızda birinin olması rahatsız edici gelebilir, ancak bu bariyeri aştığınızda “eksik görünme” korkusunun yerini ortak bir akıl alır.
Bu açıklık seni sadece teknik olarak geliştirmez, ekibin içindeki “yenilmez ama dokunulmaz” kişi imajını yıkarak seni daha sahici ve güvenilir kılar.
Senin İmza Davranışın Ne?
Özgüven, teknik bir zafer anı değil, her gün verilen küçük kararların toplamıdır. Karmaşık bir kod yazmak yerine basiti seçtiğinizde, bilmediğinizi itiraf edip bir soru sorduğunuzda veya vaktinizi korumak için bir bildirim penceresini kapattığınızda bu duruşu biraz daha inşa edersiniz.
Günün sonunda mesele, en mükemmel kodu kimin yazdığı değildir. Asıl mesele; karmaşıklığın, gürültünün ve hız baskısının ortasında kimin kendi standartlarına sadık kalarak, sakince çözüm üretebildiğidir.
Kendine güvenmek işlerin kontrolden çıktığı o anda bile kendi disiplinine ve sistemine güvenerek devam etmektir.
Şimdi sen de kendi imza davranışlarını farket ve geliştir.
Buraya kadar benimle kalıp okuduğun için teşekkürler!
Eğer ilham verici ya da düşündürücü bulduysan, aşağıdaki ❤️ ikonuna tıklayabilir, ilgisini çekeceğini düşündüğün biriyle paylaşabilir ve gelecek sayılardan haberdar olmak için abone olabilirsin.
👋 Bağlantıda kalalım! Beni LinkedIn’de bulabilirsin.
Çünkü basit sorular karmaşığı açığa çıkarır.
Temeli test eder. Gerçek ustalık, karmaşık şeyleri ezberlemek değil; en temel kavramları net ve doğru anlamaktır.
Varsayımları yakalar. “Bu neden böyle?” gibi basit bir soru, yıllardır sorgulanmayan hatalı kabulleri ortaya çıkarır.
İletişimi güçlendirir. En iyi developer’lar, teknik doğruluktan önce aynı problemi konuşup konuşmadığımızı kontrol eder.
Bakım maliyetini düşürür. Basit çözümler, debug etmesi ve geliştirmesi en kolay olanlardır.
Ego değil çözüm odaklıdır. Basit soru sormak cesaret ister; “bilmiyorum” demeyi gerektirir.
Kısacası: Acemi developer karmaşıklığı sever, usta developer sadeliği.
"İyi bir developer, 100 satırlık karmaşık bir mantığı silip yerine 10 satırlık, herkesin okuyunca “Bunu ben de yazardım” dediği o sade kodu bıraktığında asıl profesyonel duruşunu sergiler. " Evet bunu unutmuştuk. Sanırım herkes hünerlerini kod yazarak göstermek, bakın ben bu işi biliyorum demeye çalışıyordu. Neyse o günleri geride bıraktık :)