O şeyi yapmak, o şeyi yapmaktır

 (softwaredesign.ing)
3 puan yazan GN⁺ 2026-01-28 | 2 yorum | WhatsApp'ta paylaş
  • Yalnızca eylemin kendisi gerçek icradır; düşünmek ya da hazırlanmak icra değildir
  • Plan yapmak, öğrenmek, tartışmak, araç satın almak gibi şeylerin hiçbirinin ‘işi yapmak’ olmadığı tekrar tekrar vurgulanır
  • Başarısız olarak ya da beceriksizce bile olsa doğrudan deneme eylemi ancak gerçek icra olarak kabul edilir
  • Küçük de olsa başlamak önemlidir; kusursuz hazırlık ya da ideal koşullar gereksizdir
  • Gerçek eyleme geçme tutumunun üretim ve geliştirmenin özü olduğunu hatırlatan bir yazı

İcra ile icra olmamanın ayrımı

  • Yazı, “düşünmek, hayal kurmak, görselleştirmek, hazırlanmak” gibi şeylerin hepsinin ‘işi yapmak’ olmadığını sıralar
    • Örnek: “düşünmek”, “hayal kurmak”, “başarıyı hayal etmek”, “hazır olana kadar beklemek”
  • Konuşmak, açıklamak ya da tartışmak da icra sayılmaz
    • “Başkalarına anlatmak”, “internette tartışmak”, “başlayacağını duyurmak” buna dahildir

Hazırlık ve tüketim tuzağı

  • Podcast dinlemek, eğitim videoları izlemek, başkalarının örneklerini okumak bunların hiçbiri icra değildir
  • Mükemmel sistemi tasarlamak, araç satın almak ya da çalışma alanını düzenlemek de icra olarak görülmez
  • Suçluluk duygusu ya da meşguliyetle teselli bulma tavrı da gerçek eylem değildir

Gerçek icranın biçimi

  • Başarısız olarak yapmak, beceriksizce yapmak, küçük de olsa yapmak bunların hepsi ‘işi yapmak’ olarak kabul edilir
    • Mükemmel olmasa da gerçekten elini taşın altına koyan eylem önemlidir
  • Yazının sonlarına doğru “blog yazmak bile işi yapmak değildir” denerek öz eleştirel bir sonuç sunulur

Ana mesaj

  • Yalnızca eylem gerçek icradır; geri kalan her şey, icranın yerine geçen bir şey değildir
  • Küçük de olsa başlamak, başarısızlığı göze almak ve bizzat denemek tek gerçek ilerlemedir
  • Yazının son cümlesi “Şimdi yeniden çalışmaya dönmem gerek” ifadesiyle hemen harekete geçme tutumunu simgeler

İlgili okumalar

2 yorum

 
bobross0 2026-02-27

Benim gibi harekete geçmekte pek iyi olmayan insanlar için güzel bir ifade.
 
