Çok fazla soyutlama düzeyi kullandık

• Teknoloji sektöründe yalnızca araçları ve otomasyonu kullanmayı öğrenenlerin sayısı arttıkça, alt katmanların nasıl çalıştığını anlama anlamındaki teknik derinlik zayıflıyor
• Soyutlama, direksiyon ya da hidrolik direksiyon gibi işleri kolaylaştırır; ancak arıza veya kesinti olduğunda içeriyi bilen kimse yoksa kurtarma kabiliyeti düşer
• Hızlı yayınlama ve maliyetleri azaltma baskısı, DevOps ve DevSecOps gibi birden çok rolü tek bir kişinin üzerine yıkar; bu da daha fazla otomasyona ve daha az derin anlayışa yol açar
• Güvenlik alanında, GUI tabanlı sızma testi araçlarının yeşil ışığına güvenilirken gerçek bir ihlal uzun süre fark edilmeyebilir
• Teknoloji öğrenenler yalnızca akımların peşinden gitmek yerine araçların kendi yerlerine yaptığı işleri bizzat denemeli, kodu ve alt katmanları kurcalayan mühendis tavrını korumalıdır

---

Soyutlamanın örttüğü teknik anlayış boşluğu

• Günümüzde birçok “uzman”, araçları nasıl yapılandıracağını biliyor; ancak teknolojinin daha derin katmanlarda nasıl çalıştığını anlamıyor
• Soyutlamanın kendisi gereklidir
  • Direksiyon, otomobil kullanmayı kolaylaştıran bir soyutlamadır
  • Hidrolik direksiyon, sürüş deneyimini daha da iyileştiren başka bir soyutlamadır
• Sorun, soyutlama bozulduğunda ortaya çıkar
  • İçteki teknolojiyi anlayan kimse yoksa arızalı katmanı onarmak zorlaşır
  • Araç normal görünse bile sistemin gerçek durumu değerlendirilemeyebilir
• Teknoloji sektörü kâr ve piyasaya çıkış hızı baskısıyla güçlü biçimde hareket eder
  • Bunun sonucunda daha fazla soyutlama ve otomasyon devreye girer
  • Daha az kişi daha fazla iş üstlenir
  • Derin anlayıştan çok belirli araçları kullanma bilgisi vurgulanır
• Geleneksel programcı ve sistem yöneticisi rolleri, DevOps ve DevSecOps gibi geliştirme, güvenlik ve operasyonu tek bir kişinin görev tanımına koyan bir yöne evrilmiştir
  • Bir kişinin geliştirme, güvenlik ve sistem yönetiminin tamamında tam yetkinleşmesi zor olduğu için mümkün olduğunca çok iş otomatikleştirilir
  • Sonuç olarak modern teknoloji çalışanları belirli araçları kullanmayı öğrenir, ancak içteki teknolojiyi neredeyse hiç bilmiyor olabilir

Teknoloji öğrenenler için gerekli tutum

• Modern yaşam teknolojiye büyük ölçüde bağımlıdır; ancak teknolojinin kendisini anlamak giderek zorlaşmaktadır
• Güvenlik alanında da yalnızca hazır sızma testi araçlarını kullanmayı bilen, güvenliğin kendisini ise iyi bilmeyen çok kişi olduğuna yönelik bir eleştiri vardır
  • Aracın web GUI’sinde yeşil ışık gösteriliyorsa her şeyin yolunda olduğu varsayılabilir
  • Gerçek bir saldırgan sistemi çoktan ele geçirip verileri darknet üzerinde satıyor olsa bile, sızıntı veya ihlal fark edilmeyebilir
• Bazı öğrencilerin dosya ve klasör kavramlarını bile bilmediğine dair örnek olarak bir Slashdot haberi bağlantılanmıştır
• Teknoloji öğrenenler için gerekli pratikler şunlardır
  • Yalnızca popüler akımların veya trendlerin peşinden gitmemek
  • Sadece araçları öğrenmek yerine temel teknolojinin nasıl çalıştığını anlamak
  • Mümkünse yapılandırma aracının kendi yerine yaptığı işi en az bir kez elle yapmak
  • Mümkünse aracın koduna bakmak
  • Öğrenmeye ve denemeye devam etmek, ilgi duyulan teknolojinin daha derinine inmek
  • Mümkünse bir homelab kurup onu öğrenmek ve bozmak için bir oyun alanı olarak kullanmak
  • Anlaşılmayan şeyleri sormak ve birilerinin daha iyi bildiğini varsayılan değer gibi kabul etmemek
