Bir startup'taki ilk ayınız iz bırakır. Yavaş bir alışma süreci yoktur; IT departmanının bir laptop hazırlamasını beklerken oryantasyon videoları izlediğiniz bir hafta yoktur. İlk günden itibaren, gerçek insanların gerçekten kullanacağı şeyleri inşa etmeniz, bozmanız ve düzeltmeniz beklenir. İş arayanların başvurularını düzenlemelerine yardımcı olan araçlar geliştiren Treevah adlı şirkete katıldıktan sonra bunu çabucak öğrendim. Erken aşama bir ortamda geçen otuz gün, bana yazılım geliştirme hakkında herhangi bir sınıfta veya yarışmada öğrenemeyeceğim kadar çok şey öğretti.
Ritim Amansızdır
Treevah'ta işler, sizin alışmanızı beklemez. Ekip, ürünü alpha aşamasından beta aşamasına ve nihayetinde canlı ortama (production) taşımak için çabalıyor; bu da her görevin bir ağırlığı olduğu anlamına geliyor. Geçici işler veya bir profesörün gelen kutusunda bekletilecek ödevler için yer yok. Bir özelliği yayına aldığınızda, bu özellik doğrudan bir sonraki rollerini ararken son teslim tarihlerini, mülakatları ve takip süreçlerini takip etmeye çalışan kullanıcılara gider.
Tempo yorucu. Her gün çok hızlı hareket ediyorsunuz ve iş yükü beklediğinizden daha çabuk birikiyor. Teslim tarihleri soyut kavramlar değildir; şirketin daha fazla iş arayan kişiye hizmet verebilmesini veya mevcut deneyimdeki eksiklikleri giderebilmesini belirleyen kilometre taşlarına bağlıdır. Bu ağırlık sizi yıpratır. Ancak aynı zamanda büyük organizasyonlarda bulması zor bir netlik de yaratır. Bir görevi bitirdiğimde, inşa ettiğim şey ile artık iş arama sürecini yönetmekte daha az zorlanan bir kişi arasında düz bir çizgi çekebiliyorum. Bu sahiplenme duygusu nadirdir ve yorgunluğun buna değdiğini hissettirir.
Canlı Ortamda Beceriler Daha Hızlı Katlanır
Bu yazdan önce enerjimin çoğu topluluk önünde konuşma ve hackathonlara gidiyordu. Her ikisi de bana baskı altında hızlı düşünmeyi ve fikirleri sunmayı öğretti. Özellikle hackathonlar, birkaç saat içinde çalışan demoları alelacele bir araya getirme konusunda sizi eğitir. Ancak jürileri etkileyen bir hafta sonu projesi ile yüzlerce gerçek kullanıcıyla temas kurduğunda ayakta kalması gereken üretim kodu arasında fark vardır.
Treevah'ta bir ay boyunca web geliştirmeye odaklanmak bu farkı kapattı. Okulda projeler koruyucu sınırlar (guardrails) ile gelir. Kapsam sabittir, gereksinimler hazır olarak sunulur ve eğer veritabanı şemanız çökerse, bunu bir sunum slaytıyla açıklayıp geçebilirsiniz. Bir startup içinde ise şemanız sağlam durmak zorundadır çünkü gerçek iş arayanlar içine gerçek başvuru verilerini kaydediyor. Geri bildirim döngüsü anlık ve acımasızdır. Bir sayfa yavaş yüklendiğinde veya bir form kaydedilemediğinde kimse notunuzu umursamaz; onlar sadece bir fırsatı kaçırıp kaçırmadıklarını önemserler.
Bu baskı gelişimi zorunlu kılar. Daha temiz kod yazmayı bir değerlendirme kriteri istediği için değil, gece yarısı o kodun hata ayıklamasını (debugging) yapacak kişi siz olacağınız için öğrenirsiniz. Kod incelemesi (code review) sırasında daha keskin sorular sormayı öğrenirsiniz çünkü hatalı bir sürümü (build) yayına almak, gerçek kullanıcıların bir duvara çarpması demektir. Buradaki fırsatlar okul projelerinden çok daha sert çarpar. Hataların maliyeti daha yüksektir, bu yüzden dersler daha kalıcı olur.
Hataların İnsana Haddini Bildiren Gerçekliği
Eğer yıkmak istediğim bir mit varsa, o da her yazılım hatasının dramatik bir mantık hatası olduğu düşüncesidir. Bazıları elbette öyledir. Ancak Treevah'ta karşılaştığım hataların çoğu çıldırtacak kadar küçüktü. Göz önünde saklanıyorlardı ve hayatımdan saatler çalıyorlardı.
İki kalıp sürekli karşımıza çıkıyordu. Birincisi yinelenen CSS kurallarıydı. Birden fazla geliştirici birkaç sprint boyunca aynı bileşene dokunduğunda, stil dosyaları şişer. Bir kişi bir margin yardımcı sınıfı (utility class) eklerken, bir diğeri bileşen dosyasında bir değeri doğrudan kodun içine yazar (hardcode). Bunların hiçbiri tek başına yanlış değildir. Ancak birlikte, bir butonun Chrome'da düzgün, Safari'de ise bozuk görünmesine neden olan düzen kaymalarına (layout shifts) veya specificity (özgünlük) savaşlarına yol açarlar. Bunu takip etmek, zarif bir algoritmik mantık okumak yerine, tarayıcı geliştirici araçlarını açıp hesaplanmış stilleri (computed styles) satır satır incelemek anlamına gelir.
İkincisi ise öğeleri kendi üst div'lerinin dışında tanımlamaktı. Bir modal tetikleyicisi veya bir açılır menü (dropdown), DOM'daki yanlış bir düğüme (node) eklenebilir. Ekran neredeyse doğru görünür, bu yüzden yapının sağlam olduğunu varsayarsınız. Sonra bir z-index çakışması ortaya çıkar veya bir tıklama olayı (click event) yanlış işleyiciye (handler) yayılır ve aniden bir kullanıcı, başvuru formunu kapatan bir açılır pencereyi kapatamaz hale gelir. Bunlar bilgisayar bilimi bulmacaları değildir. Hızlı hareket ederken biriken, mekansal ve yapısal hatalardır.
Bu hataların bazılarını bulmak haftalarımı aldı. Koda bakıp durur, mantığın sağlam olduğuna kendimi ikna eder ve hiçbir yere varmayan çıkmaz sokaklarda dolanıp dururdum. Yaşanan hayal kırıklığı çok gerçek. Çok bariz bir şeyi gözden kaçırıyormuşsunuz gibi hissedersiniz ve aslında kaçırıyorsunuzdur. Fakat sonunda yinelenen bir kuralı veya yanlış yere yerleştirilmiş bir kapatma etiketini fark etmenin verdiği tatmin şaşırtıcı derecede