"Paul Graham'ın 2007’de yazdığı bu makale, programcıların kendi kodları üzerinde yoğun bir şekilde çalışırken aynı zamanda genel bir bakış açısı kazanabilmelerinin önemini anlatıyor. Graham, kodun programcının problemi anlama şeklini yansıttığını ifade ediyor ve programı tamamen kafada canlandırmanın, onu anlamanın en iyi yolu olduğunu savunuyor. Ayrıca, programcıların daha verimli çalışabilmesi için dikkat dağıtıcı unsurlardan kaçınmaları, uzun süreler boyunca odaklanmaları, öz ve güçlü dilleri kullanmaları, kodlarını sürekli yeniden yazmaları, tekrar okunabilir kodlar yazmaları ve küçük gruplar halinde çalışmaları gerektiğini öneriyor.

---

# Bir Programı Kafanızda Tutmanın Gücü ve Yöntemleri (Holding a Program in One's Head)

Ağustos 2007

Gençken, bir matematikçinin üzerinde çalıştığı bir problemi nasıl aklında tuttuğunu merak ederdim. Sonra programcı oldum ve aynı şeyi kendi kodumla yapabildiğimi gördüm. Matematikçiler, okulda öğretilen gibi, soruları kağıt üzerinde çözerek cevaplamazlar. Onlar daha çok kafalarında iş yaparlar: bir problemi o kadar iyi anlarlar ki, çocukluğunda büyüdüğünüz evin hatırasını aklında dolaştırabileceğiniz gibi, o problemi de aynı şekilde anlarlar. İşte programlama da böyle bir şey. Tüm programı aklında tutarsın ve istediğin gibi onu şekillendirirsin.

Bu özellikle bir projenin başında çok değerlidir, çünkü başlangıçta en önemli şey, ne yaptığınızı değiştirebilme yeteneğidir. Sadece probleminizi farklı bir şekilde çözmek değil, çözmeniz gereken problemin kendisini değiştirebilmek.

Kodun, üzerinde çalıştığın problemi anlama şeklin budur. Yani, problemi gerçekten anladığın zaman, kodunu aklında tutarsın.

Bir programı aklına yerleştirmek hiç de kolay olmayabilir. Bir projeyi birkaç ay bıraktıktan sonra, tekrar üzerinde çalışmaya başladığında, onu tam olarak anlamak günler alabilir. Hatta aktif olarak bir program üzerinde çalışırken bile, her gün işe başlarken onu aklına yüklemek yarım saatinizi alabilir. Ve bu en iyi durumdur. Normal şartlarda ofiste çalışan sıradan programcılar bu modda hiç çalışamazlar. Ya da daha dramatik bir ifadeyle, tipik ofis koşullarında çalışan sıradan programcılar, çözdükleri problemleri hiçbir zaman tam olarak anlamazlar.

En iyi programcılar bile üzerinde çalıştıkları tüm programı her zaman aklında tutamazlar. Ancak aşağıdakileri yaparak bu durumu kolaylaştırabilirsiniz:

1. **Dikkat dağıtıcı unsurlardan kaçın.** Dikkat dağıtıcı unsurlar birçok iş türü için kötüdür, ama özellikle programlama için çok daha kötüdür, çünkü programcılar genellikle detayları sınırlarında işlemeye meyillidirler.

Bir dikkat dağıtıcı unsurun tehlikesi, ne kadar sürdüğüne değil, beyninizi ne kadar karıştırdığına bağlıdır. Bir programcı, ofisten çıkıp bir sandviç alabilir ve aklındaki kodu kaybetmez. Ancak yanlış türden bir kesinti, beyninizi 30 saniyede silebilir.

Garip bir şekilde, planlanmış dikkat dağıtıcı unsurlar, planlanmamışlardan daha kötü olabilir. Eğer bir saat sonra bir toplantınız olduğunu biliyorsanız, zor bir şey üzerinde çalışmaya bile başlamazsınız.

2. **Uzun süreler boyunca çalışın.** Bir programa başladığınızda sabit bir maliyet olduğundan, birkaç uzun oturumda çalışmak, birçok kısa oturumdan daha verimli olabilir. Elbette bir noktada, yorgunluktan dolayı aptallaşırsınız. Bu kişiden kişiye değişir. 36 saat boyunca kesintisiz kodlama yapan insanlar duydum, ancak ben en fazla 18 saat boyunca yönetebildim ve en iyi şekilde 12 saatten fazla olmayan sürelerde çalışabiliyorum.

Optimum, fiziksel olarak dayanabileceğiniz sınır değildir. Bir projeyi bölmek de bir maliyet kadar bir avantaj sağlar. Bazen bir soruna bir mola verdikten sonra döndüğünüzde, bilinçaltınızın sizin için bir cevap bıraktığını bulabilirsiniz.

3. **Özlü dilleri kullanın.** Daha güçlü programlama dilleri, programları daha kısa hale getirir. Ve programcılar, onları yazmak için kullandıkları dilde programları düşünürler. Dil ne kadar özlü olursa, program o kadar kısa olur ve aklına yüklemesi ve orada tutması o kadar kolay olur.