• Bu, herkesin her şeyi ilk ilkelerden başlayarak anlaması gerektiği ya da araç kullanmaması gerektiği anlamına gelmez
  • Soyutlama gereklidir
  • Kamyon şoförünün sürmesi, tamircinin kamyonu onarması gibi uzmanlık alanları vardır
• Temel sorun, teknolojiyle çalışan kişilerin sahip olması gereken mühendislik tavrının zayıflamasıdır
  • Yazılım geliştirmede çok fazla uzman rolü araçlar ve otomasyon tarafından ikame edilmektedir
  • Giderek daha az kişi, üzerinde çalıştığı katmanın hemen altındaki katmanı bile anlamaktadır
  • Bir web geliştiricisi TCP/IP, DNS, HTTP, TLS ve güvenlik bilgisi olmadan yalnızca hazır araçlar veya framework’lerle site yapıyorsa, sorun çıktığında yararlılığı büyük ölçüde azalır

[GN⁺]

Hacker News yorumları

• Havacılık tarihinde, uçağı kullanabilen birinin aynı zamanda onu tasarlayıp üretebildiği bir dönem de vardı; o zaman da makinenin birinci ilkelerini gerçekten anlamayan insanların kokpite oturacağı bir gelecekten endişe edilip edilmediğini merak ediyorum
  Bugün pilotluk ile üretim/tasarımın ayrı beceriler ve meslekler olduğu fikrine alıştık; ayrıca bir havacılık mühendisinin boksit madenciliğini ya da alüminyum ergitmeyi bilmek zorunda olmamasını da doğal karşılıyoruz
  Mantık kapılarından web isteklerine kadar tüm yolu gözden geçirebilmek güven verici olabilir, ama şart değil. Böyle bir genel bakışa sahip mühendislerin azalması bir alarm işaretinden çok, teknoloji sektörünün olgunlaşmasını ve alanların ayrışmasını gösteren bir olguya benziyor

  • Asıl sorun, teknolojinin gerçekten anlayış olmadan da işletilebilecek kadar yeterince iyi ve güvenilir hale gelmesinin çok uzun sürmesi
    Örneğin “hep birlikte assembly’ye dönelim” türü söylemlerde, yüksek seviyeli diller ana akım olduktan sonra bile programcıların epey uzun süre assembly bilmesi gerekiyordu. Çünkü derleyici ve hata ayıklama araçlarının soyutlamaları sızdırıyordu
    Bugünün sorunu ise, olgunlaşması için zaman tanımadan sızdıran soyutlamaları katman katman yığmamız. Geliştiricilerin hep mutlu yolda kalacağı gibi yanlış bir varsayımla çalışma süresini kısaltmaya odaklanıyoruz; ama gerçekte zamanın çoğu, işlerin tasarlandığı gibi gitmediği durumları debug etmekle geçiyor. Mutlu yolu hızlandırırken mutsuz yolu yavaşlatırsanız, sonuç genelde net kayıp olur
  • “Bir gün yıldızlar, kendi evlerine giden yolun işaretleri, virajları ve tepeleri kadar tanıdık olacak; ve bir gün bu, havadaki yaşam olacak. Ama o zamana gelindiğinde insanlar uçmayı unutmuş olacak. Dikkatle terfi ettirilmiş, etiketli düğmelere alışsın diye eğitilmiş bir sürücünün kullandığı makinenin yolcuları olacaklar; ve göğün, rüzgârın ve havanın yollarına dair bilgi, zihinlerinde gelip geçen bir kurgu kadar gereksiz hale gelecek.” — Beryl Markham, West with the Night, 1942
  • Air France 447’nin yardımcı pilotu bu tasvire uyuyor gibi görünüyor. Mümkün olan en kısa sürede yüksek derecede otomasyonlu Airbus tiplerini uçurmaya başlamıştı ve diğer tiplerde sadece 250 saat deneyimi vardı
    Airbus otomasyonu, çok ciddi bir şey ters gidip sistem manuel yasalara dönmedikçe stall olmayı neredeyse imkânsız kıldığı için, stallın nasıl çalıştığını gerçekten anlamıyordu. O uçuşta tam da bu yaşandı; kaptan kokpite geri döndüğünde derin stall’u hemen fark etti, ama artık çok geçti
    İlgili Mentour Pilot videosu: https://invidious.protokolla.fi/watch?v=e5AGHEUxLME&t=1
  • Bence bu benzetmede birkaç sorun var. Asıl metnin gerçekten birinci ilkeler düzeyinde bir anlayış gerektirip gerektirmediği de net değil; ayrıca üniversitedeki herkesin uçuş bilgisine ya da bizzat uçurma becerisine sahip olması da gerekmiyor, üstelik uçmanın alternatifleri de var
    Uçuş sürecinin baştan beri fiziksel sınırları vardı; ama bilişim ve onu düşünme çerçeveleri sonsuz derecede değişken ve uygulama alanı çok geniş. Bugün satılan saçmalıkları havacılık benzetmesine çevirirsek, uçuş diye eşeğe binmeyi satmaya daha yakın. Müşterilerin önemli bir kısmı aradaki farkı ayırt edecek bilgiye sahip değil
    İlerleme için önemli olan şu: Bir şeyi nasıl basitleştireceğimizi gerçekten öğrendiğimizde, ancak o temel üzerinde büyük sıçramalar yapabiliyoruz. Fazla karmaşık hale geldiğinde, gidebileceğiniz mesafe ve ulaşabileceğiniz yükseklik sınırlanıyor. Bu, teknik borcun insanlık ölçeğine büyütülmüş hali gibi
    Ne yazık ki tarihte bir şeyin bir kademe daha basitleştiği anı pek fark etmiyoruz. Geriye bakınca doğal ve kaçınılmaz görünmesi yüzünden
  • Eğer pilot, uçak bakım teknisyeni ve havacılık mühendisinin unvanları ile iş tanımları birbirine fazla benziyor ve ayırt etmek zorlaşıyorsa, bu gerçekten kaygı verici olabilir