GN⁺ 2026-01-28
Hacker News görüşleri

  • “Kötü yapmak” ilkesi düşünme tarzımı tamamen değiştirdi
    Haftalarımı mükemmel bir mimari tasarlamaya harcadım ama sonunda plan yapmayı bırakıp sorunumu çözen kaba bir sürüm yaptım
    Şaşırtıcı olan, o ilk sürümün bana plan yaparak asla öğrenemeyeceğim şeyleri öğretmesiydi. Kullanıcıların gerçekten neye önem verdiğini, pratikte hangi edge case’lerin önemli olduğunu ve “yeterince iyi”nin ne anlama geldiğini öğrendim
    En zor kısmı, kusurları olduğunu bilirken yayına çıkmasına izin vermek. Ama gerçek kullanımın getirdiği geri bildirim döngüsü, haftalar süren varsayımsal tartışmalardan çok daha değerliydi

    • İçeriğe katılıyorum ama yazının tonu LLM tarafından üretilmiş bir yazı gibi hissettiriyor
      Bugünlerde üretkenlik odaklı subreddit’lerde bu tarz yazılar dolu. Kişisel bir otomasyon aracı yaparken haftalarca mimari planlamanın ne kadar gerçekçi olduğu da bana şüpheli geliyor
      Yazarın yorum geçmişine bakınca benzer üslubun tekrarlandığını görmek güven vermiyor
    • Geçmişte gördüğüm harika bir geliştirici, kodu birkaç kez tamamen silip baştan yazarak çalışıyordu
      Bu süreci izlemek gerçekten çok ilginçti
    • Yeni başlayanlara bu hissi öğretmek gerçekten zor
      Gerçekten uygulayıp refactor etme sürecinde, hem sorun hem de genel olarak programlama hakkında öğrenilecek çok şey var
      İlk düşündüğün soyutlamalar çoğunlukla yanlış çıkıyor. Uygulamaya başlayınca yapı tamamen değişiyor ve sonunda ilk halinden bambaşka güzel bir kod ortaya çıkıyor
    • Fred Brooks’un 『The Mythical Man-Month』 kitabındaki “Plan to Throw One Away” denemesini hatırlattı
      İlk sürümü atmayı göze alarak yap der, ama pratikte çoğu zaman atmak yerine onu yinelemeli olarak iyileştiriyoruz
      Artık araçlar ve süreçler sayesinde sürekli iterate edebiliyoruz
    • Asıl önemli olan üst seviye özellik tasarımı ile iç plumbing (altyapı iskeleti) işlerini birbirine karıştırmamak
      İç yapı da yineleme ve prototipleme gerektirir ama veri yapıları, hata işleme, loglama ve isimlendirme gibi şeyler baştan dikkatli seçilmeli ki sonradan hızlı iyileştirme yapılabilsin

  • “Doing it badly is doing the thing” cümlesini sevdim
    HN’de öğrendiğim derslerden biri şu: tıkandığında kusursuz yapmaya uğraşmak yerine önce bir başlamak önemli
    Başta karmakarışık olsa bile azar azar iyileştirince bir anda net bir resim görünmeye başlıyor. Adeta sihir gibi

    • “Yapmaya değer her şey kötü yapmaya da değer” sözü zor dönemlerde ayakta kalmama yardımcı oldu
    • Bununla ilgili sevdiğim iki tavsiye var
      Biri Dan Harmon’ın writer’s block tavsiyesi,
      diğeri de Ira Glass’ın “The Gap” konuşması
      Özeti şu: mükemmeli bekleme, berbat bir taslak bile olsa yaz, sonra onu eleştirel gözle düzelt
    • Şirketlerde bu yaklaşımı uygularsan bazen tam tersine “artık bırakabilirsin” deniyor ve o yarım sürüm sonsuza kadar öyle kalıyor
      Bu yüzden ben artık bitene kadar bilerek “henüz hazır değil” diyorum
    • Yazılım genelde alpha–beta–release diye üç aşamadan geçiyor
      Ben önce hızlıca yapıyor, sonra toparlıyor, en sonunda da baştan yeniden yazıyorum
      Önemli olan beta aşamasında mükemmeliyetçiliğe kapılmamak
    • İnsan bunu böyle kademeli iyileştirdiğinde olumlu görülüp, LLM yaptığında olumsuz görülmesi ilginç
      Aslında kademeli iyileştirme etkiliyse, bunu insanın mı yoksa AI’ın mı yaptığı çok fark etmez

  • Eski işyerimde yönetime “sorun hayranlık derneği” derdik
    Sorunu konuşmaya, analiz etmeye ve suçlu aramaya odaklanırlardı; ama gerçekten çözmezlerdi
    Sonunda önemli olan gerçekten yapmaktı

    • Tersine, bazı şirketler mevcut çözüme saplanıp kalıyor ve soruna yeniden bakmak istemiyor
      En iyi yaklaşım, sorunun kendisine ilgi duymakla çözümü yinelemeli biçimde üretme isteğini birlikte taşımak
      İçeride bizzat kullanmak anlamındaki dogfooding, bu dengeyi kurmanın iyi bir yolu
    • Sonuçta işi bizzat yapan kişiysen, o karar yetkisini kullanman gerekir
      Mümkün olduğunca kendi lehine karar verebilmek önemli
    • Orta kademe yöneticileri kaldırırsan verimlilik artar
      Güncelleme koordinasyonu azalır ve gerçekten çalışan organizasyon daha verimli olur
    • Sorunu analiz ettikten sonra, hemen şimdi başka bir işe başlaman için bir neden oluştuysa bu da sorun değil

  • Bu yazı, strangestloop.io’daki denemeye çok benziyor

    • Dürüst olayım, neredeyse intihal düzeyinde hissettiriyor
      Başlığı görünce tanıdık geldiğini düşündüm ama tıklayınca başka bir site olduğunu gördüm; üstelik yayın zamanı da birkaç gün öncesiymiş, buna şaşırdım
      İçerik fazla benzer, tesadüf demek zor
    • Ben de bunu nerede gördüğümü çıkaramamıştım ama benzer bir şey okuduğumu hatırlıyordum

  • Eskiden hazırlığın önemli olduğunu düşünürdüm ama bir noktada hazırlığın sonsuz döngüye dönüştüğünü fark ettim
    Bizim ekip iki sayfalık bir spekle ürünü 4 ayda bitirdi, rakip ekip ise 8 ay boyunca sadece belge yazıp dağıldı
    Planlama %20 yapıldığında sorunların %80’ini yakalıyor. Ondan sonrası sadece kaygının ciddiyet kılığına girmesi
    Sonunda, utanılacak bir şeyi ortaya koyup düzelterek öğrendiklerim daha fazla oldu

    • Yazının ana fikrini biraz yanlış anlamış gibisin. “Hazırlık” zaten başlı başına ‘doing the thing değil’ kategorisine giriyor bence
    • Takıma göre değişir. Bizim ekip aylarca plan yapıp yine de iyi bir lansman çıkardı. Sonuçta duruma bağlı
    • Planlamanın getirisi azalır ama çoğu proje yetersiz planlama yüzünden daha kötü hale gelir
    • Red Dwarf’taki Rimmer’ın sınava sadece hazırlanıp sonunda başarısız olduğu sahneyi hatırlattı
      Eski bir HN yorumunda alıntılanmıştı
    • Planlamayı tamamen ortadan kaldırmak da sorunlu. Denge gerekli

  • Analysis paralysis gerçekten var
    Durup kalmamak için önce başlamak gerek. Önce happy path’i hallet, edge case’leri sonra düzeltirsin
    Bugünlerde prototip maliyeti düşük, o yüzden başarısızlıktan korkmadan denemek lazım
    LLM’lerin şaşırtıcı derecede etkili olmasının nedeni de tam olarak bu — analiz yerine hemen uygulamaya geçiyorlar
    Sonuç kusursuz olmasa da çoğu zaman yeterince kullanılabilir oluyor, gerekirse sonra optimize edilir
    Bir framework yapmadan önce en az üç gerçek sistem kurmuş olmalısın. Ancak o zaman nerede fazla, nerede eksik kaldığını anlarsın

    • Ama prototipi gerçek ürün sanmamak gerekir
      “Yeterince iyi” sözü bazen öz kandırma olabilir
      Başarısız bir prototip, piyasada talep olmadığının kanıtı değildir. Sadece bir şeylerin eksik olduğunun işaretidir

  • Bu yazı, önceki gönderiyle neredeyse aynı mesajı taşıyor
    Önceki HN tartışmasında da ele alınmıştı

    • Tartışma o kadar benzer ki dupe (tekrar) olarak işaretlenmesi gerekir

  • Tersinden bakarsak, bazen ‘doing the thing’in kendisi yanlış seçim olabilir
    Bu yüzden ben hâlâ tasarım dokümanları ve code review konusunda ısrarcıyım
    GenAI çağında “plansızca bir şeyler deneyip geçmek” çok kolaylaştı; bu yüzden aynı ölçüde dengeleyici bir ağırlık da gerekiyor

    • Bugünlerde happy path kolaylaştı ama prototip ile production arasındaki fark daha da büyüdü
      Belirsizlik ve latency sorunları bütün zamanı yiyor, sonunda asıl zorluk unit economics’i tutturmak oluyor

  • 『Remains of The Day』 kitabında ‘the thing hakkında konuşmak’ kendini tatmin eden bir eylem olarak anılıyor
    Gerçekte hiçbir şey başarmadan sadece iyi hissettiren konuşmalara dönüşebiliyor

  • Öte yandan, planlama, hazırlık ve mise-en-place gerçek icraya yardımcı olabilir

    • Ama yalnızca gerçekten eyleme dönüştüğünde anlamlıdır. Analiz felcine düşmemek gerekir
    • İnsanlar çoğu zaman planlamayı ya da tartışmayı ‘doing the thing’ sanıyor. Sorun da bu