NASIL BAŞARILI PROGRAMCI OLUNUR?
İki kişi aynı bootcamp'ten mezun olur. Beş yıl sonra biri ekip yönetiyor, mimari kararlar veriyor; diğeri hâlâ "junior'lıktan nasıl çıkarım" diye soruyor. Aradaki fark zekâ değil — ikisi de aynı sınavlardan geçti. Fark, ilk günden itibaren kurulan alışkanlıklarda. Başarılı programcılık bir yetenek piyangosu değil, tekrar edilebilir davranışların toplamıdır ve bu davranışların ne olduğu sektörde aşağı yukarı netleşmiş durumda.
Türkiye'de yazılımcı talebi bankacılıktan e-ticarete, savunma sanayinden oyun stüdyolarına kadar geniş bir yelpazeye yayılıyor; ama işe alım yapan teknik liderlerin şikâyeti hep aynı: "Sözdizimini bilen çok, problem çözen az." Aşağıdaki başlıklar tam o ayrımın üzerine gidiyor.
Her Gün Kod Yaz, Ama Doğru Şekilde
En sık verilen tavsiye aynı zamanda en çok yanlış anlaşılanı. "Her gün kod yaz" demek, her gün sekiz saat klavye başında oturmak demek değil. Günde 30 dakikalık odaklı pratik — küçük bir algoritma sorusu, kendi projende tek bir fonksiyon, dünkü kodun refactor'ü — bir yılda 180 saatlik bilinçli antrenman eder.
Kritik kelime "bilinçli". Aynı CRUD ekranını onuncu kez yazmak pratik değil, tekrardır. Pratik, konfor alanının hemen dışındaki işe denir:
- Hiç kullanmadığın bir veri yapısıyla problem çözmek
- Hep IDE'nin ürettiği kodu bu kez elle yazmak
- Çalışan kodunu bir de farklı paradigmayla (örneğin döngü yerine map/filter ile) yeniden kurmak
- Bir kütüphanenin dokümantasyonuna değil kaynak koduna bakmak
Kod yazmadığın günlerde bile kod okumak mümkün. Açık kaynak projelerin pull request'leri, ustaların gerçek dünya problemlerini nasıl ele aldığını gösteren bedava ders niteliğindedir.
Neden'i Anlamadan Kopyalama
Stack Overflow'dan ya da yapay zekâ asistanından gelen kodu yapıştırıp "çalıştı, geçtim" demek, junior seviyesine çakılı kalmanın en garantili yolu. Kıdemli geliştiriciyi ayıran şey, kodun neden çalıştığını bilmesidir — çünkü kod bir gün çalışmadığında o "neden" bilgisi tek pusula olur.
Pratik bir test: yazdığın herhangi bir satır için "bunu silsem ne bozulur?" sorusuna cevap veremiyorsan, o satırı henüz anlamamışsın demektir. Deneyimli mühendisler zamanlarının büyük kısmını IDE'de değil kafalarında geçirir; tek satır yazmadan önce yazılımın nasıl işleyeceğini zihinlerinde kurarlar. Bu planlama alışkanlığı, "kod yaz-sil-tekrar yaz" döngüsünden çok daha hızlıdır.
Code Review'u Angarya Değil Okul Olarak Gör
Code review iki yönlü bir öğrenme mekanizmasıdır: inceleyen kişi kod sezgisini geliştirir, kodu yazılan kişi hatalarından öğrenir. Türkiye'deki yazılım ekiplerinde review kültürü şirketten şirkete uçurum gösterir — kimi yerde her satır iki onaydan geçer, kimi yerde "merge'le geç" düzeni işler. Hangi ortamda olursan ol, kendi standardını yüksek tut:
- Review'a gönderdiğin PR'ı önce kendin oku — ilk yorumları kendin yakala
- Gelen her yorumu savunma refleksiyle değil "ne öğrenebilirim" sorusuyla karşıla
- Başkalarının PR'larını gönüllü incele — özellikle senden kıdemlilerin kodunu
- Yorum yazarken "bu yanlış" değil "şu durumda ne olur?" dilini kullan
Bir de tersi var: hiç review almadan yıllarca tek başına kod yazmak. Freelance veya tek kişilik ekiplerde çalışıyorsan açık kaynak projelere katkı, eksik kalan bu geri bildirim döngüsünü kapatmanın en etkili yoludur — uzaktan ekip deneyimi ve yapıcı eleştiri ikisi birden gelir.
Soru Sormak Zayıflık Değil, Yöntemdir
Yazılım o kadar geniş bir alan ki kimse her şeyi bilmiyor — kıdemlisi de bilmiyor. Anlamadığın şeyi sormaktan kaçınmak, aynı belirsizlikle boğuşan ekip arkadaşlarının da işini uzatır; çünkü sen sormuyorsan büyük ihtimalle başkası da sormuyordur.
İyi soru sormanın da tekniği var. "Çalışmıyor, neden?" bir soru değildir. Şu üçlü kalıp hem cevabı hızlandırır hem soran kişinin ciddiyetini gösterir: ne yapmaya çalıştım → ne bekledim → ne oldu. Çoğu zaman soruyu bu kalıba dökerken cevabı kendin bulursun — sektörde buna lastik ördek yöntemi denir: problemi masadaki cansız bir nesneye yüksek sesle anlatırken çözüm kendiliğinden görünür.
Teknolojiye Değil Probleme Bağlan
"Ben React'çiyim", "ben .NET'çiyim" cümlesi kariyerin erken döneminde kimlik verir, ileri döneminde hapseder. Diller ve framework'ler araçtır; beş yıl önce parlayan teknolojinin bugün bakım modunda olduğu örneklerle dolu bir sektör bu. Kalıcı olan beceriler araçtan bağımsız olanlardır: veri yapıları, ağ temelleri, veritabanı mantığı, test disiplini, sürüm kontrolü.
Bu, yeni teknolojiye kapalı olmak anlamına gelmez — tam tersi. Araç bağımsız temeli sağlam olan kişi yeni framework'ü haftalar içinde söker; temeli framework'ün kendisi olan kişi her geçişte sıfırlanır. Temel katmanı sağlamlaştırmak isteyenler temel programlama eğitimi gibi araç-bağımsız bir müfredatla başlayarak hangi dile geçerse geçsin taşınabilir bir zemin kurabilir.
İşin Kendisini Anla, Sadece Kodu Değil
Başarılı geliştiriciler sadece iyi programcı değil, çalıştıkları işi anlayan insanlardır. Bir e-ticaret platformunda sepet terk oranının ne olduğunu bilen geliştirici ile bilmeyen geliştirici aynı feature'ı farklı yazar. Biri "istenen ekranı" kodlar; diğeri "çözülmek istenen problemi" kodlar ve çoğu zaman daha basit bir çözüm önerir.
Türkiye'deki kurumsal yazılım projelerinde bu fark özellikle görünür: bankacılık mevzuatını bilen backend geliştirici, muhasebe akışını anlayan ERP programcısı, e-fatura sürecine hâkim entegrasyon uzmanı — hepsi salt kod becerisinin üstüne iş bilgisi koydukları için aranan profil hâline gelir.
Geride Bıraktığın Kodu Bulduğundan İyi Bırak
İzcilerin kamp kuralının yazılım versiyonu: dokunduğun her dosyayı, bulduğundan biraz daha iyi bırak. Kötü isimlendirilmiş bir değişkene rastladın — düzelt. Tekrarlanan üç satır gördün — fonksiyona çek. Bu mikro iyileştirmeler tek tek önemsiz görünür; bir yılda kod tabanının kaderini değiştirir.
Bunun tersi de bir alışkanlık: "çalışıyorsa dokunma" refleksiyle spagettiye spagetti eklemek. Mevcut karmaşaya uyum sağlamak kısa vadede hızlıdır; ama o kod tabanında çalışan herkesin hızını kalıcı olarak düşürür. Cesaret ile dikkatsizlik arasındaki çizgiyi test güvencesi çizer — testi olan kodu iyileştirmek cesarettir, testi olmayanı ellemek kumardır.
Tükenmeden Sürdür
Sektörün konuşulmayan gerçeği: programcılığın en büyük düşmanı teknik yetersizlik değil, tükenmişliktir. Sürekli öğrenme baskısı, bitmeyen deadline'lar ve "herkes benden iyi" hissi (impostor sendromu) birleşince en hevesli geliştirici bile birkaç yılda sönebilir.
Buna karşı en etkili sigorta, programlama keyfini koruyacak alan bırakmaktır. Haftada bir saat, hiçbir iş hedefi olmayan kurcalama zamanı — küçük bir oyun, ev otomasyonu scripti, saçma ama eğlenceli bir bot. İşe yaramayan kod yazmak, kod yazmayı sevmeye devam etmenin en işe yarar yoludur. Zor dönemlerde mola vermek de plan dahilinde olmalı; dinlenmiş zihin, dün imkânsız görünen problemi bugün kahvaltıda çözer.
Başarılı programcı olmak tek bir büyük karardan değil, her gün tekrarlanan küçük seçimlerden oluşur: bugün 30 dakika pratik yaptın mı, anlamadığın şeyi sordun mu, dokunduğun kodu iyileştirdin mi? Bu soruların cevabı art arda yeterince "evet" olduğunda, beş yıl sonra ekip yöneten kişi sen oluyorsun.