• Bugünün çocukları bence yeterince takdir edilmiyor. Birkaç hafta önce bir arkadaşımın oğlu, arkadaşlarıyla birlikte yaptığı Roblox oyununu büyük bir heyecanla göstermişti
  Kanada Şükran Günü olduğu için aileden ve tanıdıklardan çok kişi vardı; o da kimin hangi kısmı ilginç bulacağını önceden belirlemişti ve ben “Lua gösterilecek kişi”ydim
  İnsanlar telefonların ve dizüstü bilgisayarların kapalı kutu gibi olması yüzünden merak uyandırmadığını görüp çocukların da öyle olacağını düşünüyor; ama bence asıl daha az meraklı hale gelenler yetişkinler
  Elbette bu da soyutlamaların üzerine kurulmuş durumda; ama yüksek soyutlama dağlarının arasında, meraklı küçük bir azınlığın girip dolaştığı vadiler hep vardı. C64 BASIC size herhangi bir bellek adresine POKE yapma imkânı veriyordu; ama 10 yaşındaki bir çocuktan FPS öğeleri olan karmaşık bir 3D koleksiyon oyununu dinlemek de oldukça harika bir şey

  • Oyun geliştirmenin, programlama ve genel olarak yazılım geliştirmeye açılan değeri bilinmeyen bir giriş kapısı olduğunu düşünüyorum. Benim için de işe yaramıştı
  • Roblox şirketin kontrol ettiği kapalı bir ekosistem olsa da, programlama yapılabilmesi ve hatta HTTP istekleri atılabilmesi kadar açık; bu yüzden kötü bir örnek saymak zor