Güçlü bir dilin etkisini, alttan yukarıya programlama olarak adlandırılan bir stil kullanarak artırabilirsiniz, burada programları birden çok katmanda yazar, alt katmanlar üstlerindeki programlama dilleri olarak hareket eder. Bunu doğru yaparsanız, sadece en üstteki katmanı aklında tutmanız yeterlidir.

4. **Programınızı sürekli yeniden yazın.** Bir programı yeniden yazmak genellikle daha temiz bir tasarım elde etmenizi sağlar. Ancak bunun avantajları olsun ya da olmasın: bir programı yeniden yazmak için onu tamamen anlamanız gerektiği için, bir programı aklına yüklemenin en iyi yolu budur.

5. **Yeniden okunabilir kod yazın.** Tüm programcılar, okunabilir bir kod yazmanın iyi olduğunu bilir. Ancak siz kendiniz en önemli okuyucu olabilirsiniz. Özellikle başlangıçta; bir prototip, kendinizle olan bir konuşmadır. Ve kendiniz için yazarken farklı öncelikleriniz vardır. Eğer başkaları için yazıyorsanız, kodunuzu çok yoğun hale getirmek istemeyebilirsiniz. Bir programın bazı bölümleri, bir şeyleri yaydığınızda, bir giriş ders kitabı gibi, okuması daha kolay olabilir. Ancak eğer kodu, onu aklına yeniden yüklemeyi kolaylaştırmak için yazıyorsanız, belki de en iyisi kısa olmaktır.

6. **Küçük gruplarda çalışın.** Bir programı aklında manipüle ettiğinizde, görüşünüz genellikle sahip olduğunuz kodun kenarında durur. Diğer bölümleri o kadar iyi anlamazsınız ve daha da önemlisi, onlarla serbestçe oynayamazsınız. Dolayısıyla, programcıların sayısı ne kadar küçük olursa, bir proje o kadar tamamen dönüşebilir. Sadece bir programcı olduğunda, genellikle başlangıçta olduğu gibi, kapsamlı yeniden tasarımlar yapabilirsiniz.

7. **Birden fazla kişi aynı kod parçasını düzenlemesin.** Kendi kodunuzu başkalarının kodları kadar iyi anlamazsınız. Ne kadar dikkatlice okumuş olursanız olun, sadece okumuşsunuzdur, yazmamışsınızdır. Yani bir kod parçası birden fazla yazar tarafından yazıldığında, hiçbiri tek bir yazarın anladığı kadar iyi anlamaz.

Ve tabii ki, başkalarının üzerinde çalıştığı bir şeyi güvenli bir şekilde yeniden tasarlayamazsınız. Sadece izin almanız gerektiği için değil. Böyle şeyleri düşünmeye bile izin vermezsiniz. Birden çok yazarı olan kodu yeniden tasarlamak, yasaları değiştirmek gibidir; tek başına kontrol ettiğiniz bir kodu yeniden tasarlamak, belirsiz bir görüntünün diğer yorumunu görmek gibidir.

Bir projede birkaç kişiyi çalıştırmak istiyorsanız, onu bileşenlere ayırın ve her birini bir kişiye verin.

8. **Küçük başlayın.** Bir programı aklında tutmak, ona aşina olduğunuzda daha kolay hale gelir. Bir şeye tamamen hakim olduğunuz hissini aldığınızda, bazı parçaları siyah kutu olarak ele alabilirsiniz. Ancak bir projeye ilk başladığınızda, her şeyi görmek zorundasınızdır. Eğer çok büyük bir problemle başlarsanız, onu kapsayamayabilirsiniz. Bu yüzden büyük, karmaşık bir program yazmanız gerekiyorsa, belki de başlamak için en iyi yol, bir özellik belgesi yazmak yerine, problemin bir alt kümesini çözen bir prototip yazmaktır. Planlamanın avantajları ne olursa olsun, genellikle bir programı aklında tutabilme avantajları tarafından ağır basılırlar.

Programcıların sıklıkla tüm sekiz noktayı kazara vurdukları dikkat çekicidir. Birinin yeni bir proje fikri vardır, ama resmi olarak onaylanmadığı için, onu saat dışında yapmak zorundadır - ki bu da genellikle dikkat dağıtıcı unsurlar olmadığı için daha verimli olur. Yeni projeye olan hevesiyle, saatlerce kesintisiz bir şekilde üzerinde çalışır. Başlangıçta sadece bir deney olduğu için, bir ""üretim"" dili yerine sadece bir ""betik"" dili kullanır - ki bu aslında çok daha güçlüdür. Programı birkaç kez tamamen yeniden yazar; bu, resmi bir proje için haklı çıkarılamaz, ama bu bir sevgi emeğidir ve onun mükemmel olmasını ister. Ve kimse onu görmeyeceği için, kendine not almak dışında hiçbir yorum eklemiyor. Başlangıçta genellikle olduğu gibi, sadece bir programcı olduğunda, kapsamlı yeniden tasarımlar yapabilirsiniz. Hatta bir grup varsa bile, birkaç kişi aynı kodu düzenleyemez, çünkü kod o kadar hızlı değişir ki bu mümkün olmaz. Ve proje küçük başlar çünkü fikir başlangıçta küçüktür, sadece denemek istediği havalı bir hilesi vardır.

