İnsanlar için kod yazmak, bilgisayarlar için kod yazmaktan daha zor

 (erikbern.com)
1 puan yazan GN⁺ 2024-09-28 | 1 yorum | WhatsApp'ta paylaş
  • Geliştirici araçları yalnızca bilgisayarın çalıştıracağı mantığı değil, başkalarının anlayıp kullanacağı zihinsel modeli de tasarlamak zorunda olduğu için daha zordur
  • Hızlı onboarding ek bir özellik değil, neredeyse ürünün kendisidir; ayar, API token’ı ve ilk çalıştırma sürtünmesi azaltılmalı, kullanıcı ürünü birkaç dakika içinde kendi dizüstü bilgisayarında deneyebilmelidir
  • Kullanıcılar uzun temel kavram açıklamalarındansa çalışan örnekleri değiştirerek kalıpları öğrenir; probleme yakın başlangıç noktaları ne kadar çoksa başarı ihtimali o kadar artar
  • Hata mesajları, kavram sayısı, adlandırma, yapılandırma biçimi, varsayılanlar, sihirli davranışlar ve söz dizimi şekeri, kullanıcının başarı yolunu değiştirdiği için okunabilir ve özelleştirilebilir tasarım gerekir
  • İyi bir geliştirici deneyimi, özellikleri basitçe azaltmak değil; yapılabileceklerin kapsamını korurken bilinmesi gereken karmaşıklığı büyük ölçüde düşürmektir

İnsanlar için kod zihinsel modelleri de kapsar

  • Bilgisayarlar için kod yazmak, büyük iş hedeflerini bilgisayarın izleyebileceği mantıksal ifadelere bölme işidir
  • Framework, kütüphane, API, SDK, DSL, gömülü DSL ve programlama dili gibi insanların doğrudan kullandığı kodlarda yalnızca çalıştırılabilir olmak yeterli değildir
  • Bu tür kodlar, bilgisayara talimat verirken aynı zamanda kullanıcının o kodu nasıl okuyup anlayacağını da ele almalıdır
  • Geliştirici aracı tasarımı, yalnızca bilgisayar bilimi değil, kullanıcının akıl yürütme biçimini hesaba katan psikolojik bir anlayış da gerektirir

Başlangıç deneyimi ürünün kendisidir

  • Geliştirici araçlarına yönelik geri bildirimler çoğunlukla ürünü sık kullanan power user’lardan gelir
  • Başlangıç aşamasında takılan kullanıcılar geri bildirim bırakmadığı için hayatta kalma yanlılığı oluşur
  • Tüketici ürünleri onboarding funnel’ını optimize ettiği gibi, geliştirici araçları da ilk çalıştırmaya kadar olan süreci ürünün çekirdeği olarak görmelidir
  • Hızlı onboarding için ürün yapısının kendisini değiştirmeye değer
    • Zorunlu ayarları kaldırmak
    • API token’ı ayarlamayı çok kolay hale getirmek
    • İlk sürtünmeyi azaltmak
    • Kullanıcının birkaç dakika içinde ürünü kendi dizüstü bilgisayarında deneyebilmesini sağlamak
  • Geliştirici araçlarının fazlasıyla çoğaldığı bir ortamda kullanıcıların belirli bir LRU cache NPM paketinin farklarını derinlemesine anlamak için enerji ya da sabır göstermesi zordur

Örnekler temel kavramlardan daha hızlı öğretir

  • İnsanlar, katı komutları izleyen bilgisayarlardan farklı olarak örüntü eşleştirmede güçlüdür
  • Birçok geliştirici aracı dokümanı temel veri modelini, ilişkileri, atomik kavramları, yapılandırmayı ve çalıştırma yöntemini anlatmakla başlar; ancak insanlar çalışan örnekleri değiştirip sonuçları görerek daha iyi öğrenir
  • 5.000 kelimelik bir “core concepts” açıklamasındansa birden çok örnek daha faydalı olabilir
    • Kullanıcı, örneklere bakarak aracın nasıl davrandığını öğrenir
    • Çözmek istediği bir problemi olan kişi, yeterince yakın bir başlangıç noktası bulabilir
    • Başlangıç noktası ne kadar çoksa, ihtiyaç duyulana yakın bir örnekle karşılaşma ihtimali o kadar artar

Kullanıcıyı başarı çukuruna itmek

  • Programlamanın varsayılan hali, bir tür hatayı sürekli düzeltmeye yakındır
  • Kullanıcı, aracı kullandığı zamanın büyük bölümünü “neyin çalışmadığını” anlamaya harcayabilir
  • Geliştirici daha hızlı başarılı olursa aracı sever; hatalarda takılıp kalırsa aracı suçlar
  • Her hata, kullanıcıyı mutlu yola geri döndürmek için bir fırsattır
    • İstisna mesajlarına kod parçacıkları koymak
    • Kullanıcının garip bir şey yapma ihtimali olduğunda yararlı uyarılar göstermek
    • Kullanıcının başarılı olması için gereken adımları sunmak

