2014'teki kendime: ilk yıllara dair tavsiyeler

Bu ay bu günlüğü tutmaya başladığımın dokuzuncu yılı. 2014’te ilk Composer yazısını yazdığımda ne öğrendiğimi kayıt altına almak istemiştim; ne nereye gideceğimi zaten bilmiyordum.

O yıla baksam, birkaç şeyi daha iyi yapabilirdim. Bunu nostalji ya da özeleştiri olarak yazmıyorum; aynı yerde olan birine somut bir şey aktarabilmek umuduyla yazıyorum.

Araç kovalamanın getiri-götürüsü

2014-2016 arası her birkaç ayda yeni bir şey çıkıyor ve “bunu öğrenmezsem geri kalacağım” duygusu içimde birikirdi. Gulp çıktı, Grunt’u bıraktım. Webpack çıktı, Gulp’u bıraktım. Her öğrenilen şey bir öncekinin üzerine kurulmuyor; sil baştan öğrenme döngüsü.

Şimdi geriye bakınca şunu görüyorum: o dönemde öğrendiğim araçların çoğu artık yok. Ama o araçları öğrenirken kazandığım şey — modül sistemi nedir, bağımlılık neden önemlidir, derleme adımları neden gerekir — hâlâ orada.

Aracı öğrenmek kaçınılmaz; ama aracın arkasındaki kavramı anlamadan öğrenirseniz, araç eskidiğinde elinizde bir şey kalmıyor. Siz 2014’teyseniz ve Gulp öğreniyorsanız, Gulp’u değil “derleme hattı nedir” sorusunu anlayın. Araç gider, soru kalır.

Temeller hiç eskimedi

Aynı dönemde HTTP’yi gerçekten anlamak için ciddi vakit harcadım. İstek-yanıt döngüsü, durum kodları, başlıklar, oturum yönetimi. Bu sıkıcı geliyordu; “zaten Ajax yazıyorum, HTTP bilmeme gerek var mı?” diye düşünürdüm.

Sonraki dokuz yılda bir kez bile HTTP’nin eskidiğini görmedim. API tasarlıyorsunuz, auth akışı kuruyorsunuz, WebSocket entegre ediyorsunuz — bunların hepsinin altında aynı temel var. Temel kavramlara yapılan yatırım bileşik faiz gibi çalışıyor; öğrenmeyi bir kez bitiriyorsunuz ama faizi yıllarca tahsil ediyorsunuz.

Eğer o yılları tekrar yaşasaydım, framework videosuna harcadığım sürenin bir kısmını HTTP spesifikasyonunu, SQL’i ve ağ temellerini anlamaya ayırırdım.

”Mükemmel kod” takıntısının maliyeti

Bir dönem, bir özelliği teslim etmeden önce kodun “temiz” olmasına takılırdım. SOLID’i yeni öğrenmiştim; her sınıfın tek bir sorumluluğu olmalıydı, her metod kısa olmalıydı. Bu disiplin değil miydi?

Kısmen öyleydi. Ama daha büyük sorun şuydu: çalışmayan bir yazılım, mükemmel bir mimariyle yazılmış olsa bile değersizdir. Teslim etmek, düzeltmek ve tekrar etmek — bu döngü çalışan kodu üretir. Mükemmel kodu beklemek çoğu zaman hiçbir kodu üretmemekle eşdeğer.

“Temiz kod” önemli ama sıralama da önemli. Önce çalışsın, sonra temizleyin. Bu sırayı tersine çevirmek erken kariyerde çok vakit kaybettiriyor.

Uzmanlaşmak mı, genelleşmek mi korkusu

“PHP’ye odaklanırsam JavaScript’te geri kalırım. JavaScript’e geçersem PHP biter.” Bu düşünce o dönemde oldukça gerçek hissettiriyordu.

Geriye bakınca şunu görüyorum: her ikisini de öğrendim ve birbirlerini dışlamak bir yana, birbirlerini güçlendirdiler. PHP’de öğrendiğim nesne yönelimli programlama (OOP) kavramları JavaScript’te işe yaradı. JavaScript’te anladığım asenkron programlama modeli PHP’nin olaylarına bakışımı değiştirdi.

İki alandan birini seçmek zorunda değilsiniz; ama ikisini birden yüzeysel öğrenmek de bir şey katmaz. Birinde derinleşin, diğerini takip edin. Zamanla derinlik genişliği kendi kendine getirir.

Hatayı görünür kılmak

Bu belki en geç öğrendiğim şey. Bir şeyi bilmediğimi söylemekten ya da bir yerde takıldığımı belirtmekten çekinirdim. “Araştırırım, hallederim” deyip saatlerce uğraşırdım; sonunda çözmek bir zafer gibi gelirdi.

Ama o saatler genellikle yanlış yönde harcandı. Birinden “şu konuda takıldım, birlikte bakabilir misiniz?” demek, başkası için de öğrenme fırsatı yaratıyor. Sorunu görünür kılmak zayıflık değil; tersine, nasıl ilerleneceğini bilen birinin davranışı.

Hata yapmaktan korkmayın. Ama hatayı gizlemekten korkunuz.

---

Bu mektubu yazarken fark ettiğim bir şey var: anlattıklarımın hiçbiri “şu aracı öğrenin” ya da “şu dili seçin” değil. Çünkü o kararlar değişiyor, konjonktüre göre farklı oluyor. Değişmeyen şey şu: nasıl öğrendiğiniz, hataya nasıl baktığınız ve temellere ne kadar yatırım yaptığınız. Bunlar zaman geçtikçe daha da önem kazanıyor.