Anlamanın Neşesi ve Gücü

 (binaryigor.com)
3 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yazılımı derinlemesine anlamak, araçların peşinden sürüklenmek yerine sorumluluğunu taşıdığınız sistem üzerinde kontrol ve sahiplik kurmanızı sağlar
  • Arama ve LLM'ler hızlı yanıtlar verir, ancak açıklayamadığınız çözümleri kopyalama alışkanlığı hata düzeltme becerisini ve temel yetkinliği zayıflatabilir
  • Tek seferlik script'lerde veya düşük riskli iç UI'larda üretme/kopyala-yapıştır makul olabilir, ancak uzun süre bakım yapılacak kod derinlemesine bildiğiniz teknolojiyle yazılmalıdır
  • Üretkenliği yalnızca kod satırı ya da PR sayısı gibi output ile ölçmek kolayca çarpıtılabilir; istikrarlı release'ler, sadeleştirme, otomasyon ve test gibi outcome'lar uzun vadeli değere daha yakındır
  • Modern yazılım; runtime, ağ, güvenlik, veritabanı ve yapay zekaya kadar karmaşık hale geldi, ancak temel ilkeleri öğrenirseniz yeni araçları ve yaklaşımları daha hızlı anlayabilirsiniz

Anlamanın sağladığı kontrol ve keyif

  • Derin anlayış, kodu ve sistemleri düzeltip değiştirebilmek için fiilî bir koşuldur
  • Anlamadığınız bir şeyi düzeltmek veya değiştirmek zordur; sonuçta sorumluluğunu taşıdığınız kod üzerindeki kontrol ve sahiplik de zayıflar
  • Anlamak yalnızca araçların efendisi olmanızı sağlamaz, psikolojik olarak da tatmin verir
  • Çevrenizi daha iyi kontrol etmenizi sağlayan davranışların olumlu duygularla bağlantılı olması doğal görülebilir

İnsan tembelliği ve LLM bağımlılığı

  • İnsanlar enerji kullanımını azaltma ve yatırım karşılığında alınan ödülü artırma eğilimindedir
  • Bu tembellik, sıkıcı ve maliyetli işleri otomatikleştirme motivasyonu olabilir; ancak öğrenme ve ustalaşma açısından zayıflık haline gelebilir
  • İnternet ve LLM'ler sayesinde benzer problemlerin cevaplarını istediğiniz biçimde kolayca alabiliyorsunuz; bu da anlama sürecini atlamayı kolaylaştırıyor
  • SQL'i doğrudan öğrenmek yerine tabloları ve istediğiniz veriyi LLM'e söyleyip sonucu kopyalamak kısa vadede kolaydır, ama onu gerçekten kullanma becerisi birikmez
  • LLM SQL'i daha hızlı üretiyor olsa bile, geçmişte doğrudan tekrar ederek geliştirdiğiniz okuma ve anlama becerisi kullanılmadığında körelir
  • LLM'ler ve arama motorları en iyi durumda bir yetenek çarpanı (force multiplier) olabilir, ancak bunun için önce güçlü temeller gerekir
  • Temel beceri ve bilgi; yalnızca arama, prompt yazma ve manuel doğrulamayla korunamaz, doğrudan inşa etme ve üretme sürecine katılmak gerekir
  • Düzenli olarak tembel eğiliminize karşı çıkmalı; dokümanları ve kaynak kodu okumalı, çözümlerin nedenlerini ve araçların trade-off'larını anlamalı, çözümleri ve algoritmaları bizzat tasarlamalısınız