Daha da dikkat çekici olan, resmi olarak onaylanan projelerin tüm sekiz şeyi yanlış yapmayı başarmasıdır. Aslında, çoğu organizasyonda yazılımın nasıl yazıldığına bakarsanız, neredeyse kasıtlı olarak yanlış şeyler yapmaya çalışıyorlar gibi görünür. Bir anlamda, onlar öyledir. Organizasyonların var olduğu süre boyunca belirleyici niteliklerden biri, bireyleri birbirinin yerine geçebilir parçalar olarak ele almaktır. Bu, daha paralel hale getirilebilir görevler için iyi çalışır, örneğin savaşları savaşmak. Tarihin çoğu süresince, iyi bir ordu profesyonel askerler, ne kadar cesur olurlarsa olsunlar, bireysel savaşçıların ordusunu yenmeyi başarabilirdi. Ama fikirlerin oluşması pek paralel hale getirilemez. Ve programlar da fikirlerdir.

Organizasyonların bireysel dahiye bağlı olma fikrini sevmediği sadece gerçek değil, aynı zamanda bir öğretidir. Bir organizasyonun tanımının bir parçası olmamaktır. Mevcut organizasyon kavramımızın bir parçası, en azından.

Belki bireylerin çabalarını birleştirebilen, ancak onların birbirinin yerine geçebilir olmasını gerektirmeyen yeni bir tür organizasyon tanımlayabiliriz. Argüman olarak bir pazarın böyle bir organizasyon biçimi olduğunu söyleyebiliriz, ancak bir pazarı bir bozuk durum olarak tanımlamak daha doğru olabilir - organizasyon mümkün olmadığında varsayılan olarak elde ettiğiniz şey.

Muhtemelen en iyisi, bir organizasyonun programlama parçalarının geri kalanından farklı bir şekilde çalışmasını sağlamak gibi bir hile yapmaktır. Belki de büyük şirketlerin bile içeride fikir geliştirmeye çalışmaması ve basitçe onları satın alması en iyi çözüm olabilir. Ancak ne olursa olsun çözümün ne olduğu, ilk adımın bir problemin var olduğunu fark etmek olduğudur. ""Yazılım şirketi"" ifadesinde bir çelişki vardır. Herhangi bir büyük organizasyonda iyi bir programcı, ona karşı olacaktır, çünkü organizasyonlar, programcıların çabaladığı şeyi önlemek için tasarlanmıştır.

İyi programcılar yine de çok şey başarır. Ancak genellikle onları istihdam eden organizasyonlara karşı neredeyse bir isyan eylemi gerektirir. Programcıların davranış biçimlerinin, yaptıkları işin gereklilikleri tarafından yönlendirildiğini daha fazla insanın anlaması belki de yardımcı olacaktır. Diğer tüm yükümlülüklerini ihmal ederek uzun süreli aşırı çalışma dönemlerinde bulunmaları, özelliklerin öncelikle yazılması yerine hemen programlamaya dalınması ve zaten çalışan kodun yeniden yazılması, onların sorumsuz olmaları nedeniyle değil. Birine merhaba demek için kapılarına başlarını sokan insanlara hırçın davranmaları veya yalnız çalışmayı tercih etmeleri, onların dostça olmamaları nedeniyle değil. Bu rastgele toplanmış sinir bozucu alışkanlıkların tek bir açıklaması vardır: bir programı aklında tutmanın gücü.

Bu durumu anlamanın büyük organizasyonlara yardımcı olup olmayacağını bilmiyorum, ancak kesinlikle onların rakiplerine yardımcı olabilir. Büyük şirketlerin en zayıf noktası, bireysel programcılara büyük işler yapma fırsatı vermemeleridir. Yani eğer küçük bir startup'sanız, onlara saldırmanız gereken yer burasıdır. Tek bir büyük beyinde çözülmesi gereken türden problemleri ele alın.

Bu yazının taslağını okuyup değerlendiren Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev ve Stephen Wolfram'a teşekkürler.

---

İlişkili Konseptler: programlama teknikleri, bir programı zihinde tutma, verimli kodlama uygulamaları, programlama dikkat dağıtıcılarından kaçınma, uzun süreli programlama, öz programlama dilleri, kod yeniden yazma, tekrar okunabilir kod, küçük grup programlama, tek yazar kodu, programlamaya küçük başlama, küçük startuplarda programlama, büyük organizasyonlarda programlama, programlama problem çözme, alttan yukarı programlama, prototip programlama, programlama verimliliği, programlama konsantrasyonu, programlama ve problem anlama."