Kendi Aracını Yapmak: Üretkenlik Maskesiyle İşten Kaçma Sanatı

Güvenli Sığınak: Kod Yazarak Müşteriden Kaçmanın Konforu

Yazarlar bunu çok iyi bilir. Fransız yazar Victor Hugo, 1830 sonbaharında Notre Dame’ın Kamburu kitabını yazmaya başladığında büyük bir tıkanma yaşadı. Yayıncısı Albert Gosselin ile yaptığı anlaşma gereği teslim tarihi hızla yaklaşıyordu. Hugo, masasından kalkıp Paris sokaklarına karışmamak için bütün giysilerini bir dolaba kilitledi. Anahtarı uşağına teslim etti. Üzerine sadece gri renkte büyük bir yün şal alarak kendini odaya kapattı. Davetleri, görüşmeleri ve mektupları ertelemenin yolu, dışarı çıkamayacak durumda kalmaktı. Hugo o kış giysisiz kaldı ama romanı zamanında tamamladı.

Modern yazılımcılar giysilerini dolaba kilitlemiyor. Onlar asıl işten kaçmak için klavyeye sarılıyor ve kendi aracını yapmak için kod yazmaya başlıyor. Kendi aracını yapmak, geliştirici için gri yün şalın yerini alıyor.

Yazılım dünyasında bu duruma sahte üretkenlik diyoruz. Bir script yazmak, bir veri tabanı göç dosyasını düzenlemek veya yeni bir komut satırı aracı geliştirmek somut bir sonuç üretir. Commit kaydı sisteme işlenir, yeşil renkli test bildirimleri ekranda görünür. Bu eylem, geliştiriciye tamamlanmış bir iş hissi verir. Ancak madalyonun diğer tarafı o kadar konforlu değildir. Bir bağımsız geliştirici veya teknik ekip lideri için potansiyel müşterilerle iletişim kurmak, satış yapmak veya pazarlama metni yazmak belirsizlik taşır. Satış görüşmesinin sonucu kontrol edilemez, reddedilme riski yüksektir. İnsan beyni, belirsiz ve korkutucu olan pazarlama faaliyeti yerine kontrolü tamamen elinde olan kod editörünü tercih eder.

Haftalık zaman çizelgelerine bakıldığında bu kaçış netleşir. Bir yazılımcı, asıl yapması gereken pazar araştırmasını ertelemek için üç gün boyunca log formatlama kütüphanesi yazabilir. Bu durum suçluluk hissi uyandırmaz çünkü ortada çalışan bir kod vardır.

Kusursuz Kamuflaj: Suçluluk Yaratmayan Altyapı Yatırımları

Mühendislik dünyasında kaçış yolları yasal gerekçelerle doludur. Sosyal medyada vakit geçirmek veya oyun oynamak net bir ertelemedir; geliştirici bunun farkına varır ve suçluluk hisseder. Ancak kendi iç araçlarını geliştirmek veya altyapıyı optimize etmek teknik bir zorunluluk gibi sunulur. Geliştirici, “Önce sistemi doğru kurmalıyım, ardından satışa odaklanacağım” gerekçesinin arkasına saklanır.

Bu durum bizi tehlikeli bir noktaya taşır. Kod tabanını düzenlemek veya yeni bir otomasyon mekanizması kurmak, asıl ürünün pazarda karşılık bulup bulmayacağı sorusunu öteler. Yazılımcı, çalışan bir prototip ürettiğinde işin bittiğini düşünür. Oysa teknik hazırlık, müşteriye giden yolun kendisi değildir. Kod yazarken harcanan her saat, belirsiz olan dış dünyayla yüzleşmeyi bir gün daha erteler.

Kendi deneyimimden örnek verebilirim. Seodisias projesini geliştirirken benzer bir döngünün içine girdim. Başlangıçta SEO verilerini toplamak ve analiz etmek için basit bir mekanizmaya ihtiyacım vardı. Bu somut bir gereksinimdi. Fakat aracın ilk sürümü bittikten sonra, mimariyi yeniden kurmak, veri tabanı sorgularını optimize etmek ve komut satırı arayüzünü cilalamak için haftalar harcadım. Sadece iki web sitesinin verisini tarayacak bir sistem için SQL sorgularını milisaniyeler seviyesine indirmeye çalışıyordum. O günlerde kendime bu geliştirmelerin gerekli olduğunu söylüyordum. Bugün geriye dönüp baktığımda, bu çabanın ne kadarının gerçek bir işe yaradığını, ne kadarının ise ürünü insanlara sunma sorumluluğundan kaçmak için yapıldığını net olarak söyleyemem. İtiraf etmek gerekirse kod yazmak, satış yapmaktan her zaman daha kolaydır.