Kısa vadeli üretkenlik ile uzun vadeli anlayış arasında denge

  • Her kodu ve her çözümü tamamen anlamak zorunda değilsiniz; bağlama göre ölçütleri değiştirebilirsiniz
  • Önemi ve riski düşük tek seferlik script'ler kopyalanabilir ya da üretilebilir
  • İki üç kişinin kullandığı iç UI'lar veya sayfalar için de aynı yaklaşım kabul edilebilir
  • Aylarca ya da yıllarca sahiplenip bakımını yapacağınız ve evrimleştireceğiniz kod, derinlemesine bildiğiniz dil ve teknolojilerle yazılmalıdır
    • Her satırı, kelimeyi, karakteri ve yapılandırma seçeneğini anlayabiliyor olmalı ya da o yöne gitmelisiniz
    • Şu anda çok sayıda çıktı üretmektense uzun vadeli anlayışı, bakım yapılabilirliği ve üretkenliği optimize etmelisiniz
  • MVP'ler veya mevcut ürün içindeki deneysel özellikler gibi, başarı ihtimalinin belirsiz olduğu durumlarda kalite ve anlama standardı biraz düşürülebilir
  • Bu tür seçimler, bilişsel borç almak gibidir
    • Şimdi daha hızlı hareket edebilirsiniz
    • Ama ürün ya da özellik çalışır hale geldiğinde veya düzeltme/değişiklik gerektiğinde, bedelini sonra daha fazla ödersiniz
  • Yine de en azından güvenle “çalışıyor” diyebilecek kadar anlamalı ve doğrulamalısınız
  • Bazı durumlarda önce üretip sonra doğrulamak ve en baştan yeniden yazmak makul bir strateji olabilir

Teknoloji yığını ve ustalaşmanın bileşik etkisi

  • Nadiren kullandığınız bir programlama dili, kütüphane veya araç için derin öğrenmeye ve ustalaşmaya çok zaman ayırmanız gerekmez
  • Sonucu doğrulayabiliyorsanız, kısmen anladığınız şeyleri kopyalayıp üretme yaklaşımı bazen kabul edilebilir
  • Ancak öğrenme ve zorlanma aşamasını atlarsanız, o teknolojide ustalaşma ve onu verimli kullanma ihtimalinizi kendiniz azaltırsınız
  • Düzenli kullandığınız temel teknoloji yığınında ustalık, yüzlerce hatta binlerce kat karşılık verebilir
  • Bilgi ve beceri bileşik etkiye sahiptir
    • Ne kadar çok bilirseniz, kendi başınıza o kadar hızlı üretebilirsiniz
    • Yeni bilgi ve becerileri de giderek daha hızlı edinebilirsiniz
    • Yetkinliğiniz arttıkça yeni çözümler ve fikirler geliştirebilirsiniz

Output yerine Outcome odaklı üretkenlik

  • Üretkenliği anlama ve ölçme biçimleri genel olarak output odaklı ve outcome odaklı diye ayrılır
  • Output ölçümü kolaydır ve sayılarla ifade edilmesi rahattır
    • Üretilen kod satırı sayısı
    • Açılan ve merge edilen PR sayısı
    • Uygulanan özellik sayısı
    • Bulunup düzeltilen bug sayısı
    • Tamamlanan iş sayısı
  • Output odaklı metrikler kolayca manipüle edilebilir
    • Gereksiz derecede uzun kod yazılabilir
    • Çok sayıda küçük PR oluşturulabilir
    • İşler yapay olarak bölünebilir
    • Kullanışsız özellikler eklenebilir
  • Sayıların artması, doğru yöne gidildiğini garanti etmez
    • PR sayısının fazla olması mutlaka iyi değildir
    • Kod tabanının büyümesi her zaman arzu edilen bir şey değildir
    • Özellik eklemek yerine kullanılmayan özellikleri kaldırmak daha iyi olabilir
  • Outcome odaklı örnekler, uzun vadeli değerle daha doğrudan ilişkilidir
    • Yeni bir CI/CD süreciyle production release'leri daha istikrarlı hale gelir
    • Refactoring ve sadeleştirme sayesinde bakım ve gelecekteki değişiklikler kolaylaşır
    • Entegrasyon çözümünün yeniden tasarlanması, yeni partner eklemeyi hızlandırır ve işlem kaynaklarından tasarruf sağlar
    • Testleri artırarak bug'ları önceden yakalar ve regresyonları önlersiniz
    • Metrikler ve alarmlar ekleyerek potansiyel sorunları ve bug'ları proaktif biçimde tespit edersiniz
    • Sıkıcı manuel işleri otomatikleştirerek zaman kazandırır ve kritik hata olasılığını azaltırsınız
  • Uzun vadeli üretkenlik ve anlayış, outcome odaklı metriklerle daha iyi örtüşür; daha fazla output her zaman daha iyi anlamına gelmez