• Biraz bulutlara bağıran yaşlı adam havası veriyor
  Bazı insanların uzman, bazılarının ise ancak idare eder seviyede olması yeni bir şey değil. Bu kısa yazının yarısını kendini övmeye ayıran yazarın ima ettiği gibi herkes kurtarıcı olamaz
  Bu yazının soyutlama ile neredeyse hiç ilgisi yok. Yazar ilk iki paragraftan sonra kendi tezine olan ilgisini kaybediyor

  • O sitedeki yazılar genelde böyle oluyor ve arada bir ana sayfaya çıkıyor. Duygusal olarak yankı bulan çok nokta var ama yazar neredeyse her zaman “en zeki benim ve bunun iyi olmadığını düşünüyorum” seviyesinin ötesine geçen bir argüman kuramıyor
  • En azından somut örnekler ya da belirli vakalar bekliyordum ama hiçbir şey yoktu. “Bulutlara bağıran yaşlı adam” yazıları bile örnek ya da elle tutulur içerik taşıyınca bir şeyler öğretebilir; ama bu durumda tüm yazı kötü bir HN yorumu gibi geliyor
  • Bende de benzer bir his bıraktı. Bu yazının nasıl üst sıralara çıktığını anlamadım
    Verdiği örnekler de çok zayıf. “Biri modern bir framework kullandı ve hacklendi; performans sorunu hacklenme yüzünden değil, framework korkunç derecede yavaş olduğu içindi” deniyor ama hangi framework olduğu, sadece diff’e bakarak bunun nasıl anlaşıldığı ya da araçları performansa uygun hale getirememekle soyutlamanın ne ilgisi olduğu belirsiz

• Bir diğer sorun da, birçok kez yanlış soyutlamaları benimsemiş olmamız. Bugünün yazılım sektöründe, tarihin son durağına gelinip her şeyin çözüldüğüne inanan kibirli bir tek kültür var
  Oysa gerçekte, yakın dönem teknolojilerin önemli bir kısmında yanlış yola sapıldığını düşünüyorum. 2014 civarına kadar her şey doğru yönde gidiyor gibiydi, ama sonrasında ilerleme geri sardı ve herkes aynı abartılmış framework'leri kullanmaya başladı gibi geliyor. Şirketler bunları herkese dayatınca yazılım geliştirme verimsiz ve heves kırıcı bir işe dönüştü
  Kişisel projelerimde kullandığım bir SDK yaptım; işte kullandığım ana akım framework'lerden en az 10 kat daha üretken, ayrıca kodu da çok daha okunabilir ve bakımı kolay. Framework'ü bilmeyen bir junior'a bile göstersem üretken çalışabilecek düzeyde. Bu SDK ile no-code bir BaaS platformunu part-time 2 ayda yaptım; ana akım araçlar ve framework'lerle bunu benim ya da başka birinin full-time 12 ay içinde yapması bile zor olurdu diye düşünüyorum

  • Muhtemelen o framework'ün üretken olmasının nedeni, kullanılabilecek en iyi framework olması değil; onu kendim yapmış olmam, iç işleyişini iyi bilmem ve düşünme biçimime iyi uyması
    Elbette başka framework'lere göre daha iyi yanları olabilir, ama aşinalık uzmanlık yaratır ve uzmanlık da üretkenlik sağlar
    Alçıpan vidası yaygınlaşmadan önce birçok usta, vidanın daha yavaş ve daha kötü olduğuna emindi; ama hem çivi çakmada uzman biri hem de vidalama uzmanı işi hızlı ve iyi bitirir
  • “Şirketler bu framework'leri herkese dayatıyor” sözüne gelirsek, şirketler insanlardan oluşur ve karar vericilerin bağlam ve bilgiyle doğru kararları vermesi beklenir
    İster frontend ister backend olsun, bu “framework'leri” kullanmamızın sebepleri var. Bu sebepleri beğenmeyebilirsiniz, ama kurumsal programlamada dilin saflığından çok işe alım kolaylığı, bakım yapılabilirlik, süreklilik gibi para kazandıran unsurlar önemlidir
    Şirket sizin özel SDK'nızı kullanırken siz ayrılırsanız ne olacak? Bunu başkalarına kolayca öğretebileceğinizi düşünebilirsiniz, ama şirketlerin teknik kararlarında bundan çok daha fazla unsur vardır
  • O SDK'yı merak ettim. Herkese açık olarak barındırıyor musunuz; değilse en azından sizin yaklaşımınızla ana akım framework'ler arasındaki farkı anlatabilir misiniz?