Kavram yükünü azaltmak

  • Bir aracı kullanmadan önce anlaşılması gereken her yeni kavram bir sürtünme noktası haline gelir
  • 2–3 kavram kabul edilebilir olsa da 8 yeni kavram öğrenmek isteyen kullanıcı sayısı fazla değildir
  • Kubernetes’te başlangıçta tüm kavramlara ihtiyaç yoktur; ancak yeni kavramlar arttıkça yük de büyür
  • Güçlü olup yalnızca 3–5 kavrama sahip framework’lerde bir zarafet vardır
  • React’i ilk kez kullanırken bir iki saat sonra kavramsal tepeyi aştığınızda, birkaç basit yapı taşıyla büyük yapılar kurabileceğiniz hissini verebilir
  • Amaç yalnızca kavram sayısını azaltmak değil, yapılabileceklerin kapsamını korurken kullanıcının bilmesi gereken kavramları azaltmaktır
  • Harika bir araç, karmaşıklığı %90 azaltırken yeteneği olduğu gibi koruyabilir
  • Karmaşıklığı %90 azaltıp yeteneği yalnızca %10 azaltan bir araç da fena değildir

Kavramsal ördek ilkesi

  • Bir framework içinde bir değeri alıp yeni bir değer hesaplayan bir unsur varsa, ona “compute node”, “valuator” ya da “frobniscator” gibi yeni adlar vermektense function demek daha iyidir
  • Bir şey ördek gibi yürüyüp ördek gibi vaklıyorsa, büyük olasılıkla ördektir ilkesi kavram tasarımına da uygulanabilir
  • İnce farklar olsa ya da değer cache’lense bile function’a yeterince yakınsa function denebilir
  • Mevcut terimleri kullanmak, kullanıcının zaten sahip olduğu zihinsel modele bağlanır ve açıklanması gereken miktarı büyük ölçüde azaltır

Programlanabilir hale getirmek

  • Kullanıcılar codebase ile beklenmedik şeyler yapar; framework unsurlarını for-loop içine, fonksiyon içine ya da başka yapıların içine koyabilir
  • Bu yüzden framework’ün neredeyse her şeyi programlanabilir olmalıdır
  • İlgili tasarım yönleri birbirine bağlıdır
    • CLI üzerinden geçmeden koddan doğrudan çağrılabilmesini sağlamak
    • Yapılandırma dosyalarını azaltıp SDK veya API’ye dönüştürmek
    • Yalnızca bir tane oluşturulmasına izin vermek yerine parametreleştirerek n tane oluşturulabilmesini sağlamak
  • Bu tasarım, kullanıcıların yeni kullanım senaryoları keşfetmesini sağlayabilir
  • Framework üzerinde “hack” yapma arzusundan yararlanmak, biraz karmaşa doğursa bile beklenmedik keşiflere yol açabilir

Sihir, varsayılanlar ve söz dizimi şekeri konusunda dikkatli olunmalı

  • Bulutta Jupyter notebook çalıştıran bir run_notebook fonksiyonu olduğunu ve kullanıcının hangi konteyner imajını kullanacağını belirtmesi gerektiğini varsayalım
  • Olası seçenekler çeşitlidir
    • image=... argümanını her zaman zorunlu tutmak
    • Çoğu veri bilimi kütüphanesinin kurulu olduğu varsayılan bir imaj sunup kullanıcının bunu override etmesine izin vermek
    • Hücrelerdeki kodu inceleyerek gerekli bağımlılıklara göre “sihirli” biçimde imaj seçmek
    • Sihirli yönteme ek olarak kullanıcının belirli bir imaj seçebilmesine de izin vermek
  • Girdi miktarını azaltıp en geniş kullanım senaryosunu desteklemek için son seçenek iyi görünebilir
  • Ancak ilk seçenek dışındakilerde sorunlar kalır
    • Sihir bazı durumlarda bozulur
    • Varsayılana dayanan kodu okuyan kullanıcı, özelleştirme imkânını fark etmeyebilir
  • Varsayılanlar %97’den fazla uygulanmıyor ve sihir %99’dan fazla doğru çalışmıyorsa çok dikkatli olunmalıdır
  • Kodlama golf değildir; araç sağlayıcısının işi yalnızca kullanıcının yazdığı kod miktarını en aza indirmek değildir
  • Perl kısa koda güçlü biçimde optimize edilmişti, ancak programlar özel karakter dizileri gibi görünebiliyordu; Python ise kod %50 daha uzun olsa bile okunması ve anlaşılması daha kolaydı
  • İnsanlar kodu yazmaktan 10 kat daha fazla okuduğu için okunabilirlik önemlidir
  • Söz dizimi şekeri de aynı ölçütle değerlendirilmelidir
    • Yaygın kullanım senaryoları için özel söz dizimi eklemek isteyebilirsiniz
    • Ancak bu, tutarlılığı bulanıklaştırabilir ve özelleştirme yöntemini daha az belirgin hale getirebilir
    • Söz dizimi şekeri %99’dan fazla uygulanmıyorsa, onu eklememek daha iyi olabilir