Karmaşıklaşan yazılım ve temel ilkeler

  • Yazılım mühendisliğinin temel teoremi şu cümleyle özetlenir: “Bilgisayar bilimindeki her problem başka bir dolaylı katmanla çözülebilir; ancak çok fazla dolaylı katman problemi bunun istisnasıdır”
  • Modern yazılım geliştirme, birçok katman ve unsur nedeniyle son derece karmaşıktır
    • Runtime ve platformlar: tarayıcı, sunucu, bulut, mobil, masaüstü, gömülü
    • Ağ: HTTP, DNS, TLS, TCP, UDP, IP, WebSockets, WebRTC, veritabanı ve mesaj aracılarının protokolleri
    • Güvenlik, authentication, authorization
    • İşletim sistemi
    • Sanallaştırma, containerization, Kubernetes türü orkestrasyon
    • Veritabanları: SQL, NoSQL, yerel, uzak, dağıtık
    • Yüksek seviyeli programlama dilleri ve compiler/interpreter/transpiler pipeline'ları
    • Kütüphaneler, framework'ler, paket yöneticileri
    • API'ler ve harici servisler
    • CI/CD, TDD, BDD, GitOps, IaC, DDD, EDA, Event Sourcing, CQRS, SSR, CSR, Clean Architecture, Hexagonal Architecture, Modular Monolith, Microservices, Microfrontends
    • LLM'ler ve yapay zeka
  • Bu karmaşıklıkla başa çıkabilmemizin nedenleri de var
    • Birçok sistem aşırı tasarlanmıştır ve önemli ölçüde sadeleştirilebilir
    • Belli bir dönemde genelde yazılım geliştirme alanının yalnızca küçük bir bölümünde uzmanlaşmak yeterlidir
    • Kalanı için farkındalık düzeyi çoğu zaman yeterlidir
    • Araçların arkasındaki genel örüntüleri ve ilkeleri öğrenmek, yeni araçları/yaklaşımları/teknolojileri öğrenmede kaldıraç etkisi yaratır

Temel ilkelerin kapsamı ve etkisi

  • Temel ilkeler, yazılım geliştirmede kullanılan araçların, kütüphanelerin, framework'lerin, protokollerin ve bileşenlerin altında yatan; fazla değişmeyen temel kurallar, kısıtlar ve mekanizmalardır
  • Temel kapsam birçok alanı içerir
    • Bilgisayar mimarisi ve donanım: CPU yapısı, komut yürütme, bellek hiyerarşisi, register'lar, cache, depolama aygıtları
    • Makine dili, assembly, yüksek seviyeli diller: assembler, compiler ve interpreter'ların neden gerekli olduğu ve dil türlerine göre trade-off'lar
    • İşletim sistemi: process, thread, scheduling, lock'lar, senkronizasyon, sanal bellek, dosya sistemleri, IPC, system call, I/O
    • Algoritmalar, veri yapıları, karmaşıklık analizi
    • Ağ: bilgisayarlar arası iletişim, güvenilirlik, throughput, latency, katmanlı yapı
    • Veritabanları ve veri sistemleri: ACID, transaction'lar, isolation level'lar, index'ler, saklama biçimi, ilişkiler, veri modelleme
    • Yazılım tasarımı ve mimarisi: modülerlik, bağımlılık ve sorumluluk yönetimi, information hiding, encapsulation, katmanlar, istemci-sunucu, event'ler, coupling ve cohesion
    • Durum ve veri akışı: kimlik, tek doğru kaynak, çakışma çözümü, cache ve memoization, durum geçersizleştirme, state machine, tutarlılık ve senkronizasyon
    • Dağıtık sistemler: CAP teoremi, replikasyon, gecikme, partition, consensus, service discovery, eventual consistency
    • Eşzamanlılık ve paralellik: lock'lar, senkronizasyon, paralelleştirilebilirlik, race condition, deadlock
  • Her alanda ustalaşmanız gerekmez; hatta bu mümkün de olmayabilir. Ama her alandan biraz bilmek ve seçtiğiniz birkaç alanda üstünleşmek hedeflenmelidir
  • Temel ilkelere odaklandığınızda zamanla evrensel sezgi diyebileceğimiz bir meta beceri oluşur
  • Hesaplamanın ve bilgisayarların tek başına ya da cluster içinde nasıl çalıştığını derinlemesine anlarsanız, sürekli değişen araç ve framework ayrıntılarından daha az etkilenirsiniz
  • Bu seviyeye geldiğinizde yeni moda araçları öğrenmek de çok daha kolaylaşır