Aynadaki Kırmızı Işıklar: Kendi Kendini Kandırmanın Beş İşareti

Kendi aracını yapmak eyleminin bir kaçış mekanizmasına dönüştüğünü anlamak için belirli işaretleri takip etmek gerekir. Bu işaretler, geliştiricinin aynaya baktığında görmesi gereken kırmızı ışıklardır.

İlk olarak, geliştirilen aracı yalnızca yazarı kullanıyordur ancak güncellemeler durmaksızın devam ediyordur. Komut satırı çıktısının renklerini değiştirmek, kullanılmayan parametreler için destek eklemek veya test kapsamını yüzde yüz yapmak için harcanan hafta sonları bu durumun göstergesidir. Örneğin, loglama aracını Winston yerine Pino kütüphanesine taşımak için bir cumartesi gününü harcamak konfor alanında kalma arzusudur. Ortada tek bir kullanıcısı olan ve işletmeye doğrudan gelir getirmeyen bir araç varsa, yapılan çalışma yalnızca bir oyalanma biçimidir.

İkinci işaret, her önemli pazar adımından önce yeni bir teknik ön koşulun icat edilmesidir. “Müşteriyle görüşmeden önce şu dağıtım betiğini tamamlamalıyım” veya “Lansman yapmadan önce yeni bir performans izleme aracı yazmalıyım” cümleleri tanıdıktır. Bu ön koşullar hiç bitmez çünkü her biten aracın ardından bir diğeri tanımlanır. Hedef, asıl zor olan lansman anını ileriye atmaktır.

Üçüncü durum, zamanın matematiksel dağılımında gizlidir. Haftada kırk saatini kendi iç kütüphanelerini yazmaya ayıran bir yazılımcı, satış ve müşteri bulma faaliyetine yalnızca bir saat ayırıyorsa hedeflerinde dürüst davranmıyordur. Zaman kaydı yalan söylemez. Zamanı kontrol etmeyen geliştirici, üretkenlik maskesi takmış bir kaçak durumuna düşer.

Dördüncü işaret, yeni sürümlerin ve refactor çalışmalarının lansman heyecanını gölgelemesidir. Sürüm numarasını ikiye çıkarmak, ilk kullanıcıdan geri bildirim alma düşüncesinden daha fazla heyecan veriyorsa yön şaşmıştır. Kod tabanını temizlemek güvenlidir, müşteriyle karşılaşmak ise gerçektir.

Beşincisi, kullanım senaryolarının masa başında uydurulmasıdır. Geliştirici, hazırladığı aracın çözdüğü sorunları liste halinde yazar. Fakat bu sorunları yaşayan tek bir canlı kişiyle dahi konuşmamıştır. Readme dosyasındaki senaryolar gerçek dünyada karşılığı olmayan varsayımlardan ibarettir.

Masadaki Tek Soru: Kaldıraç mı Yoksa Savunma Mekanizması mı?

Bazı araçlar gerçekten işi hızlandırır. Tekrarlayan el işlerini otomatikleştiren bir script veya veri aktarımını kolaylaştıran bir entegrasyon gerçek bir kaldıraçtır. Bu ayrımı yapmak için her yeni geliştirme kararından önce kağıt üzerine tek bir soru yazmak gerekir.

Sorulacak asıl soru, bu araç olmadan bugün hangi işin yapılması gerektiğidir.

Bu soruya verilecek cevaplar gerçeği ortaya çıkarır. Eğer cevap “potansiyel kullanıcıları aramak, satış e-postaları göndermek veya mevcut sistemdeki karmaşık bir hatayı çözmek” ise ve geliştirici bunların yerine yeni bir CLI aracı yazmaya yöneliyorsa, ortada bir savunma mekanizması vardır. Sürekli meşgul olmak, işi bitirmek anlamına gelmez. Değer üretmeyen her meşguliyet, zamanı boşa harcamaktır.

Kendi aracını yapmak bir geliştiricinin en büyük gücüdür. Ancak bu gücün, zor kararları ertelemek için bir sığınak olarak kullanılması verimliliği yok eder. Yazılımcı, araç üretmeyi tamamen bırakmak yerine, klavyenin başına geçmeden önce listenin en tepesindeki zor işi tamamlamalıdır. Kod, editörün içinde bekleyebilir. Müşteri ise beklemez.

Bugün yeni bir kod satırına başlamadan önce kendi zaman kaydını incele ve asıl kaçtığın işin hangisi olduğunu belirle.