- Kıdemli geliştiriciler ile geliştirici olmayanlar, AI ajanlarının geliştiricilerin yerini alacağı yönündeki aynı cümleyi; istikrar ve pazar öğrenimi gibi farklı ölçütlerle değerlendirir
- İş ekipleri hızla ürün çıkarıp geri bildirim alarak belirsizliği azaltmak isterken, kıdemli geliştiriciler sistemi bozabilecek artan karmaşıklığa karşı temkinlidir
- Müşteri oluştuktan sonra, pazarı keşfetme ve hizmeti sürdürme şeklindeki iki döngü aynı anda işler; kıdemli geliştiricinin temel sorumluluğu da karmaşıklık yönetimine dönüşür
- İkna, “sorun karmaşıklık” demekle bitmez; Google Forms ya da mevcut arayüzdeki butonlar gibi daha hızlı deneylerle karşı tarafın hız ihtiyacını da karşılamak gerekir
- AI, yayına çıkma hızını artırır ama anlaşılabilirlik, değiştirilebilirlik ve hata ayıklanabilirliğe zarar verebilir; ayrıca sorumluluk da almaz, bu yüzden kıdemli geliştiriciler Speed ve Scale'i ayırabilir
Aynı cümleyi neden farklı ölçütlerle duyuyoruz?
- Kıdemli geliştiriciler ile geliştirici olmayanlar, “AI ajanları yazılım geliştirmenin geleceğidir ve geliştiricilere artık ihtiyaç kalmayacaktır” cümlesini farklı biçimde algılar
- Metin yazarlığında mesaj hedef kitleye uygun olmalıdır; aynı cümle, dinleyene göre farklı anlamlara gelebilir
- Kıdemli geliştiricilerin sezgisinin AI iyimserliğinden ayrışmasının nedeni, işin odağının pazar öğrenimi mi yoksa hizmet istikrarı mı olduğuna göre problemin tanımının değişmesidir
Kıdemli geliştiricilerin temkinli olduğu şey
- Bazı kıdemli geliştiriciler, yeni araçlar, başka şirketlerin yöntemleri ya da Hacker News'teki en iyi uygulamaları gerekçe göstererek bir şeyler benimsemeye çalışır
- Daha çok tercih edilen kıdemli geliştiriciler ise önce “Buna gerçekten ihtiyaç var mı?”, “Yapmazsak ne olur?”, “Şimdilik dayanıp, daha önemli hale gelirse sonra tekrar bakabilir miyiz?” diye sorar
- Bu tip geliştiriciler, geliştirmeyi mümkün olduğunca kaçınılacak, azaltılacak ve yeniden kullanılacak bir şey olarak görür
- Profesyonel yazılım geliştirmede kıdemli geliştiricilerin en çok çekindiği şey karmaşıklıktır
- Özel durumlar, koşul ifadeleri, yeni veritabanı tabloları ve yeni bileşenlerin hepsi sisteme karmaşıklık ekler
- Çalışan bir sistemin sorumluluğunu taşıyan geliştiriciler, eninde sonunda artan karmaşıklıktan korkar hale gelir
- Yeni ve yaratıcı tasarımlar yapmada iyi olan kıdemli geliştiriciler bile çalışan bir sistemi devraldıklarında karmaşıklığa karşı temkinli olur
İş ekiplerinin temkinli olduğu şey
- Pazarlamacılar, satış ekipleri, ürün yöneticileri ve CEO'lar; pazara bir şey sunup geri bildirim alarak bunun değerli olup olmadığını öğrenme döngüsünün içindedir
- Bu döngünün amacı öğrenme, en büyük tehdidi ise belirsizliktir
- Hiçbir stratejinin başarı garantisi olmadığı için belirsizlik son derece sert işler
- Pazarlama ve satış hedefleri, kurucunun maaşı ve ürün yöneticisinin verileri zaman baskısıyla birleştiğinde, teslim tarihinden önce belirsizliği azaltmanın tek yolu mümkün olduğunca hızlı şekilde pazara çıkmakmış gibi görünür
- Pazara ne kadar çok şey sunulursa, o kadar çok geri bildirim alınır ve potansiyel olarak belirsizlik o kadar azaltılabilir
- Her şirket bu döngüyle başlar ve bu döngü saf hız etrafında döner
Müşteri geldikten sonraki ikinci döngü
- Müşteriler para ödemeye başladıktan sonra, hizmetin sürdürülmesini ve güvence altına alınmasını hedefleyen ikinci bir döngü oluşur
- Sistemin çalışmaya devam etmesi, anlaşılabilir, hata ayıklanabilir, değiştirilebilir, öğretilebilir ve istikrarlı olması gerekir
- Kıdemli geliştiriciler, müşterilere hizmeti sürdürme yönündeki iş sorumluluğunu üstlendikleri için istikrara önem verir
- Bütün bunları tehdit eden şey yine karmaşıklıktır
- Karmaşıklık; sistemi daha az anlaşılabilir, daha zor hata ayıklanabilir, daha zor değiştirilebilir, daha zor öğretilebilir ve sonuç olarak daha az istikrarlı hale getirir
- Karmaşıklık arttıkça istikrar düşer; kıdemli geliştirici sorumluluğunu yerine getiremez ve ödeme kesintileri gibi sorunlar ortaya çıkabilir
- İlk döngünün amacı belirsizliği azaltmaksa, ikinci döngünün amacı karmaşıklığı yönetmektir
İletişimin koptuğu nokta
- Müşteri oluştuktan sonra, pazarı keşfetme ve hizmeti sürdürme şeklindeki iki döngü aynı anda çalışır
- İş tarafı hem yeni olasılıkları keşfetmeli hem de mevcut müşterilere hizmet vermelidir
- Hangi döngüye zaman ayırdığınıza bağlı olarak, aynı problem farklı görünür
- İş ekipleri belirsizliği azaltmak için daha hızlı üretmek ve daha hızlı pazara çıkmak ister
- Kıdemli geliştiriciler ise talepler arttıkça karmaşıklık, bakım maliyeti, anlaşılabilirlik, sürdürülebilir geliştirme hızı ve zaman içindeki üretkenlik konusunda endişelenir
- Ama yalnızca karmaşıklık yönetiminin diliyle konuşmak, diğer ekiplerin belirsizliği azaltma isteğini karşılamakta yetersiz kalır
- İkna etmek için, kıdemli geliştiricinin çözümünü karşı tarafın problemine de çözüm olacak şekilde ifade etmek gerekir
- İletişim, problem karmaşıklık yönetimi açısından anlatılırken çözüm belirsizliği azaltma açısından ifade edilemediğinde başarısız olur
Kıdemli geliştiricilerin gerçek gücü
- Kıdemli geliştiricilerin en yararlı yeteneği, gereksiz şeyler inşa etmemek ve zaten yapılmış olanı yeniden kullanma fırsatlarını bulmaktır
- Anket verisi toplanacaksa Google Forms kullanılabilir
- Baştan sona yeni bir özellik geliştirip test etmek yerine, mevcut arayüze bir buton ekleyip insanların tıklayıp tıklamadığı görülebilir
- Yeni bir analiz hizmeti devreye almadan önce, önce analize ihtiyaç duyan en kritik kararın ne olduğu sorulabilir; tek bir karar, tek bir grafik ve tek bir metrikle başlanabilir
- Bütün bir doğum günü pastası pişirmek yerine, bir sandviçin üstüne tek bir mum dikmek gibi bir yaklaşım mümkündür
- Kıdemli geliştiriciler, insanların istediğini mevcut yazılımlardan yararlanarak nasıl sağlayacaklarını öğrenir
- Bunu kısa biçimde ifade eden cümle şudur: “Can we try something quicker?”
- “quicker”, karşı tarafın gerçekten istediği hızın kabul edildiğini gösterir
- “something”, aynı sonuca ulaşmanın başka yolları olabileceğini ima eder
- “try”, kusurlu olsa da yeterince iyi olabilecek bir seçeneğe alan açar
- Bu cümle, şirketin istediği belirsizlik azaltma hızını kabul ederken; kıdemli geliştiricilere azaltma, yeniden kullanma ve mümkünse kaçınma yönündeki uzmanlıklarını kullanma alanı verir
AI'ın değiştirdiği baskı ve geride kalan sorumluluk
- AI kısa sürede çok şey üretebildiği için, azaltma, yeniden kullanma ve kaçınma yaklaşımı anlamsızmış gibi görünebilir
- Ancak AI, kıdemli geliştiricilerin yaptığı bir şeyi, yani sorumluluk almayı, hâlâ yapamaz
- Kıdemli geliştiricilerin sistemin anlaşılabilirliğine önem vermesinin nedeni, sorun çıktığında onu düzeltebilmek zorunda olmalarıdır
- Anlaşılabilirlik, sistem büyümesi gerektiğinde onun akıllıca ölçeklenmesini ve ücretli müşterilere istikrarlı biçimde hizmet vermeyi mümkün kılar
- AI, pazara çıkış hızını büyük ölçüde artırır; ama kıdemli geliştiricilerin sorumluluğunu taşıdığı istikrar döngüsünü de etkiler
- AI ajanları, junior geliştiriciler, geliştirici olmayanlar, yatırımcılar ve onların çevresindekiler sisteme kod ekledikçe; sistem hızın aşırı ödüllendirildiği, istikrarın ise feda edildiği bir yapıya dönüşebilir
- AI; anlaşılabilirliği, değiştirilebilirliği, hata ayıklanabilirliği, öğretilebilirliği ve güvence altına alınabilirliği kötüleştirebilir
- AI sistemi istikrarsız hale getirebilir ama bunun sorumluluğunu üstlenmez
- Kıdemli geliştiricilerin temel kaygısı tam da budur
Kod yazardan çok editöre benzeyen kıdemli geliştirici
- Kıdemli geliştiricilerin kullanabileceği yöntemlerden biri ayrıştırma (decoupling) yaklaşımıdır
- Uzun süre boyunca yalnızca yazılım geliştiriciler yazılım üretebildiği için, geliştiriciler hem pazar öğrenimi hem de hizmet istikrarı şeklindeki iki döngüden birden sorumluydu
- Tek bir sistem aynı anda bu iki hedefi taşımak zorundaydı
- Her hedef için ayrı bir sistem kurulursa, hız ile istikrar birbirinden ayrılabilir
- Bu, bir romancının önce hızlıca taslak yazıp, sonra işe yarayan parçaları seçip yaramayanları attığı editörlük sürecine benzer
- Editörün işi, iyi çalışan parçaları alıp onları tutarlı bir bütün haline getirmektir
- Speed versiyonu hız için kurulan sistemdir; burada AI ajanları, üretilmiş ama gözden geçirilmemiş kod, junior geliştiriciler ve pazarlama ekipleri fikirleri hızla hayata geçirebilir
- Speed versiyonu, anlaşılabilir olmayı değil; pazar geri bildirimi almaya yetecek kadar iyi olmayı hedefler
- Scale versiyonu ise istikrar için kurulan sistemdir; kıdemli geliştiriciler bunu istikrarlı, anlaşılabilir ve ölçeklenebilir olacak şekilde tasarlar
- Speed versiyonu iş tarafının pazardan öğrenmeye devam etmesini sağlar; kıdemli geliştiriciler de bunun arkasından iyi incelenmiş ve anlaşılabilir bir sistem kurar
- Scale versiyonunun tasarımı, Speed versiyonunda neyin işe yarayıp neyin yaramadığına göre şekillenir
- Özellikler önce Speed tarafında oluşturulur, sonra Scale tarafında sağlamlaştırılır
- Gerçek uygulama biçimi net olmayabilir; ancak önemli olan, hız peşinde koşan işle istikrar peşinde koşan işi açıkça birbirinden ayırmaktır
- İddialı bir taleple karşılaşıldığında, “Speed versiyonunu 3 gün içinde hazırlayacağım, Scale versiyonu ise yaklaşık 6 hafta sonra hazır olur” denebilir
- Böylece karşı taraf hız ve ivme kazanır, kıdemli geliştirici ise gözlem ve tasarım için zaman elde eder
- Bu açıdan bakıldığında, kıdemli geliştirici “kıdemli yazılım yazarı”ndan çok kıdemli yazılım editörüne benzemeye başlayabilir
1 yorum
Hacker News görüşleri
Uzmanlığın en önemli kısmı içsel dünya modelinden gelir ve ondan ayrılamaz
Genelde her şeyin sözle ifade edilebileceğine ve söylenenler aktarıldığında dinleyenin konuşanın kastını aynen anlayacağına inanılır; geliştiricinin uzmanlığını başkalarına “aktarması” yönündeki talep de bu inançtan doğar
Aslında bilgi sözle epey iyi aktarılabilir, ama tüm bilginin birbirine bağlanıp katılaşmış hali olan dünya modeli böyle değildir. Yapay zeka olgulardan çok daha fazlasını bilebilir, ama o bilgiyi hâlâ bu temelden hareketle şaşırtıcı derecede sık isabet eden içgörüler üretmek için kullanmıyor
Uzmanlık aktarımı gerçekte daha çok nereye gidileceği ve ne öğrenileceğine dair ipuçları vermeye benzer; alan kişinin de bunu içselleştirmek için çaba göstermesi ve uygun projeler aracılığıyla aynı uzmanlığı edinmesi gerekir
Yazılımın “fizik yasalarını” anlayıp uygulayan kişiyle, sadece prosedürü adım adım yazıp her aşamanın özünü anlamaya çalışmayan kişi ayırt edilir
Bu, nesne yönelimliye alışkın birine fonksiyonel programlama öğretirken özellikle belirgin olur; bazılarında model çöker, bazıları ise değişkenler dünyasından monadlar dünyasına görece kolay bir çeviri yapılabildiğini hızla görür
Neredeyse 30 yıldır çoğunlukla büyük bir şirkette çalıştım ve her hafta hatırı sayılır bir zamanı yeni gelenlerin yaşadığı sorunlara yanıt vermeye ayırıyorum. Daha soruyu duyar duymaz, problemin kökünün onların dünya modelinin, Naur’un dediği Theory’nin, eksik ya da çarpık olması nedeniyle akıl yürütmeyi zorlaştırdığını hemen fark ettiğim çok oluyor
Görev, kişinin kendi teorisini metin ve diyagram gibi sembolik ifadelere çevirerek yeterli deneyim ve zekâya sahip birinin benzer bir zihinsel model kurmasını sağlamak. Yani kendi teorimi başkasının zihnine kurmak istiyorum
Naur’un sözünü ettiği türden teori doğrudan nakledilemez, ama bence senior geliştiricinin işi, ister sınıfta ister sahada olsun, deneyimi devreye sokup böyle bir teoriyi yeniden üretecek yolu bulmaktır. Bu yüzden iletişim becerisi önemlidir ve başkalarından işleyen teoriler alma sürecini birçok kez yaşamış olmak etkili sezgiler geliştirmeyi sağlar
Artık bu iş, yaptığım işin en tatmin edici kısmı oldu ve bu işlevi anlamlı biçimde yerine getirdiğimi hissettiğim sürece emekliliği aceleye getirmek istemiyorum
Juniorları eğitirken ve mentorluk yaparken nelerin mümkün olduğunu ve hangi kalıpların başarısızlığa yol açtığını göstermeye çalışıyorum, ama bu eğitim çoğu zaman parçalı ve eksik kalıyor
Mümkün olduğunca neden öyle yaptığımızı açıklıyorum, ama “şunu asla yapma” diye kestirip attığım şey çok az. Yetiştirdiğim insanların sorun çözme biçimlerine sık sık şaşırıyorum, ben de sık sık öğreniyorum
Kendi katkısıyla ilgilenmeyen ve işi sadece maaş aracı olarak gören kişilerde eğitim daha az başarılı oluyor. Bunun yanlış bir bakış olduğu anlamına gelmez ama kayıtsızlık üzerine bir iş dünya görüşü kurulduğunda eğitimi içselleştirmek zorlaşır
https://andymatuschak.org/books/
Bir senior geliştirici olarak genelleyici kesin yargılardan gerçekten nefret ederim
“Buna gerçekten ihtiyaç var mı?”, “Bunu yapmazsak ne olur?”, “Şimdilik idare edip daha önemli hâle gelirse sonra dönebilir miyiz?” gibi tutumlar yüzünden başarısız olan örnekleri, deney peşinde koşanlar yüzünden başarısız olanlar kadar gördüm
Her sistem farklıdır, her ürün farklıdır. CT tarayıcı firmware’i geliştiriyorsanız yeni denemelere yaklaşımınız, 100 müşterili bir CRUD SaaS’tan farklı olmalıdır
Hevesli ve aşırı açık fikirli seniorların sistemi çıkması zor köşelere sıkıştırdığı durumlar elbette vardır, ama PHP5’in yeterli olduğunu söyleyen insanlar da vardır
İyi bir senior, bunun ne zaman hangisi olduğunu anlayabilmelidir
Sonra bu, teknik karar alırken başkan yardımcısını dinleyip Elasticsearch kullanmak gerektiği gibi bir kurala dönüştü
Elbette bazı durumlarda harekete geçmek gerekir, ama bugün denge gerekenden fazla her şeyi karmaşıklaştırma yönüne kaymış durumda
Yeni ürün ve hizmetler üretmeyelim demek değil bu; üretirken toplam entropiyi en aza indiren yolu arayalım demek. Bu, operasyon ve teknik borcu azaltma için de geçerli
Erken optimizasyon tüm kötülüklerin anasıdır
Startup’ta mı yoksa nakit akışı oturmuş büyük bir şirkette mi olduğunuza göre ürünün çekirdek işlevini değiştirme kararı farklılaşır
Yazıyı keyifle okudum ve ana mesaj olan hedefe göre daha iyi iletişim kurma fikrine katılıyorum
Ama çerçeveleme sanki doğru bir yoldan başlayıp biraz farklı bir yöne sapmış gibi geldi
Sunulan iki döngü de ne kadar sıkı ve hızlıysa o kadar faydalı. Biri sistemi hızlıca “istikrarlı” ve bakımı yapılabilir bir denge noktasına götürüyor, diğeri ise belirsizlikle ilgileniyor
Yapay zekaya daha iyi uyum sağlamak için sistemi bölme yönündeki ek içgörü de, yapay zeka ana akım olmadan çok önce spike’larla anlattığım bir şeydi
Uzmanlığımı iletişimle aktarma ve paylaşma isteğimin genelde junior geliştiricilerde bir karşılığı olmadığını fark ettim
Geliştiriciler çoğunlukla mentor aramakla ilgilenmiyor. LinkedIn profilime bile bakmıyorlar, beni bilgi ve uzmanlık için olası bir kaynak olarak da görmüyorlar
Sektörde 30 yıllık deneyimin ardından paylaşacak bir şeyim olmamasından değil, paylaşacak kimsenin olmamasından söz ediyoruz
Daha az deneyimli bir geliştirici, URL doğrulayıcıyı AI büyüsü ile değiştirmeyi önerdi; ben de buna karşı çıkıp yapay zeka ile önceden doldurulmuş önbellek tabanlı bir fuzzy matching çözümü önerdim ama kimse umursamadı. Şimdi AI modeli ansızın kapandı ve sistem bozuldu. Tüm sistemi yeniden doğrulamamız gerekiyor
Benden önce terfi alan daha genç bir geliştirici, bunu düzeltme yolunu belgeye dökerken “Dan, buna yardım edebilir misin?” dedi. İlerleme yöntemi makul çalışmak değil de belge yazmak ve toplantı yapmak olduğu için o terfi etti; şimdi de benim emeğimi kullanarak liderlik kanıtlamaya çalışıyor
Daha iyi çözümler önerdikçe daha az deneyimli geliştiriciler için tehdit hâline geliyorum ve işler çoğunlukla bir şekilde yürüdüğü için yöneticiler de aldırmıyor. Benim de bunu daha iyi ele alma yollarım olabilirdi ama saçmalıkla savaşmak çok yorucu ve ben sadece iyi kod yazmak istiyorum
Öte yandan juniorlar konuşmak, öğle yemeği yemek ve ne yaptıklarını paylaşmak istiyor. Seniorlar ise mesafeli ve yalnız
Belki sadece bizim işyerimize özgüdür ama ofis önemli
Oradaki bazı senior geliştiriciler, junior bir şey sorduğunda sinirlenirdi. 20 yıllık birine soru sormak zaten cesaret isterken, bunun %50 ihtimalle kötü karşılanması cabasıydı
İyi bir öğrenme deneyimi oldu ve şimdi özellikle mentorluk yapmaya çalışıyorum
Son birkaç on yılda aralıklı olarak mentorluk yaptım ve harika mentilerle karşılaşma şansım oldu. Bazılarını neredeyse 10 yıldır izliyorum ve şu anda çok iyi durumdalar
Nasıl bulunacakları konusunda daha faydalı bir şey söyleyemem ama böyle insanlar var
Ama ben geldikten hemen sonra onun yerini doldurduğunu söyleyip istifasını verdi ve sonuç benim için pek iyi olmadı
Gördüğüm çoğu kavram kanıtı biraz ilgi görünce prodüksiyon oldu
“Tutar da büyürse baştan yazarız” diye herkesin söz verdiği birkaç durum oldu, ama bu hiç gerçekleşmedi
Yazı sorumluluk ve hesap verebilirliğe değiniyor ama riski alan kişi için bunların hiçbiri yok. Çılgın bir fikri hızla dışarı salar, müşterilerin yutmasını umar ve kazancını alır. Bunun nasıl çalışacağı, nasıl ölçekleneceği ve işletim maliyetinin satış fiyatını aşmamasının nasıl sağlanacağı onun derdi değildir
Sağdaki döngüyü uç noktaya götüren şirketler oldu ve bugün bunlardan ikisi çok meşhur. Bir şeyi hızlıca piyasaya sürüyorlar, sadece doğrusal biçimde ölçeklendiriyorlar ve sonra para toplamaya gidiyorlar. Başarılı şirketler, sayısız kullanıcıları var ve bazıları para da ödüyor. “Bu sürdürülebilir mi, çıkış yolu ne?” diye soran senior geliştiriciler ya da makul insanlar kovuluyor; geriye sadece inananlar kalıyor
Mühendisler teknik olmayan paydaşların dediğini sessizce yaparsa bir sorumluluk boşluğu doğar ve bir gün büyük felaket gibi patladığında kendini en kötü savunabilen kişi suçlanır
Tersine, bakış açısını yeterince genişletip yeterince “neden” sorarsanız, neredeyse her iş problemini sistemi korkunç tek yönlü kapılara zorlamadan makul bir şekilde çözebilirsiniz
Her şirket mühendisliğe bu yetkiyi vermez ama vermeyen yerler, muhakemesine saygı duyulan yerlere giden seniorları elinde tutamaz. Bazen teknik borç iş açısından doğru seçim olabilir ama yeterince senior bir mühendis her zaman bir çıkış yolu bırakabilir
Yine de sistemin saflığını iş problemlerinin üstüne koyamazsınız. Sistemin maliyetini iş ödediği için bunu unutursanız etkinizin temelini de kaybedersiniz
Yazının vardığı sonuç aslında eski tavsiye olan “bir tanesini çöpe atmayı planlayarak yap” fikri. Ben de Mythical Man-Month’u okudum ama mesele karar vericileri buna nasıl ikna edeceğimiz
Beklentiyi karşılamazsa özelliği kapatıyor ya da siliyorduk; aksi halde inceleyip düzgünce refactor ediyorduk
Takım özerkliği yüksekti ve takvim baskısı şikâyeti de neredeyse yoktu, çünkü çoğu zaman diğer departmanlar geriden geliyordu. Yalnız pazarlamanın her zaman bir “fikri” vardı
Bunun prototip ya da kavram kanıtı olması, gerçek sorunun ne olduğunu sıralayamıyorsanız özünde önemli değildir
Birçok takımın teknik borç içinde yüzdüğünden, bunun büyük risk olduğundan ve hızı düşürdüğünden yakındığını görüyorum ama olay kayıtlarında kayda değer bir vaka yok ve prodüksiyonda tehlikeli kod çalıştırmanın sonucu sayılabilecek bir şey de görünmüyor. Risk kayıtlarında da “bu kod eski, korkunç ve desteği bitmiş bağımlılıklara sahip” gibi bir madde yok; hiçbir takım teknik borcun onları nasıl ve ne kadar yavaşlattığını açıklayamıyor
Öte yandan, yayına çıkmadan önce yazdıkları uygulamayı daha “iyi” hâle getirebileceklerini söyleyip aylarca refactor yapan ekipler de gördüm. Tüm değer teslimi gecikti, liderlik doğal olarak öfkelendi ve güven neredeyse tükendi
Takımla paydaşlar arasında teslimat konusunda iyi bir diyalog kurulursa herkes memnun olabilir ama bu yoksa kazanan taraf her zaman paydaşlar olur
Asıl sorun olan teşvikleri gözden kaçırıyor
“Şirketin” ne istediği önemli değil; belirli kararları veren insanların ne istediği önemli. Yeni bir özellik ya da uygulama çıkarıp bunu şirket metriklerinden bir yerlerde görünür kılmak sayesinde işini koruyan insanlar var. Senior geliştirici bunun kötü fikir olduğunu söylese bile böyle insanlar dinlemez ya da umursamaz. Çünkü söz konusu olan kendi işleri
Ama ürün tarafındaysanız özellikleri müşteri ihtiyaçlarına uydurmanız gerekir; dolayısıyla araştırmacıya dayatmayı bırakması söylenmelidir
Gerçekten yetkin bir senior, mevcut şirket kültürünün baskın yapısının ne olduğunu ve 5 yıl sonra ne gerekeceğini anlar, sonra da buna göre uyum sağlar
5 kişilik bir startup’ın pisti kısaltacak ek karmaşıklığa ihtiyacı olmayabilir. 500 kişilik bir şirketin ise tüm iş kararlarının ikinci dereceden etkilerini hafifletmek için bu karmaşıklığa ihtiyacı olabilir
Bu, “her zaman karmaşıklıktan kaçın” gibi siyah-beyaz bir mantık değil; “anlamlı olduğunda karmaşıklık ekle” yaklaşımıdır ve şirketin birkaç ay daha hayatta kalması gereken durumlarda bu soru bile son derece nüanslı hâle gelir
Fırtına gelmeden iki saat önce mimariyi düşünmek yerine “Su öyle yükselir mi ki artık dışarı atamayız?” diye sormaya başlarsınız
Benim gördüğüm sorun, yöneticilerin gerçekte ne kadar para kaldığını ya da gerçek takvimin ne olduğunu söylemeyip oyun oynaması. Bunun nedeni, kritik an gelmeden katkı verenlerin ayrılmasından korkmaları; ama bunun sonucu insanlar bu bağlamda aptalca kararlar almaya devam ediyor ve sonunda herkes yeni iş aramaya başlıyor
Birkaç gündür ekibe neredeyse aynı duyguları aktarmaya çalışıyordum; özellikle de “Yeni özelliğin tamamını inşa edip test etmek zorunda mıyız? Mevcut UI’a bir düğme ekleyip insanların tıklayıp tıklamadığına baktık mı?” cümlesi neredeyse kelimesi kelimesine aynıydı
Görünüşe göre ürün tarafı artık kendi zihinsel kapasitesini kullanmak zorunda olmadığına karar verdiğinden, mühendisler topluca acı çekiyor. Mantık şu: Önce inşa et, kullanıcı personasını ve faydayı sonra, belki de hiç, anlarsın
Eskiden alanı, kullanıcıyı ve ürünün hangi sürece oturduğunu anlamaya zaman ayrılırdı; şimdi ise hayali kullanıcıların istediği varsayılan şeyler piyasaya sürülüyor ve başarılı olana kadar deney yapılıyor
Asıl yazının anlattığı sorun tam da bu. Vibe coding ile üretilmiş her rastgele özellik, bir istikrarsızlık ve risk kaynağına dönüşüyor; üstelik onunla ilgili çalışan bir zihinsel modele kimse sahip olmadığı için bakım da ancak daha fazla vibe coding ile yapılabiliyor
Karmaşıklığı tek bir ölçüm boyutuna indirebildiğinizi varsaysak bile, bu çözüm uzayındaki birçok unsurdan sadece biridir
Bakım yapılabilirlik, ölçeklenebilirlik, güvenilirlik, dayanıklılık, antifragility, büyütülebilirlik, genellik, kalıcılık, birleştirilebilirlik gibi başka nitelikler de vardır ve bunların hepsi her zaman geçerli değildir
Bence senior ile Staff+ geliştiriciyi ayıran şey, tek bir boyuttan değil çözüm uzayındaki trade-off’lar üzerinden konuşabilme becerisidir
Ama önümüzdeki 10 insan-yıl boyunca bu sistemin geliştirilmesini daha kolay ve hızlı kılacak unsurlar olarak anlaşılırsa, naif yaklaşımın dümdüz ilerlemeye çalıştığı yerde yandan dolaşan seçimler anlamına gelir
Tavşan ile kaplumbağa masalındaki gibi, ilk iki haftayı aceleyle yakıp alçakta duran meyveyi, görünür çıktıları ve MVP’yi toplamak, sonra da olgunlaşmamış tasarım ve geliştirme sırasındaki bakım yükü yüzünden hızın sürekli düşmesi dinamiğini anlamak zordur. Birkaç hafta “hızlı” görünmüştür ama sonunda takvim 6 ay sarkar
Bir programcı ise sonunda tasarımın mümkün olan her yönünün bir trade-off olduğunu kavramalıdır