Anlamanın neşesi ve etkisi

  • Leonardo da Vinci'nin dediği gibi, “En asil haz, anlamanın neşesidir”
  • Yazılım geliştirmede anlamak yalnızca keyif değil, aynı zamanda pratik etki ve güç sağlar
  • Yazılım mühendisliğinin kapsamı çok geniştir, ancak temel ilkelere odaklanırsanız hâkim olabildiğiniz alan büyür
  • Mevcut bilişsel sınırlarınızı sürekli zorlayan bir tutum, düzenli bir neşe ve artan etki alanına yol açar

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Lobste.rs görüşleri

  • Bu blog yazısının genel tonunu gerçekten çok sevdim
    Son zamanlarda her yerde “içinde neler olup bittiğini bile bilmeden bir araç yaptım” türü yazıları fazla sık görmeye başladım ve bunun övünülecek bir şey gibi sunulmasından yoruldum

    • Aynen. Derin anlayış gerçek avantajı yaratır ve yeni fikirler ile içgörülere yol açar
      Üstelik sürecin kendisi de son derece keyifli

  • İlginç bir yazıydı ve insanların anlamadıkları çıktılar üretmeye itilmesi yönündeki akımın bir ölçüde kasıtlı olduğunu düşünüyorum
    Yapay zeka laboratuvarları açısından da bunun açık ekonomik nedenleri var. İnsanların kendi ürünlerine bağımlı hale gelmesi, değerlemelerini haklı çıkarmaya başlamalarının bir yolu ve kullanıcıların yetkinliğini zayıflatmak da bunun yöntemlerinden biri
    Tam da bugün benzer bir yazı yazdım; bir şeyi gerçekten öğrenip ustalaşmanın keyfi gibi aynı temel öncülü paylaşıyor: https://hgrsd.nl/blog/simplicity-agency-and-mastery/

    • Yazıyı paylaştığın için teşekkürler. Özellikle özne olma gücü ve kartopu etkisi hakkındaki nokta çok iyiydi
      Kişi özne olma gücünden asla vazgeçmemeli; ne kadar çok şey bilir ve yapabilirse, daha da fazla şeyi bilip yapabildiği erdemli bir döngü oluşur. Gerçekten güzel ve olumlu bir geri besleme döngüsü

  • Bu yazının o korkunç vibecoding etiketiyle işaretlenmemiş olmasına sevindim. Aslında bu tür şeyleri onlarca yıldır daha kısa ve genelde daha yakınmacı sürümleriyle konuşuyoruz
    Yazılım korkutucu derecede karmaşık, bu yüzden bilişsel kestirmeler çok fazla ve belli bir noktada hayatta kalmak için de gerekli olabiliyor. Ama insanlar, dikkatli olmaları gereken zamanlarda bile daha tembel davranmaya yatkın. Bilgisayarlar katı modülerliğe çok iyi uyar, insanlar ise değil
    Bu yazının, anlamayı basit bir “görev” olarak değil, bir şeyin nasıl çalıştığını anlamanın ne kadar eğlenceli olduğunu vurgulamasını sevdim. Dünyayı anlamaktan keyif almayan insanlar elbette vardır ama bu benim karakterimin o kadar temel bir parçası ki, aksi neredeyse sadece teorik geliyor. Eğer bu keyif sende yoksa, yazılım kariyerine başlamadan önce bir kez daha düşünmelisin

    • Bu yazıda vibecoding etiketi görünüyor
      Artık neredeyse her yazıya vibecoding etiketi ekleniyor gibi, o yüzden belki de bunun yerine fikri tersine çevirip bir non-vibecoding etiketi getirmek daha iyi olur. Vibecoding olmayan ya da vibecoding'in faydalarını anlatan yazıları öyle etiketler, geri kalanını olduğu gibi bırakırız. Ne yazık ki bu yeni standart gibi görünüyor
      Ayrıca duygularımla da “vibe” olarak uyuşan iyi bir yazı

  • Öğrenmeyi gerçekten seviyorum ve yazıda, “yalnızca kısmen kavradığın bir şeyi üretip sonra onu anlamak için daha fazla zaman harcaman gereken” durum ele alınıyor; kişisel olarak böyle bir bilişsel borçtan nefret etmiyorum
    Eğer ilgi duyduğum bir problem alanıysa, zaman ayırıp o borcu ödeyerek anlayış kazanmayı isterim. Sonuçta aynı anlayışa varmanın başka bir yolu gibi geliyor
    Lean Startup kavramını da hatırlatıyor. Ortada görülebilir bir şey varsa, boş bir ekranda neyin önemli olduğunu tahmin etmek yerine somut bir şeyi kurcalayarak başlayabiliyorsun. Nereden başlayacağını bilememek daha kötü ve AI hızlı bir başlangıç yapmaya yardımcı olabilir
    Hâlâ tam oturmayan kısım, daha az deneyimli junior'ların kötü kokuları nasıl fark edeceği ve itiraz edecek sezgiyi nasıl geliştireceği. Benim AI kullanma biçimim çok yinelemeli ve onu gelişim için Sokratik sorgulama gibi ele alıyorum. Bu, mevcut araçlarla mümkün olan tek seferlik vibecoding dünyasından oldukça farklı

    • “Daha az deneyimli junior'ların kötü kokuları nasıl fark edeceği ve itiraz edecek sezgiyi nasıl geliştireceği” kısmıyla ilgili olarak, geçen yılın sonunda sektöre yeni giren yakın arkadaşlarım ve aile üyelerim var
      Gerçekçi olmak gerekirse, bunun eskisinden çok da farklı olduğunu düşünmüyorum. Daha senior kişiler onlara tavsiye verir ve karşı çıkar, ayrıca çoğu teknoloji şirketinde akran değerlendirmesi de vardır. Yani junior'lar tamamen yalnız değil. Hatta hata yapıp uyum sağlamak için bolca zamanları var

  • Birçok temel konuyu epeyce sıralamış olmasını sevdim
    Okur bunu Gish gallop ya da parading of horribles gibi retorik teknikler olarak hayal etmeye yatkın olabilir, ama aslında hayatımızın her anında kesişen onlarca temel teori olduğunu düşünüyorum
    Bilgisayarlar da tek bir birleşik teoriyle programlanmış olmaktan ziyade, birçok küçük teorinin birbirine eklenmiş olduğu bir overlapping set-inclusion diagram'a daha yakın

  • Yazıyı büyük bir keyifle ve dikkatle okudum, hatta birkaç arkadaşımla da paylaştım
    Yavaşlamak giderek zorlaştığı için, yeni yılda temel öğrenmeye açıkça adanma niyetim üzerine ben de şunu yazdım: https://writing.tidefield.dev/hello-world-again/#honing-my-focus
    “2026'dan sonra temel olan ve modası hızla geçmeyecek şeyleri çalışacağım…” yaklaşımının aynı yönde olması hoşuma gitti