Sadece "olmaz" diyen mühendis, ZIRP dönemine özgü bir fenomendi
(seangoedecke.com)- Sadece "olmaz" diyen mühendis, kod değişikliklerini varsayılan olarak engelleyen, karmaşık özellikleri geciktiren ve mümkün olduğunca az kod yazılmasını sağlamaya çalışan bir kıdemli arketipidir
- ZIRP döneminde düşük faizler ve genişleyen işe alımlar sayesinde üretkenlik kaybı daha az önemliydi; radikal teknik önerileri engelleyen bu rol şirketler için faydalıydı
- Faizler yükseldikten sonra teknoloji şirketleri mühendislerinin %5 ila %20’sini işten çıkardı ve hisse fiyatından çok gelire odaklanınca, “olmaz” demenin arkasındaki koruyucu kalkan zayıfladı
- LLM’ler, yapay zeka üretimi PR’lar ve yeterince kullanılabilir kodlarla baskıyı artırdı; ancak temel değişim, yapay zekadan çok ZIRP’in bitmesiyle değişen ekonomik teşviklerdi
- Bu rol ortadan kalkmayacak, ancak saf mühendislik alanına daha uygun hale gelecek; bunun için de 2010’lara kıyasla daha dar bir kapsamı ve daha düşük görünürlüğü kabul etmek gerekecek
“Sadece olmaz diyen mühendis”in rolü
- Sadece olmaz diyen mühendis, kıdemli ve staff mühendisler arasında görülen bir arketiptir; özellik geliştirmeyi yavaşlatan, karmaşıklığı artıran değişiklikleri engellemeye ve mümkün olduğunca az kod yazılmasını sağlamaya odaklanan bir role yakındır
- Karşı uçtaki sadece olur diyen mühendis ise hızlı hareket etmeyi önemser, kod değişikliklerini varsayılan olarak onaylar, MTTR’yi MTBF’den daha önemli görür ve çok kod dağıtma eğilimindedir
- Mühendislerin çoğu bu iki uç arasında yer alır; ancak burada odak, “olmaz” rolüyle kendini güçlü biçimde özdeşleştiren mühendislerdir
- Yapay zeka çağında yalnızca junior mühendislerin PR’larını değil, yapay zeka üretimi kodları da topluca reddetmek gerekir; üstelik bazen yönetici ya da VP tarafından yazılmış kodları politik nedenlerle reddetmek daha da zor olabilir
- Kariyerde ilk kez standartları düşürüp “evet” deme yönünde ciddi baskı hissedilir; ama asıl neden yapay zekanın kendisinden çok ZIRP’in sona ermesidir
ZIRP’in yarattığı ortam
- ZIRP, “sıfır faiz politikası”nın kısaltmasıdır ve 2008 ile 2022 arasında bankaların şirketlere neredeyse sıfıra yakın faizle para verdiği yazılım geliştirme dönemini ifade eder
- Yatırımcılar bu borç parayı neredeyse her şeye yatırdı ve teknoloji şirketlerinin de düşük risk, yüksek getiri beklenen projeler için mühendis istihdam etmeyi sürdürmekte güçlü teşvikleri vardı
- Başarılı şirketler mühendis sayılarını onlarcadan binlere çıkardı; çevresel açık kaynak projeleri, bitmek bilmeyen teknik göçler ve başka dillere yeniden yazımlar gibi işlere kaynak ayırdı
- Yazılım mühendisleri için bu dönem, pazarlık gücünün yüksek olduğu ve neredeyse ne yaparlarsa yapsınlar yüksek ücret alabildikleri bir dönemdi
- Yönetim ekipleri, takımlar çok hızlı büyüdüğü için ayrıntılara dikkat etmekte zorlanıyordu; ayrıca mühendis sayısındaki artışın kendisi de hisse fiyatına iyi geldiğinden, birçok faaliyet büyük sorun olarak görülmüyordu
- Ancak fazla sayıda mühendisin tamamen serbest hareket etmesi sistemleri yönetilemez hale getirebilirdi; bu noktada “sadece olmaz diyen mühendis” şirketler için faydalı hale geldi
ZIRP döneminde “olmaz” neden değerliydi?
- Üretkenlik kaybı büyük bir sorun sayılmadığı için, şirket mühendislerinin yarısı değişiklik önerip reddedildikleri bir döngüde kalsa bile buna katlanılabiliyordu
- Bu yaklaşım, mühendislerin işin çekirdeğindeki sistemlere zarar vermesini engelleme etkisi de yaratıyordu
- Teknik özgürlük sarhoşluğuyla el yapımı bir veritabanına geçiş gibi radikal öneriler sunan mühendislerin %5’ini kontrol etmeye de yardımcı oluyordu
- Çok yüksek teknik standartlara sahip bir şirket itibarı işe alım açısından olumluydu ve ZIRP döneminde bütün teknoloji şirketleri sürekli işe alım yapıyordu
- “Junior çok kod üretir, senior daha az üretir, staff ise kodu kaldırır” sözü, uzmanın neredeyse hiç hareket etmeden değer yaratabildiği fikrini çekici kılar; ama staff mühendisin gerektiğinde çok hızlı biçimde çalışan çok sayıda kod da üretebilmesi gerektiği için bu ifade eksiktir
ZIRP sonrası değişim
- Bankalar faizleri yükseltince, neredeyse tüm teknoloji şirketleri mühendislerinin %5 ila %20’sini hemen işten çıkardı
- Şişkin mühendislik organizasyonlarını hisse fiyatını desteklemek için elde tutmak artık kârlı değildi; şirketlerin gerçekten para kazanması gerekiyordu
- Buradaki “para kazanmak”, mutlaka kâr etmek anlamına gelmiyor; en azından gelir üretmek anlamına geliyor
- Yüzlerce mühendise gelir getirmeyen işler yaptırdıklarını kabul etmek, işten çıkarmalar için iyi bir kamuya açık açıklama değildi
- ZIRP’in bitişi ChatGPT’nin yükselişiyle kabaca aynı döneme denk geldiği için, şirketler işten çıkarmaları yapay zekanın gücüyle açıklayabildi
- “Bu dönüştürücü yeni teknoloji sayesinde mühendis sayısının yarısıyla 10 kat değer sunabiliriz” mesajı güçlü görünür; ama gerçekten öyleyse mühendisleri tutup 20 kat değer üretmemek için neden yoktur
Daha odaklı şirketler ve zayıflayan koruma kalkanı
- Teknoloji şirketleri son 20 yılın herhangi bir döneminden daha odaklı durumda ve artık rastgele çok sayıda işe girişmek yerine para kazandıracak yeni kabiliyet ve özelliklerin peşinden umutsuzca koşuyor
- Bu yeni ortam, sadece olmaz diyen mühendis için açıkça elverişsizdir
- Eskiden bu mühendisler yönetimin örtük desteğini alırdı; biri şikâyet etse bile “o mühendisin ne yaptığını biliyoruz, olmaz dediyse güvenelim” denip konu kapanabilirdi
- Şimdi o destek kayboldu ve aynı davranışlar yönetim tarafından eleştiriliyor ya da aktif biçimde bozuluyor
- Daha fazla takım oyuncusu olman, “evet” diyebileceğin yollar bulman ya da önemli kararlarda artık danışılmaman gibi durumlar yaşanabiliyor
- 2022 öncesinde ödüllendirilen davranışlar artık kötü performans değerlendirmelerine yol açıyor; ekonomik teşviklerdeki değişimi kültürel değişimlerin birkaç yıl gecikmeyle izlemesi de mümkün
- Bu dönüşüm yapay zekaya bağlı değil; LLM’ler bu on yılda hiç yükselmemiş olsaydı bile şirketler yine mühendis çıkaracak ve “olmaz” rolünü üstlenen mühendisler aynı davranışların neden cezalandırıldığını anlamakta zorlanacaktı
Yapay zekanın eklediği sarsıntı
- ZIRP sona ermemiş olsaydı, LLM’ler “sadece olmaz diyen mühendis” için güçlü bir meşruiyet sağlayabilirdi
- Yapay zeka destekli kodlamayı ne açıkça ne de içeride sorgulamakta rahat olmayan şirketler, yapay zeka kodu tsunamisinin şirketi kaplamasını önlemek için bu mühendislere büyük ölçüde dayanırdı
- Gerçekte ise LLM’ler, mevcut yaraya bir de hakaret ekliyor
- Eskiden engellenecek olan yapay zeka üretimi PR’ların merge edildiğini görmek ve kendisinin de bu araçları kullanmasının istenmesi buna dahil
- Daha da kötüsü, yapay zeka araçlarının genel olarak işe yaraması
- Henüz herhangi bir tür felakete yol açmış görünmüyorlar; kod biraz daha az temiz ve biraz daha zor anlaşılır olabilir, ama yeterince kullanılabilir durumda
- Özellikle şirketin çok sayıda yeni şey denediği ve başarısız olanları attığı ortamlarda “yeterince iyi” kod işe yarar
- Son dönemde olayların arttığı düşünülse bile, bu gözlem yanlış olabilir ya da hız artışı ve işten çıkarmalar gibi ZIRP sonrası başka etkenler asıl neden olabilir
- “Sadece olmaz diyen mühendis” artık yalnızca geçimini değil, kimliğini de tehdit altında hisseder
- Teknik rolünün, teknoloji sektörünün son derece sıra dışı ekonomik koşullarına bağlı olduğunu kabul etmek ya da sonun hemen geldiğini söylemeyi sürdürmek arasında kalır
Saf mühendislik ve saf olmayan mühendislik
- “Sadece olmaz diyen mühendis” ortadan kaybolmayacak, ancak artık her teknoloji şirketine aynı ölçüde uymuyor
- Pure and impure software engineering yazısında ayrıştırılan saf mühendislik, derleyiciler veya dil çalışma zamanları gibi kapsamı iyi tanımlanmış ve esas olarak teknik hedeflere sahip işlerdir
- Saf olmayan mühendislik ise, başarısı baştan garanti olmayan yeni özellik denemeleri gibi kapsamı belirsiz ve müşteri odaklı hedeflere sahip işlerdir
- ZIRP döneminde teknoloji şirketleri, React) gibi saf işleri çok daha fazla yapıyor ve saf olmayan işleri bile saf iş gibi ele alma eğilimi gösteriyordu
- “Sadece olmaz diyen mühendis” saf işlerde çok iyi uyum sağlar
- Çünkü saf kod tabanları çok daha yüksek kalite standartları ister ve daha yavaş geliştirme döngülerini tolere edebilir
- Teknoloji şirketlerinin çoğu hâlâ çekirdek altyapı gibi alanlarda bir tür saf iş yapıyor
- Bu işler zorunludur, ancak devasa mühendislik ekipleri gerektirmez ve çoğu zaman spot ışığını da üzerine çekmez
- “Sadece olmaz diyen mühendis” olarak kalmak istiyorsan, bu tür rollere yönelmen gerekir; fakat 2010’lara göre daha dar bir kapsamı kabullenmen de gerekir
Tartışmalar ve tamamlayıcı bakış açıları
- lobste.rs ve Reddit üzerinde, yapay zeka kodunun etkisinin zamanla ortaya çıkacağı ve bu yüzden “genel olarak işe yarıyor” demenin erken olduğu yönünde eleştiriler vardı
- “Bunu söylemek için henüz erken” itirazı kolay kolay yanlışlanamaz; ancak yapay zeka kodunun hemen ölümcül sonuçlar doğurmadığı da açık görünüyor
- “Sadece olmaz diyen mühendis” arketipinin ZIRP’ten önceki onlarca yılda da var olduğuna dair itirazlar da geldi; Linus Torvalds buna örnek gösterildi
- Bu arketipin kendisi ZIRP’in ürünü değil; fakat bakış açısına göre ZIRP, bu rolün nişini yapay biçimde genişletti ve şimdi o alan yeniden daraldı
- Dinamik dillerin kullanımı ile olgunlaşmamış gözlemlenebilirlik ve feature flag araçlarının bu rol için niş yarattığı da öne sürüldü
- Hacker News üzerinde ise bu teorinin daha sağlam kanıtlara ihtiyaç duyduğu yönünde çeşitli görüşler paylaşıldı
- Bu bakış açısı, kişisel deneyim denilen küçük bir pencereden geliyor; ZIRP öncesi ve sonrası sektörün nasıl olduğu konusundaki genellemeler kişiden kişiye değişebilir
- Bunu test etmek için, 2010 ve 2026 yıllarında kıdemli ve üzeri yüzlerce mühendise haftada kaç kez “olmaz” dedikleri ve bu retlerin ne sıklıkla geri çevrildiği sorulabilir
- Hem ZIRP öncesinde hem sonrasında “olmaz” demek gereklidir; ancak ZIRP sonrasında fark, yönetimin bu yetkinliği hızla içselleştirmesi ve bu sözü onlar adına söyleyecek ayrı bir mühendis grubuna daha az ihtiyaç duymasıdır
1 yorum
Hacker News görüşleri
Kod borçtur. Mühendislerin “hayır” demesi, kod kalitesine öznel biçimde takıntılı olmalarından değil, karmaşıklığı azaltmaya çalıştıklarından kaynaklanır
Bugünlerde yöneticiler “kalite” kelimesini sık sık yanlış anlıyor. Kalite, mühendislik ekibinin koda kolayca ekleme ve değişiklik yapabilmesini de hesaba katarak, ürünü mümkün olduğunca hızlı ve düşük maliyetle üretmek için gereken uygun çaba miktarı demektir
Daha iyi bir açıklama burada: https://www.nair.sh/guides-and-opinions/communicating-your-e...
O kişinin neyi neden yaptığını katı kurallarla yazılı hale getirme girişimleri kaçınılmaz olarak başarısız olur
Bu tür masa başı iktisadının sorunu, her iki yönde de argüman üretilebilmesidir
Buna “sıfır faiz çağının sonu ve sadece-hayır diyen mühendisin yükselişi” de denebilir. Sermaye maliyeti arttığı için şirketlerin o parayı daha akıllıca harcaması gerekir ve gereksiz şeylere saçılmaması için hayır diyebilen mühendislerin muhakemesine daha çok ihtiyaç duyulur
Yazıyı okudukça, “inandırıcı terimlerin hepsi var; ZIRP dönemi, sadece-hayır diyen mühendis falan derken içgörülü görünmeye çalışıyor ama derine indikçe o dönem yazılım mühendisliğinde yaşadığım deneyimle hiç örtüşmüyor ve bugün AI ile yaşanan büyük değişimi de doğru teşhis edemiyor” diye düşündüm. Yani bana moda sözcüklü saçmalık gibi geldi; yazının kendisinde eksi oy düğmesi yok ama topluluğun bunu işaret etmesine sevindim
AI projeleri başarısız olsa bile yeterince hızlı başarısız olup başka bir şeye geçilebildiği sürece sorun olmuyor. Bir şeyi en baştan doğru yapmak ancak başlangıç yatırımı büyük olan uzun vadeli projelerde önem kazanıyor
“Şirketteki mühendislerin yarısının sonsuz değişiklik önerip reddedildiği bir döngüye takılı kalması tamamen sorun değildi. Zaten üretken olmaları gerekmiyordu ve bu yaklaşım işin çekirdek sistemlerini etkilemiyordu” demek, şey, bir bakış açısı. Oldukça alaycı
Geriye dönüp bakınca alaycı geliyor ama o zamanlar aynı olgu kümesini insanların duygularını daha az incitecek şekilde farklı anlatıyorduk
Facebook'ta Metaverse üzerinde çalışan birinin yeni iş modelleri için prototip üreten kilit kişi mi yoksa sadece meşgul görünmesini sağlayan işler yapan biri mi olduğu ancak sonradan anlaşılır
Oldukça uç bir yorum. ZIRP bittiyse ve odak arttıysa doğal sonuç daha az değil, daha çok şeyi reddetmek olmaz mı?
ZIRP'in her türlü sahte iş yarattığını ve bu sahte işleri denetlemek için katmanlar da oluşturduğunu iddia etmek için epey zorlamak gerekir
“Sadece-evet diyen mühendis” ile “sadece-hayır diyen mühendis” ayrımını ve MTBF yerine MTTR'yi önceleyen bakışı beğendim
Ben kesinlikle “sadece-evet” tarafındayım ama kötü mimari seçimlerini sonradan düzeltmek çok acı verici olabilir ve bir özellik, kullanıcı kazandıktan sonra yayına çıkmadan öncesine göre çok daha zor düzeltilir. Bu yüzden biraz da “sadece-hayır”, en azından “önce biraz düşünelim” tarafındayım
“Sadece-evet” ile “sadece-hayır” dengesi büyük ölçüde projeye bağlı. Finans ya da sağlıkta varsayılanın “hayır” olması daha iyi olabilir ama saçma bir startup fikrindeyse YOLO
Toparlamak için zaman istemek aslında hayır demekle aynıdır. Geliştirme sorumlusu bu yetkiye sahip olmalı ve gerçekten kullanmalıdır. Hiç kullanmıyorsa fiilen o yetkiye sahip değil demektir
Alternatif sunmadan sadece “hayır” diyen bir mühendis olunmamalı. Bu iyi mühendislik değil, tembelliğin iyi görünmeye çalışmasıdır
Mühendisler çoğu zaman legacy yüzünden ideal olmasa da gerekli çözümler üretir. Ve hayır, tüm sistemi yeniden yazıp “doğru şekilde” yapmak mümkün değildir. “Hayır” demek ya da çözümün ideal olmadığını işaret etmek sizi süperzeki bir dahi yapmaz
İş tarafındaki insanlarla yapılan toplantılarda, kod yazmayı bildiği için baskın davranıyordu; en kötüsü de bir öneriye katılmadığında hiç alternatif sunmamasıydı. Onunla çalışmak zordu
Bu yazının sözünü ettiği ZIRP insanı o muydu diye düşündüm
LLM ve ajanlarda eksik noktalar varsa, iyileşmeyi beklemek yerine standartları düşürelim diye pazarlayan bir akım var. Mantık “MTTR’ye odaklanın” şeklinde.
Kod kötü mü? Okuma, inceleme yapma, darboğaz oluşturan kişiyi döngüden çıkar. Böyle bir anlatı her yere yayılmış durumda
Bu teknoloji oldukça faydalı, o yüzden sadece semptomları ele almak yerine araçlarla daha iyi çalışmanın yollarına ve buna uygun süreç iyileştirmelerine odaklanılsa iyi olur
Yapılabilecek şeylerin sonu yok ama asıl mesele, zamanı gerçek projelerde kullanmakla bu tür iyileştirmelere ayırmak arasında nasıl paylaştıracağın
“Mühendis sayısı arttıkça hisse fiyatı için daha iyiydi… bankalar faizleri artırınca… hisseyi yukarı taşımak için şişkin mühendis organizasyonlarını elde tutmak artık kârlı olmaktan çıktı” deniyor ama, yazılım mühendisi sayısı ile hisse fiyatı arasında bağlantı kuran bilinen bir mekanizma var mı? Yoksa bu sadece deneyimsel olarak gözlemlenmiş bir olgu mu?
“Eskiden junior bir mühendisin elle yazdığı PR’a hayır demek yeterliydi ama artık AI üretimli kod yağıyor ve bunun bir kısmı, politik olarak reddetmesi zor olan manager ve VP’lerin yaptığı şeyler” denmesi inanılmaz
Büyük bir teknoloji şirketinde çalıştım ama InstructGPT ve benzerleri çıkmadan önce sektörden ayrıldım, dolayısıyla içeride LLM ile kod üretimi deneyimim olmadı. Gerçekten böyle şeyler yaşanıyor mu? Üst düzey yöneticiler ve VP’ler LLM ile üretilmiş kod değişiklikleri mi öneriyor? Ben buna dayanamazdım
Politik yük de gerçek. Ne yaptığını pek bilmeyen ve sorulara da cevap veremeyen birinin açtığı 25 bin satırlık PR’a anlamlı bir inceleme yapmak oldukça zor; ama öylece “olmaz” da diyemiyorsun
Adil olmak gerekirse, şirketin ilk dönemlerinde liquid’i ve Shopify’ın büyük kısmını bizzat inşa etmiş biri, yani deneyimsiz değil; yine de durum bu
Doğrulaması zor bir hipotez gibi görünüyor. Bir şey başarmaya çalışan bir şirket için, hangi kararların uzun vadeli maliyet yaratacağını söyleyip önceliklendirmeye yardımcı olacak birilerinin bulunması gayet mantıklı değil mi?