İlk kez kullananlar için tasarım ilkeleri

  • İnsanlar için kod yazarken geriye daha birçok tasarım sorunu kalır
    • Çoğu şey değişmez olmalı, ama tamamı değil
    • Scaffolding’den, yani kod üretiminden kaçınmak
    • Geri bildirim döngüsünü çok hızlı hale getirmek
    • Kullanıcıların kullanımdan kaldırılması planlanan özelliklere kolayca uyum sağlayabilmesini sağlamak
    • Dokümanlardaki ve örneklerdeki kod parçacıkları için otomatik testler kullanmak
  • İlk kullanıcı deneyimini tasarlamak, pop şarkısı yapmaya benzer
  • Prodüktör şarkıyı bin kez dinlese bile, 999. dinleyişinde onu ilk kez duyan birine nasıl geleceğini hayal etmelidir
  • Geliştirici araçlarında da ürünü tekrar tekrar yapan kişinin ilk kez kullanan kullanıcının deneyimini hayal etmesi çok zordur

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-28
Hacker News yorumları

  • Herkesin öğrenme biçimi farklı. Ben örneklere geçmeden önce önce temel kavramlara ihtiyaç duyarım. Temel kavramlar çok basit değilse bu daha da geçerli.
    Birçok eğitim içeriği, elinden tutup Lego yaptırmaya benziyor. “İşte Lego parçaları; ben oyuncak bir proje yaparken beni takip et, günün sonunda Lego yapmayı öğrenmiş olacaksın” tarzında.
    Bu yöntem bana pek uymuyor. Kararların nasıl ve neden alındığını bilmek, yazarın bakış açısından görmek istiyorum. Her bir Lego parçasının nasıl bir şey olduğunu, birbirlerine nasıl bağlandıklarını, belirli bir tasarıma nasıl ulaşıldığını bilmek istiyorum.
    En azından asgari düzeyde üst seviye kavramsal açıklama olmadan bir eğitimi takip etmek, aslında gerek kalmaması gereken bir şeyi tersine mühendislik yapıyormuşum gibi hissettiriyor. Yeni bir kütüphane ya da framework gördüğümde tanıtım yazısını okur, “başlangıç” kod örneklerini genelde atlarım. Çoğu zaman “ileri seviye” bölümlerde daha fazla kavramsal tartışma olduğu için oradan başlarım; sonra API referansından önemli arayüzleri kavrar, en son da eğitimin başındaki temel kod örneklerine geri dönerim.

    • Eskiden kendimi “temel kavramlar” tipi biri sanırdım, ama sonradan bunu fazla ileri götürdüğümü fark ettim. Her şeyi önceden gerçekten anladığımı hissetmeden konfor alanımın dışındaki işleri reddetme eğilimindeydim.
      Bugünlerde çok daha sık doğrudan atlayıp örneklerle çalışıyorum ve kendimi daha üretken hissediyorum. Bir ölçüde bu bir güven meselesi. Kaliteli yazılım geliştiren insanların, yaygın kullanım senaryolarında iç kısımları derinlemesine kazmaya gerek kalmadan arayüzü anlaşılır kılacak kadar düşünmüş olduklarına güvenmek.
      Elbette daha derine inmeyi gerektiren engellerle sık sık karşılaşıyorum. Ama böyle bir durum, yalnızca yüzeysel izlenimle başarıyla aştığım başka 10 şey olduğu için ortaya çıkıyor. Bu yüzden gerçekten derine indiğimde de bunun genelde zaman kaybı olmadığını düşünüyorum.
    • Buna gerçekten katılıyorum. İlk başladığımda create-react-app gibi “proje oluşturuculardan” hoşlanmazdım. Bu sadece bir örnek; React’i onun ortaya çıkmasından çok önce öğrenmiş olduğum için şanslı olduğumu düşünüyorum.
      Bu tür araçlar belirli bir klasör yapısı, şablon dosyaları ve önceden yapılandırılmış araçlar üretir. Oluşturulan dosyaların ne yaptığını ve neden o şekilde oluşturulduğunu üst düzeyde hemen anlamazsam, anlamadığım fazla miktarda sihir olduğu için rahatsız olurum.
      Yeni bir şey geldiğinde, amacını zaten bildiğim kavramlarla ilişkilendirerek anlatan üst düzey bir tanıtıma ihtiyaç duyarım. En azından o kara kutunun ana arayüzünü kabaca anlamadan sihirli kara kutularla uğraşmak bana rahat gelmez. Örneğin create-react-app’i en baştan öğreniyor olsaydım, hemen Babel ya da ESLint gibi onun yapılandırdığı araçların amacını araştırmaya başlardım.
    • Ben o şekilde denedim ve bilgisayar bilimlerini nasıl öyle çalışıp geçtiğimi bilmiyorum. Çözümleri yeniden üretebiliyordum ama anlamıyordum.
      Yıllar sonra, çok sayıda iyi pratik örnek gördükten sonra kavramların ne söylediğini anlayabildim. O farkındalıktan sonra öğrenme biçimimi incelttim.
      Önce temel kavramlara göz atıyorum; o kavramların neden gerekli olduğunu anlayana kadar çeşitli örnekler deniyorum; ardından naif örneklerde eksik kalan uç durumları ortadan kaldırmak için temel kavramları dikkatle okuyorum.
    • Ben de benzerim. Maven’ın neden çalışmadığını anlamaya çalışırken de bu sorunu yaşadım. “Nasıl başlanır” eğitimine değil, neler olup bittiğini anlayabilmem için temel ilkelere ihtiyaç duydum.
      Öte yandan örneklerden başlama yönteminin iyi API tasarımına yardımcı olabileceğini düşünüyorum. Bir API’yi “önce temel kavramlar” anlayışıyla tasarlarsanız, sonuçta ancak temel kavramları anladıktan sonra kullanılabilen bir API’ye dönüşmesi kolaydır; bu da onu ara sıra kullananlar için iyi değildir.
    • İyi özetlemişsin. Özellikle “insanlar böyle öğrenmez” cümlesinde şüphelenmeye başladım.
      Hacker tarzına uygun olarak alıntı yoktu. Eğitim bilimine sadece biraz baktım ama Dewey ve Piaget’nin deneyim psikolojisinden modern ilkeler çıkaran, büyük ve olgun bir akademik alan bu. Bırakın tek bir blog yazısını, bir blog yazısının tek bir bölümüyle ele alınabilecek olandan çok daha fazla söylenecek şey var.
      En büyük sorun, belirtildiği gibi insanların birbirinden farklı olması. Bir sonraki büyük sorun ise bu farklılığın neden ortaya çıktığını ve zaman içinde ne kadar kararlı kaldığını bile kesin olarak bilmememiz. Yazının kendisi iyi yazılmış ve belirli bir eğitim stratejisinin pratikliğini iyi irdeliyor, ama biraz daha alçakgönüllülük olmasını isterdim.

  • İki hafta bile geçmeden benzer bir yazı vardı: https://news.ycombinator.com/item?id=41566097
    İnsanlar için yazmak eninde sonunda iki beceriye, empati ve yazmaya indirgenir.
    Biraz kod yazmak ile bir uygulama ya da ürün yazmak arasında büyük fark vardır. Bu yazı da daha az açık sözlü olsa da sonuçta aynı şeyi söylüyor. Empatinin önemli olmasının nedeni, benmerkezcilik ile dışa dönüklük arasındaki farkı yaratmasıdır.
    Benmerkezci geliştirici çoğunlukla kolaylık, rahatlık, kod gösterişi ve diğer öznel ölçütlerle ilgilenir. Sonuçta yalnızca kendi aktarma çabasını hesaba katar. Dışa dönük geliştirici ise daha çok mimari ve dokümantasyonla ilgilenir. Çünkü başarının, başkalarının kendi çıktısını nasıl karşıladığına bağlı olduğunu düşünür.
    Basitlik, kolaylıktan daha önemlidir. Çünkü dışa dönük geliştirici başkalarının zihnini okuyamaz ve neyi kolay bulacaklarını bilemez; ama adım sayısını azaltmayı ve kodu küçük tutmayı bilir.
    Bütün ürün açısından bakıldığında uygulama yazmak, beynin içinde bir deneme, makale ya da kitap yazmaktan farklı değildir. Esas mesele organizasyon ve işlevdir. Kod sonradan gelir; sayfadaki kelimeler gibidir. Yalnızca kod parçaları yazan kişi, her şeyi bir araya bağlayan üst düzey organizasyon becerisini geliştiremez.
    Bu yüzden framework’lerden çok hoşlanmıyorum. Framework’ler, geliştiricinin özgün yazılım yazmak için ihtiyaç duyduğu pratiği elinden alır ve bunun sonucunda organizasyon becerilerini geliştirmesini engeller. Kişinin kendisi bunu göremez; ama görebilen biri için bu, son derece açık büyük bir uçurumdur.

    • Doğru, ama aynı zamanda bir ikilem. Framework yapanlar bunu başkalarının ürünleri daha kolay çıkarabilmesi için yapıyor. Framework üretme sürecinde kendileri daha iyi geliştiriciler oluyor.
      Ama diğer insanlar artık onların soyutlamalarını öğrenmek zorunda kalıyor ve bu ölçüde alttaki kavramlardan uzaklaşıyor. Bu da framework’ün ötesine geçmek için gereken temel becerileri edinmeyi zorlaştırabiliyor. Rails öğrenirken bende de böyle bir his vardı; sonunda çok fazla şeyi gizlediğini fark edip bıraktım ve en baştan yapmayı denedim.
    • Kod parçaları yazmakta epey iyiyim, ama uygulama yeterince karmaşık hale geldiğinde soruna daire çizip yeniden yazıyormuş gibi saldırma eğilimim oluyor. Karmaşıklık arttığında bazen sonsuz yeniden yazma döngüsüne giriyorum.
      Bunun tamamen farklı bir beceri olduğunu fark etmek insanın gözünü açıyor. Bir bakıma artık bilinen bir bilinmeyen haline geldi.
    • Empati iyidir, ama bilişi anlamak gerekir. Aksi halde empati yanlış yerde kullanılır.
      Patronun ensenizde olduğu bir durumda ya da saat gece 2’de operasyon sorununu düzelten birine bu kod nasıl görünür? Bu yanıt gerçekten gerekene kadar ne kadar değerli olduğunu bilmezsiniz. Gerektiği anda ise o yanıt için büyük para ödersiniz. Tabii bunu yapabilen birini bulabilirseniz. Böyle insanlar nadirdir.

  • “İnsanlar temel kavramlardan değil, örneklerden öğrenir” sözüne katılmıyorum. Belki mızıkçılık sayılabilir, ama tüm insanlar böyle çalışmaz.
    Genelden özele gitmeyi tercih edenler zaten ilkokul-ortaokul-lise eğitiminde büyük ölçüde görmezden gelinir; ancak yükseköğretime gelince nihayet kendilerine uygun bir yere başlayabilirler. Zaten yeterince dışlanmış durumdalar; varlıklarını da inkâr etmeye gerek yok.

    • Geçenlerde kız arkadaşımla ve babasıyla seyahat ederken manuel vites kullanmayı öğrendim. Kız arkadaşım sadece debriyaja ne zaman basıp ne zaman bırakacağımı eylem olarak anlattı; hiç yardımcı olmadı.
      Ne zaman ne yapmam gerektiğinin nüanslarını, nelerin tamamen aynı anda yapılması gerektiğini ve nelerin hemen ardından gelmesi gerektiğini anlayamadım. O sırada kız arkadaşımın babası debriyajın gerçekte ne yaptığını, tekerleklerle motor arasındaki bağlantının iki tarafı nasıl etkilediğini kısaca açıkladı.
      O anda hemen anladım ve belirli durumlarda ne yapmam gerektiğine dair talimat duymama da gerek kalmadı. Yaklaşık 20 dakika sonra, manuel viteste en zoru denilen şeyi, geriye eğimli bir rampada el freniyle kalkış yapıp arabayı sürebiliyordum. Bazı insanlar için işleyişi ilk ilkelerden anlamak çok daha faydalı; yazılım mühendisleri arasında da bu “bazı insanlardan” epey olduğunu düşünüyorum.
    • Benim ikisine de ihtiyacım var. Benim için gerçek öğrenme temel kavramları öğrenmektir; ama örnekler, bu anlayışı doğrulayabileceğim cevabı bilinen vakalardır.
      Örnekte şaşırtıcı bir yer varsa bu, modelimin henüz tamamlanmadığı anlamına gelir. Ya da örnek yanlıştır.
    • Ortalama bir teknik kişiden daha yavaş kavrıyor olabilirim, ama ikisine de ihtiyacım var. Şu anki işimin büyük kısmının sinir bozucu olmasının nedeni, büyük bir şirkette olduğum için her yeni işle karşılaştığımda yalnızca önceki kişinin bunu nasıl yaptığına dair örneklerin verilmesi.
      “Ulaşmaya çalıştığımız şey bu, bu şöyle çalışır ve biz bunu böyle yaparız” değil; uygulayıcıya gösterilen şey her zaman yalnızca “biz bunu böyle yaparız” oluyor. Çok az farklılaştığında bile akıl yürütemez, uyarlayamaz ve sorunu çözemaz hale geliyorsunuz.
      Sık yapılan işler için bir miktar dokümantasyon olsa da genellikle eski ya da eksik oluyor. Wiki olmadığı için herkes istediği zaman düzeltemiyor; dokümanı düzeltmek için can sıkıcı bir süreçten geçmek gerektiğinden sonuçta güncellenmiyor. Düşününce orduda olduğum dönemlere epey benziyor.
    • Ben de katılıyorum. Benim öğrenme biçimim, benzetme yaparsam başvuru kılavuzunu baştan sona okumak. Yeni bir şey öğrenmeye çalışırken önerilen giriş materyallerinin çoğu, aradığım şeyin tam tersi olmuştur.
      Şu anda Drizzle ORM öğrenmek için zaman ayırırken de bunu yaşıyorum. İlk bulduğum kaynakların hepsi “altı sorgu örneği”ydi; neden o söz diziminin kullanıldığını, başka seçeneklerin neler olduğunu merak edip bunaldım. Böyle kaynakları kapatıp dokümantasyondaki tüm sayfaları okuduktan sonra bir şeyler yapmaya başlamak benim için çok daha rahat.
    • Okulda işler, kafamın içinde teori kurma alıştırması yapmaya başladıktan sonra yoluna girmeye başladı. Hipotez kurmak, sınamak ve rafine etmek şeklinde.
      Bunu hâlâ gerçek zamanlı yapabilir miyim bilmiyorum. Bu yöntem epey düşünme döngüsü kullandığı için, şu anda yazı okumak ya da videoyu durdurup sindirmek hız olarak bana daha uygun.
      Henüz anlamamış kişilere sık sık ayaküstü ders verir hale geldim. Bir sisteme dair teoriniz varsa, ezberi zar zor aşmış bir sınıf arkadaşının yanıtlayamayacağı sorulara da yanıt verebilirsiniz.

  • Code Complete’ten bir cümle: “Programlama işinin küçük bir kısmı, bilgisayarın okuyabilmesi için program yazmaktır; daha büyük kısmı ise başka insanların okuyabilmesi için yazmaktır.” s. 733
    Neredeyse 20 yıl boyunca aklımda kaldı

    • “Programlar insanların okuması için yazılır; bilgisayarların çalıştırması ise yalnızca ikincil bir iştir.”
      Abelson ve Sussman’ın Structure and Interpretation of Computer Programs kitabının ilk baskısının önsözünde geçen bir söz; Code Complete’ten 10 yıl daha eski
      Uymaya çalıştığım bir özdeyiş, ama işverenler tuhaf biçimde hep bilgisayarın çalıştırdığı kısımda ısrar ediyor gibi görünüyor
    • SICP yazarlarından biri olan Abelson da benzer bir şey söylemişti. Kodun insanların anlayacağı şekilde yazılması, bilgisayarın anlamasının ise en son gelmesi gerektiği minvalindeydi

  • Biraz konu dışına sapmak olacak ama birkaç gün önce Unity oyunu yaparken, IDE'lerin son 10–20 yılda gerçekten pek gelişmediğini düşündüm.
    Temel IntelliSense kesinlikle çok daha iyi hale geldi, ama bunun dışında birkaç küçük nokta haricinde kodlama kavramının tamamı eskisiyle neredeyse aynı görünüyor.
    En büyük olumlu değişim editörün dışında. Kütüphanelere ve dokümantasyona çok daha kolay erişilebiliyor, kullanıcı soruları ve cevapları muazzam ölçüde arttı ve bazen bu cevapları bir araya getirip makul görünen yanıtlar veren ChatGPT gibi yeni araçlar da ortaya çıktı.
    Ama genel olarak kod yazma eylemi durgunlaşmış gibi. Bu yüzden şimdilik oyun üzerinde çalışmayı biraz durdurup birkaç deney yapıyorum. Yeni bir dil yapmak istemiyorum; mümkün olan tüm angaryayı bilgisayara devredip yaratıcılığa odaklanmak istiyorum.
    İlk test etmek istediğim üç şey şunlar: Parantezler ya da sonlandırıcılar gibi küçük dil ayrıntılarıyla neden ben uğraşayım; araç bunları otomatik tamamlayamaz mı? private-public erişim zincirleri ya da unsafe gibi değiştiriciler için de araç en verimli kümeyi otomatik olarak belirleyemez mi? Birbiriyle etkileşen yaklaşık 5 metoda odaklanırken, birden fazla pencere açıp VS'in yatay/dikey kaydırıcılarıyla boğuşmadan hepsini tek ekranda görmek istiyorum. Bir HashSet oluşturduktan sonra bunu Dictionary ya da Tuple'a çevirmem gerekiyorsa, bunu öylece değiştirsin; yalnızca karar gerektiren yerleri gösterip onaylamama ya da kendim düzeltmeme izin versin. Unity'de bir metoda ya da veri kümesine tıklayıp onu bir Burst Job'a ve ona bağlı NativeData kümesine dönüştürmesini söyleyebilmek de isterdim.

    • Kodlama kavramının tamamının eskisiyle neredeyse aynı olması, programlama dili kavramının tamamının pek değişmemiş olmasından kaynaklanıyor. Turing makinesi ve lambda hesabı diye iki büyük sütun var; sonrası soyutlamalardan ibaret. Soyutlama iyiyse buna paradigma diyoruz.
      Ama sonuçta hepsi soyutlama ve biz çok aptal bir makinenin veri hesaplaması için komutlar yazıyoruz.
      Parantezleri ya da sonlandırıcıları araç otomatik tamamlasın denmiş, ama bilgisayar gerçekten çok basit bir şeydir ve programlama dili zihindeki düşünceleri aktarma kanalıdır. Bu tür ayraçlar, dil anahtar sözcükleri kadar önemlidir; çünkü kuralların bir parçasıdır. Onları otomatik tamamlamak için daha fazla kurala ve daha fazla ayraca ihtiyaç olur.
      Birbiriyle etkileşen birden fazla metodu tek ekranda görmek istiyorsanız Vim ve Emacs ya da Pharo gibi Smalltalk IDE'leri var.
      Veri dönüşümü Vim ve Emacs makrolarıyla yapılabilir. Ama gerçek şu ki veri kodlaması çok önemlidir. Bilgisayar için her şey bittir; o bitlere anlamı biz verir ve o anlama göre onları manipüle eden kuralları biz oluştururuz. Bir kural kümesinden başka bir kural kümesine biçim değiştirmek için daha fazla kural gerekir.
      Canlı programlama ortamlarını denemenizi öneririm. Common Lisp'in SLIME'ı, Smalltalk'ın Pharo'su, JavaScript'in web denetleyicisi gibi. Karada duran bir tekneye bakıp yelken açmanın nasıl hissettireceğini hayal etmek yerine, denizin ortasındaki bir teknede çalışmak gibi.
    • Metin editörü deneyiminin büyük ölçüde iyileşmemesinin nedeni, bunun çoğu zaman darboğaz olmaması bence.
      Programlamanın en zor kısmı düşünmek ve öğrenmek. Daha hızlı yazmak çok büyük fayda sağlamıyor.
    • Otomatik tamamlama konusunda katılıyorum. En az 35 yıl önce bile MS-DOS için Brief editörü, keyfi şablonlar tanımlayıp bunları otomatik tamamlayabiliyordu.
      Örneğin C programı yazarken “f” harfini “for (=; <=; ++) {;}” ya da tercih ettiğiniz girintileme biçimine genişletebiliyordunuz.
      Modern programlama editörlerinin çoğu benzer kullanıcı ayarlarını destekliyor, ama ne yazık ki çoğu durumda süreç çok eskiye kıyasla daha karmaşık.
      Söz dizimi laf kalabalığı olan bir programlama diliyse, editörde en az tuş vuruşuyla herhangi bir program yapısını hızlıca yazabilmek için şablonlar tanımlamaya zaman ayırmak gerektiğini düşünüyorum.
    • Parantezler ya da sonlandırıcılar gibi şeyler söz dizimini açık hale getirir ve araç desteğini büyük ölçüde iyileştirir. Editörlerde genellikle bunları ekleyen özellikler bulunur. Ama bazı durumlarda bana apaçık görünse de aslında geçerli birkaç seçenekten biri olabilir; bir tasarım dokümanı gibi bir şey yoksa araç zihninizi okuyamaz.
      HashSet, Dictionary, Tuple arasında hangisinin kullanılacağı gibi meselelerin performans etkileri vardır ve soyut düzeyde hangisini kullanmak gerektiği her zaman açık değildir. Java gibi açık tipli dillerde, muhtemelen C#'ta da, metot çağrılarını başka bir tipi alacak şekilde refactor etmek mümkün olmalı. O zaman bir metodu değiştirip tüm çağrılarını refactor edersiniz.
      Gemini pro ve ChatGPT o1'i denedim; ikisi de Python ve JavaScript kodlamada gerçekten kötü. Hatalı kod yazıyorlar ve bir hatayı düzeltmeye çalışırken sık sık başka hata ekliyorlar. İkisi de gereksinimleri düşünmekten çok cevabı aceleye getiriyor gibi. İstediğimiz biçimde “zihin okuyabilen” ya da neyin önemli olup olmadığını anlayan araçlara daha biraz mesafe var bence.
      Daha kötü olabilecek nokta ise eğitim verisi. Kodların çoğu ortalamanın altındaki ve ortalama seviyedeki kodlayıcılar tarafından yazıldığı için, bu tür araçlar ortalama bir kodlayıcının düşünce kalıplarını benimser. Yalnızca en yüksek kaliteli kodla eğitilse bile, çoğu kodlayıcının doğru şekilde prompt verip veremeyeceği belli değil. Bu yüzden 10–20 yıldır kod yazıyorsanız, anında sihir beklediğiniz sürece bir araçtan biraz hayal kırıklığına uğrama ihtimaliniz epey yüksek.
      Yine de yapay zeka olmayan statik analiz araçları uzun zamandır harika ve daha da iyi olacaklar. Buna yapay zeka eklenirse daha da gelişebilir. Aracı, bir spesifikasyon atıp iyi bir sonuç geri alan bir sanatçı gibi değil, benim sanatçı olmama yardım eden bir şey olarak düşünürsek harika bir deneyim yaşanabilir bence.
      Editörün daha fazla ne yapmasını istediğinizi yapay zekaya söyleyip ayarları yapmasına yardım etmesini istemek de ilginç bir deney olabilir. Eklentiler arasında yapay zeka olmayan pek çok araç var. Yaşam tarzınıza uyan eklentileri seçmek için büyük dil modeli kullanmak en verimli yol olabilir.
    • Birden fazla dosyanın bir bölümünü düzenlerken, birbiriyle etkileşen yaklaşık 5 metodu tek ekranda görmek isteme kısmı için haystack ilginç olabilir.
      https://haystackeditor.com/
      Kendim kullanmadım ama denemeyi düşünüyorum.

  • Yazının başlığı tartışmaya açık. Çünkü kod yalnızca insanlar için yazılır. Bilgisayarın “koda” ihtiyacı yoktur; özellikle yüksek seviyeli koda hiç ihtiyacı yoktur. Bilgisayar için makine dili komutları yeterlidir.
    Kod yazmamızın nedeni, makine dili komutlarının insanlar için yazmasının çok zor, okumasının ise daha da zor olmasıdır.
    Kodu bilgisayarla etkileşim kurma biçimi olarak düşünmemek gerekir. Kod, insanın düşüncesini biçimselleştirip, makinenin bile takip edebileceği kadar belirsizlikten arındırma yoludur.

  • Geçen hafta yazıp paylaştığım blog yazısını özgecil biçimde tanıtıyorum
    Move Fast & Document Things [1]
    Felsefi bir yazı yazmaya çalışmadım; küçük ekibimizin [2] otomasyon ya da yapay zeka ile değil, derin ve zorlu incelemeler yoluyla kendimiz ve birbirimiz için kod yazma kültürünü nasıl zorunlu kıldığını anlatan pratik ipuçları paylaşmak istedim
    Başka kuruluşlarda mühendislik liderliği yapan kişisel arkadaşlarımın hepsi “biz de aynısını yapıyoruz ama sen bunu gerçekten yazıya dökmüşsün” dedi. Değerli bulduysanız tavsiye etmenizi rica ederim
    [1] https://olshansky.substack.com/p/move-fast-and-document-thin...
    [2] https://github.com/pokt-network/poktroll/graphs/contributors

  • “Çok fazla programlama kitabı ve öğreticisi ‘hadi sıfırdan, tuğla tuğla bir ev inşa edelim’ yaklaşımında; benim istediğim ise ‘işte çalışan bir ev, bir şeyleri değiştirelim ve ne olduğuna bakalım’”
    Programlamayı kendi kendime bu şekilde öğrendim. Küçük, basit ve biraz kötü programları iyi kullanarak yıllar geçirdim
    Sonradan daha iyi yazılım geliştirme işlerine uygun olmadığımı fark ettim. Çünkü yazılım tasarımı, programlama dilleri ve bilgisayarlar hakkında hiçbir temel bilgim yoktu. Sıkıcı yoldan öğrenmediğim için ne kadar çok şey bilmediğimi mülakat odasından çıkarken fark etmek insanı alçaltan bir deneyimdi
    Her zaman tüm kılavuzu okumalı ve her zaman temelleri öğrenmelisiniz

  • Kodumun tamamını insanlar için yazarım
    Bu insan ister ben olayım, ister birkaç yıl sonra niyetimi anlamak zorunda kalacak zavallı biri olsun fark etmez
    Kod yazmanın kendisinin zor olduğunu düşünmüyorum. Yeteneği gösteren şey; problemi kapsamlı biçimde akıl yürütmek, diğer paydaşlarla işbirliği yaparak en iyi yolu keşfedip onları yönlendirmek, yeni matematik ya da sektör teamülleri gibi uzmanlık becerileri öğrenmek, verimli algoritmalar tasarlamak ve programın yapısının ve kalıplarının net ve zarif sınırlara sahip olmasını aktarabilmek
    Sonuçta işin büyük kısmı iletişim ve açıklığa dayanıyor

  • Bu yazının büyük bir bölümü dokümantasyonla ilgili ve 4doc modeline atıf yapsaydı çok yardımcı olurdu: https://docs.divio.com/documentation-system/
    Temelde söylenen şu: yalnızca referans dokümantasyonu sunmayın, kullanım dokümantasyonu da sunun. Ayrıca kullanıcıların genellikle tüm dokümantasyonda önce görmek istediği kısım bu olduğundan, onu öne çıkarın
    Elbette bu genel olarak böyle; ben referans materyaline doğrudan gitme eğilimindeyim ama bu her zaman böyle değil
    4doc’un her derde deva ya da bir doğa yasası olduğu anlamına gelmiyor. Hillel Wayne de buradaki sorunları şurada iyi ele alıyor: https://www.hillelwayne.com/post/problems-with-the-4doc-mode...