• “Bugün sözde uzmanların çoğu, sadece hangi moda aracın nasıl kurulacağını biliyor; ama işlerin daha derin düzeyde nasıl çalıştığını hiç anlamıyor” sözü bana çok dokundu
  Herkes “X yapmak için yapılandırma dosyasına şu satırı ekleyin” gibi ezbere dayalı prosedürleri biliyor, ama X'ten biraz farklı bir şeyi ya da X'in bir varyasyonunu yapmak gerektiğinde senaryonun dışına çıkmayı bilmiyor. Daha kötüsü, insanlar sohbeti not-quite-X'ten tekrar X'e çevirmeye çalışarak zaman kaybettiriyor. Bu bana kaybolan cüzdanı sadece sokak lambasının altında arama benzetmesini hatırlatıyor

• Çok dar bir bilgiyle bile katkı sunulabilen bir teknoloji ekosistemi, bir tür “techosystem”, oluşturmuş olmamızın harika olduğunu düşünüyorum. Daha az olumlu söylersek, bu aynı zamanda şirketlerin daha az teknik bilgi gerektiren daha ucuz işgücünü işe alabilmesi demek
  Çoğu durumda vasat bir çözümün, hiç çözüm olmamasından daha iyi olduğuna inanıyorum. 1995~2005 interneti vasat çözümler üzerine kuruluydu ve gerçekten çok eğlenceliydi
  Derine inen uzmanlar ne yok olan bir türdür ne de soyutlama öncesi çağın gizli bilgisine sahip kıt bir kaynaktır. Aksine, bugün her zamankinden daha fazlalar. Bunlar, stack'in üstünü ve altını da yapmış olmalarıyla değil, kendi katmanlarının dışına bakma meraklarıyla tanımlanır
  Çünkü sadece üst tarafa soyutlama katmanları eklenmiyor; alt katmanlar da NVMe, WebGPU, WebAssembly, QUIC, AVX512 gibi şeylerle değişiyor
  Yine de derine inen uzman, ekiplerin çoğu için gereksiz bir lükstür ve bir teknoloji yöneticisinin en önemli becerilerinden biri, böyle birini ne zaman mutlaka işe alması gerektiğini bilmektir

• Soyutlama seviyesinin artması gerekli. İnsan beyni yıllar geçtikçe çok daha yetkin hale gelmiyor, ama kullanılabilir araçların sayısı artıyor; dolayısıyla odaklanabilmek için soyutlamaya ihtiyaç var
  Bunun geleceğin karanlık olduğu anlamına geldiğini düşünmüyorum. İş problemleriyle uğraşan bir programcı; EUV, compiler, assembly, instruction set, kernel, USB protokolleri, HTTP, die, PCB gibi konuları bilmeden de yüksek seviyeli bir dilde çok üretken olabilir. Pilotların da aerodinamik, çekme dayanımı, alüminyum, kauçuk, GPS gibi her şeyi bilmesi gerekmez
  Yine de modern toplumdaki teşvik uyumsuzluğu yeterince tartışılmayı hak ediyor. Pilotlara, iş yazılımı geliştiricilerine, araştırmacılara ya da bankacılara duyduğum güvenden genel olarak daha çok güveniyorum. Çünkü uçak düşerse pilot olay yerine ilk varan kişi olur

• Mancınık yazılımı, sahip olduğunuz malikâne sayısı gibi şeyleri gösteren aşırı genel CRUD uygulamalarından farklı bir yaklaşım gerektirir
  Dünyada çok fazla aptal yazılım var ve bu sorun değil. Birçok “gerçek problem” de epey aptal ve kahramanca mühendislik gerektirmiyor
  Korkutucu derecede çok durumda, alelacele birleştirilmiş özensiz yazılım bile yeterli oluyor
  Bundan hoşlanmıyorum ama ya kendi üstün mühendisliğimle bir iş kurup rekabette kazanarak onların haksız olduğunu kanıtlamam ya da sadece bulutlara bağırdığımı kabul etmem gerektiğini düşünüyorum

  • Mancınık yazılımının önemli bir kısmı da, daha önce söylendiği gibi, kaynak yönetimi ya da birim testleri olmadan alelacele yapılıyor
    Hastaneler satın alma kararı verirken, “bu düğmeye basılmıyor” seviyesinin biraz üstü dışında yazılım kalitesini pek doğrulamıyor

• Soyutlamayı eleştiren yazının, “Bugünün öğrencileri arasında dosya ve klasörün ne olduğunu bile bilmeyenler var” cümlesine hyperlink vermiş olması tuhaf biçimde yerinde
  O bağlantı bir Slashdot başlığına gidiyor, oradan bir PC Gamer yazısına, o yazı bir Verge yazısını yeniden anlatarak bağlantılıyor, Verge yazısı da bir Stack Exchange sorusuna çıkıyor

• Başka bir deyişle bu, cargo cult programlama. Bunun hakkında 2 yıl önce yazmıştım [1] ve tepkiler ya tamamen katılanlar ya da bunu şiddetle gatekeeping diye saldıranlar olarak ikiye bölünmüştü
  Keşke sevdikleri teknolojiye derinden yatırım yapmış mühendislerin mesleki bağışıklık sistemini tetiklemeden bu hastalığı iyileştirmenin daha iyi bir yolu olsa
  [1] https://medium.com/the-engineering-manager-guide/cargo-cult-...

  • Bence “react expert”, “node expert” gibi ifadeleri tırnak içine almasıyla bu zaten ortaya çıkıyordu. Rolünü, onların gerçekten uzman olmadığını ortaya koymak olarak gördüğü oldukça açıktı
    İki kişi de soruyu anlamadı ama o ne soruyu netleştirdi ne de sorunun kendisinde bir problem olabileceğini düşündü
    “React.js uzmanından doğrudan DOM manipülasyonu, MVC tabanlı istemci tarafı şablonlama, bileşen tabanlı DOM manipülasyonu ve vanilla JS’ye compile etme gibi çeşitli SPA yaklaşımlarını karşılaştırmasını istedim” cümlesinin ben de dürüst olmak gerekirse ne anlama geldiğini bilmiyorum
    “vanilla JS’ye compile etme”nin TypeScript’i JavaScript’e compile etmek anlamına gelip gelmediğini, bunun DOM’la ne ilgisi olduğunu bilmiyorum. “MVC tabanlı bileşen tabanlı DOM manipülasyonu” da tuhaf. Geliştirmeyi daha derin anlayan biri gibi değil, bir tasarım desenleri kitabı okuyup kendisiyle aynı terminolojiyi kullanmayanlara eksi puan veren biri gibi geliyor
  • O yazıda sorulan sorular iyiydi. Yine de insanların kendi becerileriyle, işleriyle ve başarılarıyla gurur duymasının nadirleşmesiyle temel bir şeyi kaybedip kaybetmediğimize üzülüyorum
    İşini iyi yaptığında duyduğu tatmini gerçekten seven biri, bence genelde sadece işi bitirmek isteyen birine göre bir şeyi gerçekten anlamaya daha fazla zaman harcar
    Ama bu merak bize ne kazandırıyor? fortune(6) içindeki şu anekdotu hatırlıyorum ve meraksız insanların içinden kaçının bunu anlayacağını merak ediyorum
    Bir acemi, bozuk bir Lisp makinesini kapatıp açarak tamir etmeye çalıştı. Knight bunu görünce sertçe şöyle dedi: “Neyin yanlış olduğunu anlamadan makineyi sadece kapatıp açarak tamir edemezsin.” Knight makineyi kapatıp açtı. Makine çalıştı
  • Gatekeeping kavramının gerçekten zararlı olduğunu düşünüyorum. Bu suçlama her kullanıldığında, neredeyse her zaman gatekeeping’in zaten kötü olduğuna dair örtük bir varsayım taşıyor
    “Gatekeeping yapıyorsun, o yüzden ben kazandım” türünden bir koz olarak kullanılıyor; bu saçma bir düşünce. Yüksek uzmanlık standartlarını savunmakta yanlış bir şey yok ve bu özünde gatekeeping’dir. Doktora gittiğimde, tıbbın gatekeeping uygulanan bir meslek olmasından son derece memnunum
  • Olumsuz tepkinin neden geldiğini anlamak için blog yazısını okuyup baktım ama metin savaşçı ve kibirli hissettiriyor. Sanki insanlara ayrıntılar üzerinden quiz yapıp kendisinin daha çok bildiğini göstermeye çalışıyor gibi