"Paul Graham'ın 2003 tarihli bu makalesinde, bilgisayar programlamayı (hacking) ve resim yapmayı karşılaştırıyor. İkisinin de yaratıcı süreçler olduğunu ve birbirlerine benzerlikler taşıdığını belirtiyor. Her iki süreçte de, eserin mükemmelleştirilmesi ve son kullanıcının ihtiyaçlarının anlaşılması gerektiğini ifade ediyor. Ayrıca, yazılımın sadece makinelere değil, aynı zamanda insanlara da hitap etmesi gerektiğini, bu yüzden yazılımcıların empati yeteneğine sahip olmaları gerektiğini savunuyor. Graham, yazılım tasarımının gelecekte ne kadar 'havalı' olacağının bu yeni medyayla neler yapabileceğimize bağlı olduğunu belirtiyor.

---

# Yazılım Geliştiriciler ve Ressamlar: Yaratıcı Süreçlerin Karşılaştırılması (Hackers and Painters)

Mayıs 2003

_(Bu yazı, Harvard'da verdiğim bir konuk dersinden ve daha önce Northeastern Üniversitesi'nde yaptığım bir konuşmadan derlenmiştir.)_

Bilgisayar bilimleri üzerine yüksek lisansımı tamamladıktan sonra biraz farklı bir rotaya girdim ve resim öğrenmek için sanat okuluna kaydoldum. Bilgisayarlara olan merakım, aynı zamanda resme de ilgi duyabileceğim fikri birçok kişiyi şaşırttı. Onlara göre, kod yazmak ve resim yapmak birbirinden tamamen farklı dünyalardı. Kod yazmak soğuk, kesin ve düzenliyken, resim yapmak ise içgüdülerin coşkulu bir dışavurumuydu.

Ama aslında her iki düşünce de yanlıştı. Hackerlik ve resim yapmak arasında birçok ortak nokta vardı. Aslında, tanıdığım pek çok farklı insan türü içinde, hackerlar ve ressamlar belki de en çok birbirine benzeyenlerdi.

Hacker'lar ve ressamların ortak noktası, ikisinin de birer 'yaratıcı' olmasıydı. Besteciler, mimarlar ve yazarlarla birlikte hacker'lar ve ressamların amacı, güzel şeyler yaratmaktı. Aslında direkt olarak araştırma yapmıyorlardı; ama güzel şeyler yaratırken yeni bir teknik keşfederlerse, bu durum onlar için bir artı oluyordu.


""Bilgisayar bilimi"" terimi hiç hoşuma gitmiyordu. En büyük sebep? Aslında böyle bir şey yoktu. Bilgisayar bilimi, Yugoslavya'ya benzer şekilde, tarihin bir tesadüfü sonucu bir araya gelmiş, birbiriyle zayıf ilişkili alanların karışımıydı. Bir uçta, aslında matematikçiler olan ama çalışmalarını bilgisayar bilimi olarak adlandırıp DARPA hibeleri kapabilen insanlar vardı. Orta kısımda, ağlardan veri yönlendirmek gibi konularda algoritma davranışlarını inceleyen, bilgisayarların doğa tarihini araştıran kişiler bulunuyordu. Diğer uçta ise, ilginç yazılımlar yazmayı hedefleyen ve bilgisayarları, mimarlar için olduğu gibi beton veya ressamlar için boya gibi bir ifade aracı olarak kullanan hackerlar vardı. Bu durum, sanki matematikçiler, fizikçiler ve mimarlar aynı bölümdeymiş gibi bir şeydi.

Bazen hackerların yaptıkları ""yazılım mühendisliği"" olarak adlandırılır, ama bu isim oldukça yanıltıcıdır. İyi yazılım tasarımcıları, mimarların mühendis olduğundan daha çok mühendis değiller. Mimarlık ve mühendislik arasındaki sınır keskin bir şekilde belirlenmiş değil ama var. Bu sınır, 'ne yapılacağı' ve 'nasıl yapılacağı' arasında duruyor: Mimarlar ne yapacaklarına karar verir, mühendisler ise bunu nasıl yapacaklarını çözerler.


'Ne' ve 'nasıl'ı çok ayrı tutmamalıyız. Nasıl yapılacağını anlamadan ne yapacağına karar verirsen, başın belaya girersin. Ama kodlama, sadece bir şeyin nasıl uygulanacağına karar vermekten daha fazlası olabilir. En iyi haliyle, aslında spesifikasyonları yaratmaktır - ve bunu yapmanın en iyi yolu, onları uygulamaktır.

Belki bir gün ""bilgisayar bilimleri"", Yugoslavya gibi, parçalara ayrılır. Bu, iyi bir şey olabilir. Özellikle de benim doğduğum toprak, 'hacklemek', bağımsız olursa.

Bir departmanda tüm bu farklı türdeki işleri birleştirmek yönetim açısından kolay olabilir, ama zihinsel açıdan karmaşıklığa yol açıyor. İşte bu, ""bilgisayar bilimleri"" adını neden sevmediğimin bir diğer sebebi. Belki ortadaki kişiler, deneysel bir bilim yapmış olabilir. Ancak iki uçtaki kişiler, hackerlar ve matematikçiler, aslında bilim yapmıyorlar.

Matematikçiler bu durumdan pek rahatsız olmuyor gibi görünüyor. Diğer matematikçilerle birlikte teoremleri kanıtlamaya başlıyorlar ve muhtemelen çok geçmeden, çalıştıkları binanın dışında ""bilgisayar bilimleri"" yazdığını unutuyorlar. Ancak yazılımcılar için bu durum bir sorun teşkil ediyor. Yaptıkları işin adı 'bilim' olunca, kendilerini bilimsel olarak davranmaya mecbur hissediyorlar. Bu yüzden, gerçekten yapmak istedikleri şey olan güzel yazılımlar tasarlama yerine, üniversite ve araştırma laboratuvarlarında çalışan yazılımcılar, kendilerini araştırma makaleleri yazmaya yönlendiriyorlar.

En iyi ihtimalle, makaleler sadece bir formalite. Hackerlar önce havalı bir yazılım yazıyor, sonra bunun hakkında bir makale yazıyorlar ve bu makale, yazılımın temsil ettiği başarıyı ifade ediyor. Ancak genellikle bu durum sorunlara yol açıyor.Bazen, güzel şeyler yapmak yerine, araştırma makaleleri için daha uygun olacak çirkin şeyler yapmaya başlayabiliriz. Bu durum, güzellik kavramının her zaman iyi bir makale konusu olmamasından kaynaklanır. Araştırma yaparken, özgün ve zengin konular bulmak önemlidir. Bir doktora tezi yazan herkes, ilgi çekmeyen bir alanda çalışmanın, keşfedilmemiş bir konu bulmanın en iyi yol olduğunu bilir. Ayrıca, araştırmanın zengin olması da önemlidir. Karmaşık sistemler, karşılaşılan zorluklar ve bunların nasıl aşıldığı hakkında daha detaylı makaleler, daha ilgi çekici olabilir. 

Bir şeyi güzel hale getirmenin genellikle, zaten var olan bir şeye ince ayarlar yapmaktan veya mevcut fikirleri biraz yeni bir şekilde birleştirmekten geçtiğini unutmayalım. Ancak, bu tür bir çalışmayı bir araştırma makalesine dökmek pek kolay olmayabilir.

Üniversiteler ve araştırma laboratuvarları neden hala hackerları yayınlarına göre değerlendiriyor, diye düşünebilirsiniz. Bu durum, ""akademik yetenek"" kavramının sıradan standart testlerle ölçülmesi veya bir yazılımcının verimliliğinin kod satırı sayısıyla ölçülmesi gibi durumlara benzer. Bu testlerin uygulanması kolay ve bir ölçüde işe yarıyor olmaları, onları cazip kılıyor.

Hacker'ların gerçekte ne yapmaya çalıştığını ölçmek, yani güzel bir yazılım tasarlamak, çok daha zor bir iş. İyi bir tasarımı değerlendirebilmek için iyi bir tasarım anlayışına sahip olmanız gerekiyor. Ve aslında, insanların iyi bir tasarımı tanıma yetenekleri ile kendilerine olan güvenleri arasında hiçbir ilişki yok. Hatta belki de ters yönde bir ilişki var.

Tek dışsal ölçüt zamanın ta kendisi. Zaman geçtikçe, güzel olan şeyler genellikle büyür ve çirkin olanlar genellikle kenara atılır. Maalesef, burada bahsettiğimiz zaman dilimleri genellikle bir insan ömründen daha uzun olabilir. Samuel Johnson, bir yazarın itibarının yerine oturması için yüz yıl gerektiğini söylemiştir. İlk olarak yazarın etkili dostlarının, ardından da onların tüm takipçilerinin hayata veda etmesini beklemek gerekiyor.

Bence hackerların, itibarlarında büyük oranda rastgelelik olduğunu kabullenmeleri gerekiyor. Bu konuda diğer yaratıcı mesleklerle aynı kefeye koyabiliriz onları. Hatta, bir kıyaslama yapılırsa, hackerlar daha da şanslılar. Modanın etkisi, resim sanatındaki kadar güçlü değil çünkü hackleme dünyasında.

İnsanların yaptığınız işi yanlış anlamasından daha kötü durumlar da var. Asıl büyük tehlike, kendi yaptığınız işi bile yanlış anlamak. Yeni fikirler aradığınız yerler genellikle ilgili alanlardır. Kendinizi bilgisayar bilimleri bölümünde bulduğunuzda, örneğin, kod kırma işinin aslında teorik bilgisayar bilimlerinin uygulamalı bir hali olduğuna inanmaya doğal olarak meyilli olabilirsiniz. Yüksek lisansımı yaparken sürekli aklımın bir köşesinde, teorik bilgi konusunda daha fazla bilgi sahibi olmam gerektiği ve final sınavından sadece üç hafta sonra tüm bu bilgileri unuttuğum için kendimi suçlu hissettiğim bir duygu vardı.

Şimdi yanıldığımı anlıyorum. Hackerların, hesaplama teorisini anlamaları gerekiyor, tıpkı ressamların boya kimyasını anlamaları gerektiği gibi. Zaman ve mekan karmaşıklığını nasıl hesaplayacağınızı ve Turing tamamlığı hakkında bilgi sahibi olmanız gerekiyor. Bir parser ya da düzenli ifade kütüphanesi yazarken, bir durum makinesi kavramını hatırlamak da işe yarayabilir. Gerçekte, ressamların boya kimyası hakkında hatırlaması gereken çok daha fazla şey vardır.

Fikirlerin en iyi kaynağının, adında ""bilgisayar"" geçen diğer alanlar değil, yaratıcıların yaşam alanı olan diğer disiplinler olduğunu keşfettim.Resim, hesaplama teorisinden daha fazlasını sunar. Bu, bir programı bilgisayar başında değil, kağıt üzerinde çözmek zorunda olduğumuzu öğrettiğinde anladığım bir şey. Ama benim tarzım bu değildi. Ben, program yaparken kendimi bir bilgisayarın önünde, bir kağıt karşısında değil, tam da o an programı yazarken buluyordum. Daha da kötüsü, tam ve doğru bir program yazmak için sabırla vakit harcamak yerine, genellikle umutsuzca hatalarla dolu kodlar yazıyor ve bunları yavaş yavaş düzeltiyordum. Hata ayıklama, yazım hatalarını ve gözden kaçanları yakaladığınız son bir kontrol olduğu öğretilmişti bana. Ama benim çalışma şeklimde, sanki programlama tamamen hata ayıklama işlemiydi.

Bu yüzden uzun bir süre kendimi kötü hissettim, tıpkı ilkokulda kalemi doğru tutamadığım için hissettiğim gibi. Eğer diğer yaratıcı insanlara, ressamlara ya da mimarlara bakmış olsaydım, aslında benim de yaptığım şeyin bir adı olduğunu fark ederdim: eskiz yapmak. Anladığım kadarıyla, üniversitede bana öğretilen programlama şekli tamamen yanlış. Programları yazarken onları anlamalı ve şekillendirmelisiniz, tıpkı bir yazarın, ressamın ya da mimarın yaptığı gibi.

Bu, yazılım tasarımı için gerçek sonuçlar doğuruyor. Öncelikle, bir programlama dilinin esnek olması gerektiği anlamına geliyor. Bir programlama dili, zaten düşündüğünüz programları ifade etmek yerine, programları düşünmek için olmalı. Kalem gibi olmalı, tükenmez kalem gibi değil. Statik tiplemeyi kullanma fikri, eğer insanlar programları bana üniversitede öğrettikleri gibi yazsaydı harika olabilirdi. Ama tanıdığım hiçbir yazılımcı bu şekilde program yazmıyor. Sıkı bir derleyici teyzemizle nazik sohbetler yaparken dizimizde dengeli bir tipler fincanıyla oturmak zorunda kalmayacağımız, karalama, lekeleme ve bulanıklık yapmamıza izin veren bir dile ihtiyacımız var.

Statik yazma konusunda konuşurken, yaratıcılarla aynı çizgide düşünmek bizi bilimlerde sıkça karşılaşılan bir sorundan kurtarabilir: matematik kıskançlığı. Bilim insanlarının çoğu, gizlice matematikçilerin kendilerinden daha zeki olduğunu düşünür. Matematikçilerin de bu konuda aynı fikirde olduklarını düşünüyorum. Sonuç olarak, bilim insanları çalışmalarını olabildiğince matematiksel göstermeye çalışırlar. Belki fizik gibi bir alan bu durumdan çok etkilenmez ancak doğa bilimlerinden uzaklaştıkça, bu durum daha büyük bir soruna dönüşebilir.

Formüllerle dolu bir sayfanın görüntüsü gerçekten de çok etkileyici olabiliyor. (Küçük bir ipucu: daha da etkileyici olması için Yunanca değişkenler kullanın.) İşte bu yüzden, diyelim ki önemli olan sorunlardan ziyade, formülle çözülebilen sorunlara yoğunlaşma eğiliminde oluyoruz.

Eğer hackerlar kendilerini yazarlar ve ressamlar gibi diğer yaratıcılarla aynı tutarlarsa, bu tür bir duruma hiç bulaşmazlar. Yazarlar ve ressamlar matematik kıskançlığına kapılmazlar. Kendilerinin tamamen farklı bir şey yaptıklarını hissederler. Bence hackerlar da tamamen aynı durumda.

Eğer üniversiteler ve araştırma labaratuvarları, hackerların yapmak istedikleri işi yapmalarını engelliyorsa, belki de onların yeri şirketlerdir. Ne yazık ki, çoğu şirket de hackerlara kendi istedikleri gibi hareket etme özgürlüğü sağlamaz. Üniversite ve araştırma laboratuvarları hackerları birer bilim insanı gibi davranmaya zorlar, şirketler ise onları mühendis gibi çalışmaya iter.

Bu durumu kendim de oldukça yeni fark ettim. Yahoo, Viaweb'i satın aldığında ne yapmak istediğimi sordu. İş dünyası hiçbir zaman ilgimi çekmemişti, ben sadece yazılım yapmak istedim. Ancak Yahoo'ya geldiğimde, onların yazılım yapmak dediği şeyin, yazılım tasarlamak değil, onu uygulamak olduğunu anladım. Programcılar, ürün yöneticilerinin vizyonlarını (eğer öyle diyebilirsek) kodlara çeviren teknisyenler olarak görülüyordu.

Bu, büyük şirketlerin genellikle başvurduğu bir yöntem gibi görünüyor. Sonuçların belirsizliğini azalttığı için bu yolu seçiyorlar.Yazılım tasarlayabilen hackerların sayısı gerçekten de çok az. Bu yetenekli kişileri bulmak, şirket yöneticileri için gerçek bir zorluk olabilir. Bu yüzden birçok şirket, yazılımın geleceğini tek bir dahi hacker'a bırakmak yerine, tasarımı bir komitenin yapmasını ve hackerların bu tasarımı hayata geçirmesini tercih ediyor.

Eğer bir noktada para kazanmayı düşünüyorsanız, bunu aklınızda tutun. Çünkü bu startup'ların neden başarılı olduğunun sebeplerinden biri budur. Büyük şirketler, başarısızlıklardan kaçınmak istedikleri için tasarım sonuçlarının değişkenliğini azaltmaya çalışır. Ancak bu dalgalanmaları sönümlerken, hem zirveleri hem de dipleri kaybedersiniz. Bu, büyük şirketler için bir problem teşkil etmez, çünkü onlar mükemmel ürünler yaparak değil, diğer büyük şirketlerden biraz daha az hata yaparak kazanırlar.

Eğer ürün yöneticileri tarafından tasarlanan bir yazılıma sahip büyük bir şirketle tasarım savaşına girebilecek bir yol bulabilirseniz, onlar sizinle ayak uyduramazlar. Ancak, bu tür fırsatları bulmak kolay olmamakla birlikte, bir kalede bir rakiple yakın dövüşe girmek kadar zor. Örneğin, Microsoft Word'den daha iyi bir kelime işlemci yazmak oldukça kolay olabilir. Fakat işletim sistemi tekelindeki kalelerinde olan Microsoft, sizin daha iyi bir ürün yarattığınızı bile farketmeyebilir.

Tasarım savaşlarını kazanmanın yeri, henüz kimsenin el atmadığı, kalelerini kurmadığı yeni pazarlardır. İşte burada, cesur bir tasarım anlayışına sahip olmak ve aynı kişilerin hem tasarımı hem de ürünü hayata geçirmesi, büyük bir başarıyı beraberinde getirebilir. Microsoft da başladığında bunu yaptı. Apple ve Hewlett-Packard da. Başarılı her startup'ın bu yolu izlediğini tahmin ediyorum.

Harika bir yazılım yapmanın bir yolu kendi startup'ınızı başlatmaktır. Ancak bu durumda iki problemle karşılaşabilirsiniz. Birincisi, bir startup'ta yazılım yazmaktan çok daha fazla iş yapmanız gerekiyor. Viaweb'deyken, zamanımın sadece çeyreğinde kod yazabildiysem kendimi şanslı sayardım. Geri kalan zamanımda ise genellikle sıkıcı ya da korkutucu işlerle meşgul olurdum. Ne demek istediğimi anlamanız için bir örnekle açıklayayım; bir keresinde diş çürüklerimi doldurtmak için bir toplantıyı terk etmek zorunda kalmıştım. Dişçi koltuğunda, matkap sesini beklerken, kendimi tatilde gibi hissetmiştim.

Start-up'larla ilgili bir diğer sorun, para kazandıran yazılımlarla yazması keyifli olan yazılımlar arasında pek bir benzerlik olmaması. Programlama dilleri yazmak eğlenceli olabilir, Microsoft'un ilk ürünü de bir programlama diliydi aslında, fakat artık kimse programlama dilleri için para ödemiyor. Para kazanmak istiyorsan, genellikle kimse bedava çözmeye yanaşmadığı, oldukça zorlu problemlerle uğraşmak zorunda kalıyorsun.

Bu sorun her üreticiyi etkiler. Fiyatlar arz ve talep tarafından belirlenir ve iş üzerinde eğlenilecek şeyler için, tek tek müşterilerin sıradan sorunlarını çözen şeylere göre daha az talep var. Off-Broadway oyunlarında oynamak, bir ticaret fuarında birinin standında goril kostümü giymekten daha az kazandırıyor. Roman yazmak, çöp öğütücüler için reklam metni yazmaktan daha az para getiriyor. Ve programlama dilleriyle oynamak, bir şirketin eski veritabanını web sunucusuna bağlama işinden daha az kazanç sağlıyor.

Bu sorunun cevabının, yazılım örneğinde, neredeyse tüm yaratıcıların bildiği bir kavramda yattığını düşünüyorum: gündüz işi. Bu ifade, genellikle gece sahne alan müzisyenlerle ilişkilendirilir. Daha geniş bir çerçevede bakacak olursak, paranızı kazandığınız bir işinizin ve sevdiğiniz için yaptığınız başka bir işinizin olduğunu ifade eder.

Kariyerlerinin başında neredeyse tüm yaratıcılar gündelik işlerde çalışırlar. Ressamlar ve yazarlar bunun tipik örnekleridir. Şanslıysanız, asıl uğraştığınız işle bağlantılı bir gündelik iş bulabilirsiniz. Müzisyenlerin sıklıkla plak dükkanlarında çalıştığını görürüz. Bir programlama dili ya da işletim sistemi üzerinde çalışan bir yazılımcı da, bu konuda bir iş bulabilir.[1]

Birazdan okuyacağınız, hack'lerin gündüz işlerinde çalışıp, yanlarında harika yazılımlar üzerinde çalışmasının neden bu kadar önemli olduğunu anlatan bir yazı. Bu fikrin yeni olduğunu iddia etmiyorum, çünkü bu, açık kaynaklı hacklemenin tam da ne olduğudur. Açık kaynak kodunun muhtemelen doğru model olduğunu söylemek, çünkü bu diğer tüm üreticiler tarafından da bağımsız olarak teyit edilmiştir.

Herhangi bir işverenin, programcıların açık kaynaklı projeler üzerinde çalışmasına izin vermek konusunda tereddüt etmesi bana oldukça şaşırtıcı geliyor. Bizim şirketimiz Viaweb'de, açık kaynaklı projeler üzerinde çalışmayan birini işe almayı düşünmezdik bile. Bir programcıyı işe alırken en çok önemsediğimiz şey, boş zamanlarında hangi tür yazılımlar geliştirdikleriydi. Bir şeyi gerçekten iyi yapabilmeniz için onu sevmeniz gerekir, ve eğer kod yazmayı seviyorsanız, kaçınılmaz olarak kendi projeleriniz üzerinde çalışıyor olacaksınız.

Hackerlar aslında bilim insanlarından çok, yaratıcılar. Bu yüzden metaforlar için bakmamız gereken yer bilimler değil, diğer yaratıcı alanlar. Peki ya resim, bize hackerlık konusunda neler öğretebilir acaba?

Resim yapma örneği, hacklemeyi nasıl öğreneceğimizi en azından doğrulamamıza yardımcı olabilir. Resim yapmayı çoğunlukla uygulayarak öğreniriz. Hacklemek de aynı şekilde. Çoğu hacker, üniversite programlama derslerine katılarak hacklemeyi öğrenmez. Onlar 13 yaşında kendi programlarını yazmaya başlayarak hacklemeyi öğrenirler. Üniversite derslerinde bile, çoğunlukla hackleme yaparak hacklemeyi öğrenirsiniz. [3]

Ressamlar, arkalarında bir eserler izi bıraktıkları için, onların 'yaparak öğrenme' sürecini izleyebiliriz. Bir ressamın çalışmalarına kronolojik sırayla baktığınızda, her bir tablonun öncekilerden edinilen bilgi ve tecrübeler üzerine inşa edildiğini görürsünüz. Bir tabloda çok başarılı bulduğunuz bir detay varsa, genellikle bu detayın ilk sürümünü, daha önceki bir tabloda daha basit bir haliyle bulabilirsiniz.

Bence çoğu üretici bu şekilde çalışır. Yazarlar ve mimarların da bu şekilde çalıştığı görülüyor. Hackerların da ressamlar gibi davranıp, bir projede yıllarca çalışmak yerine, düzenli olarak her şeyi baştan başlaması belki daha iyi olabilir.

Hackerların hacklemeyi yaparak öğreniyor olması, onların bilimden ne kadar farklı olduğunu gösteriyor. Bilim insanları, bilimi deneyler ve problem setleri çözerek öğrenirler, doğrudan yaparak değil. Onların işi başlangıçta mükemmeldir çünkü sadece başkalarının zaten yaptığı işleri tekrar ederler. Sonunda, kendi özgün çalışmalarını yapabilecek hale gelirler. Fakat hackerlar, baştan itibaren özgün işler yaparlar; sadece işleri çok kötüdür başlarda. Yani, hackerlar özgün olarak başlar ve iyi olurlar; bilim insanları ise iyi olarak başlar ve sonunda özgün olurlar.

Yaratıcıların öğrenme biçimlerinden biri de örneklerden ders çıkarmaktır. Bir ressam için bir müze, tekniklerin referans kütüphanesi gibidir. Yüzlerce yıldır, büyük ustaların eserlerini kopyalamak ressamların geleneksel eğitiminin bir parçası olmuştur. Çünkü bir eseri kopyalamak, resmin nasıl yapıldığını yakından incelemeyi gerektirir.

Yazarlar da aynı yöntemi kullanır. Benjamin Franklin, Addison ve Steele'in denemelerindeki noktaları özetleyerek ve sonra onları yeniden yazmayı deneyerek yazmayı öğrendi. Raymond Chandler da dedektif hikayeleri için aynı taktiği uyguladı.

Hackler, yani bilgisayar programlama konusunda yetenek sahibi insanlar da, iyi programlara bakarak - yani hem ne yaptıklarını hem de onların kaynak kodlarını inceleyerek - programlamayı öğrenebilirler. Açık kaynak hareketinin genellikle pek dile getirilmeyen avantajlarından biri, programlamayı öğrenmeyi daha kolay hale getirmesidir. Ben programlamayı öğrendiğimde, genellikle kitaplardaki örnekler üzerinden ilerlerdik. O dönemde ulaşılabilir olan tek büyük kod parçası Unix'ti, ama o bile açık kaynaklı değildi.Kaynak kodunu okuyanlar, genellikle 1977 yılında yazılmış olmasına rağmen 1996 yılına kadar yayınlanmasına izin verilmeyen John Lions'ın kitabının kaçak fotokopilerini okuyordu. Bu, bir nevi ""yazılım tarihi"" dersi gibiydi. 

Resim sanatı da bize benzer bir ders verir. Bir tablo, genellikle bir taslakla başlar. Zaman içinde detaylar eklenir, renkler belirginleşir ve tablo şekillenir. Ancak bu süreç, sadece boşlukları doldurmakla sınırlı değildir. Bazen ilk taslak yanıltıcı olabilir. Röntgen ile bakıldığında, pek çok tablonun aslında hareket ettirilmiş kollar veya düzeltilmiş yüz özellikleri gibi detayları barındırdığını görürüz. 

Bu durum, bence yazılım hacklemek için de geçerli. Bir programın özelliklerinin tamamen kusursuz olacağını beklemek gerçekçi değil. Daha baştan bunu kabullenip, özelliklerin gerektiği gibi değiştirilebileceği bir şekilde program yazmak daha iyi olur. 

(Büyük şirketlerin yapısı bu işi onlar için zorlaştırıyor, işte bu yüzden startup'lar burada avantajlı.)

Artık herkesin erken optimizasyonun tehlikelerini bildiğini düşünüyorum. Bence, bir programın ne yapması gerektiğine erken karar verme, yani 'erken tasarım' konusunda da aynı şekilde endişe etmeliyiz.

Doğru araçlar, bu türden tehlikeleri bertaraf etmemize yardımcı olabilir. İyi bir programlama dili, yağlı boya gibi, aklınızı değiştirmeyi kolay kılar. Dinamik yazım burada kazançlı çıkıyor çünkü baştan belirli veri gösterimlerine bağlı kalmak zorunda değilsiniz. Ancak bence esnekliğin sırrı, dilin mümkün olduğunca soyut olmasında yatıyor. Değiştirmesi en kolay olan program, genellikle en kısa olanıdır.

Bu bir paradoks gibi görünebilir ama gerçekten iyi bir resim, olması gerektiğinden daha iyi olmalı. Bir örnek vermek gerekirse, Leonardo, Ulusal Galeri'de sergilenen Ginevra de Benci'nin portresini çizerken, onun arkasına bir ardıç ağacı ekledi. Ardıç ağacının her bir yaprağını tek tek, büyük bir özenle çizdi. Birçok ressam belki de ""Bu sadece arka planda, kadının başını çerçevelemek için bir detay. Kimse bunu bu kadar yakından inceler mi ki?"" diye düşünmüş olabilir.

Leonardo değil. Bir resmin bir kısmında ne kadar çok çalışacağını, insanların o kısmı ne kadar yakından inceleyeceği hiç etkilemezdi. Tam bir Michael Jordan'dı. Durmak bilmezdi.

Azim kazanır çünkü, toplamda bakıldığında, görünmeyen detaylar ortaya çıkar. İnsanlar Ginevra de Benci'nin portresinin yanından geçerken, genellikle Leonardo da Vinci'nin adını etikette görmekten önce, bu tablo hemen dikkatlerini çeker. Bu görünmeyen detaylar bir araya gelip, binlerce zar zor duyulan sesin uyumlu bir şekilde şarkı söylediği gibi, tamamen büyüleyici bir şey oluşturur.

Harika bir yazılım, güzelliğe fanatikçe bağlı olmayı gerektirir. İyi bir yazılımın içine baktığınızda, kimse tarafından görülmesi beklenmeyen kısımların da ne kadar güzel olduğunu görürsünüz. Kendi yazdığım yazılımların harika olduğunu söylemiyorum, ama kodlama söz konusu olduğunda, eğer günlük hayatta da aynı şekilde davranırsam, bana reçeteli ilaç yazılabilirdi. Kötü biçimlendirilmiş veya çirkin değişken adlarına sahip kodlar beni deli eder.

Eğer bir hacker, sadece kod yazan bir uygulayıcıysa, bir projeyi başından sonuna kadar, birisi hendek kazıyormuş gibi ilerletir. Ancak, eğer hacker bir yaratıcıysa, o zaman ilhamı da hesaba katmalıyız.

Hacklemek, resim yapmak gibi, döngüler halinde ilerler. Bazen yeni bir projeye öylesine tutulursunuz ki, günde on altı saatini ona ayırmak istersiniz. Ancak bazı zamanlarda da hiçbir şey ilginizi çekmez.

İyi bir iş yapabilmenin yolu, bu döngüleri göz önünde bulundurmaktan geçer çünkü sizin bu döngülere nasıl tepki verdiğiniz, onları doğrudan etkiler. Manuel vitesli bir araba ile yokuşta giderken, aracın stop etmemesi için bazen debriyajdan ayağınızı çekmeniz gerektiğini bilirsiniz. Bu durum, hırsınızın önüne geçmekte de işe yarayabilir. Hem resim yaparken hem de kod yazarken, bazı görevler korkutucu derecede iddialı olabilirken, diğerleri sizi rahatlatacak kadar rutin olabilir.Motivasyonumuz düştüğünde, bazen basit görevlere odaklanmak en iyi strateji olabilir. Bu görevler, bize hedeflerimize doğru ilerlediğimizi hissettirir ve enerjimizi yeniden yükseltir.

Hackerlık dünyasında ise, hataları biriktirmek tam anlamıyla bir sanat haline gelir. Ben hata ayıklamayı seviyorum çünkü bu, yazılımcılığın aslında insanların düşündüğü kadar basit olmadığı tek zamandır. Karşınıza tamamen belirlenmiş bir sorun çıkar ve tek yapmanız gereken onu çözmektir. Programınızın x işlemi yapması gerekiyor, ama y işlemi yapıyor. Peki, nerede hata yapıyor? Sonunda kazanacağınızı biliyorsunuz. Bu, bir duvar boyamak kadar rahatlatıcı olabilir.

Resim sanatı da, hem kendi işimizi nasıl yöneteceğimizi hem de nasıl birlikte çalışacağımızı öğrenebileceğimiz önemli bir kaynaktır. Geçmişin büyük sanat eserlerinin çoğu, birkaç kişinin elinden çıkmıştır, ancak müzede eserlerin yanında genellikle tek bir isim bulunur. Leonardo, Verrocchio'nun atölyesinde çırakken, 'Mesih'in Vaftizi' adlı eserindeki meleklerden birini boyamış. Bu tür işbirlikleri aslında normdu, istisna değil. Örneğin, Michelangelo'nun Sistine Şapeli'nin tavanındaki tüm figürleri tek başına boyama ısrarı onun olağanüstü adanmışlığının bir göstergesi olarak kabul edilmiştir.

Bildiğim kadarıyla, ressamlar bir tablo üzerinde birlikte çalıştıklarında, asla aynı yerleri boyamazlar. Genellikle usta, ana karakterleri boyar ve yardımcıları ise geri kalan figürleri ve arka planı boyar. Ancak hiçbir zaman bir ressam, diğerinin çalışmasının üzerine boyama yapmaz.

Bence bu, yazılımda işbirliği için de geçerli olan bir model. İşleri gereğinden fazla zorlamayın. Bir kod parçasını üç veya dört kişi aynı anda düzenlemeye çalışırsa ve bu kişilerden hiçbiri kodun gerçek sahibi değilse, sonuç genellikle karışık ve dağınık olur, sanki herkesin girip çıktığı bir bekleme salonuna dönüşür. Bence, işbirliği yapmanın en doğru yolu, projeleri net bir şekilde tanımlanmış modüllere ayırmak, her modülün belirli bir sahibi olmasını sağlamak ve bu modüller arasındaki bağlantıları mümkün olduğunca dikkatli bir şekilde tasarlamaktır, hatta mümkünse bu bağlantıları bir programlama dili kadar detaylı ve belirgin hale getirmektir.

Resim yapmak gibi, çoğu yazılım da insanlar için tasarlanır. Bu sebeple, hackerlar da, ressamlar gibi, gerçekten harika işler yapabilmek için empati sahibi olmalıdırlar. Kullanıcının bakış açısını anlamalısınız.

Çocukken sürekli bana başkalarının bakış açısından bakmayı öğütlerlerdi. Pratikte bu her zaman, benim ne istediğim yerine, başkasının ne istediğini yapmam anlamına geliyordu. Bu durum, empatiye pek de iyi bir ün kazandırmıyordu ve ben de bilinçli bir şekilde bu yeteneğimi geliştirmemeye çalıştım.

Vay be, ne kadar yanılmışım. Ortaya çıkıyor ki, başkalarının bakış açısını anlamak neredeyse başarının sırrı. Bu, kendi çıkarlarınızdan vazgeçmek anlamına gelmiyor, tam tersi. Bir başkasının nasıl düşündüğünü anlamak, onun çıkarları doğrultusunda hareket edeceğiniz anlamına gelmez; örneğin savaşta olduğu gibi bazı durumlarda tam tersini yapmak istersiniz.

Çoğu yaratıcı, çalışmalarını bir insan kitlesi için oluşturur. Ve bir kitleyi kendine çekebilmek için, onların neye ihtiyaç duyduğunu anlamak gereklidir. Örneğin, en iyi resimlerin çoğu insanları resmeder, çünkü insanlar genelde insanları ilgi çekici bulur.

Empati, iyi bir hacker ile harika bir hacker arasındaki belki de en belirgin farktır. Bazı hackerlar gerçekten çok zekidirler, ama empati konusunda adeta kendi dünyalarında yaşarlar. Bu tür insanlar için kullanıcının gözünden bakabildiği harika bir yazılım tasarlamak genellikle zordur.

İnsanların empati konusunda ne kadar iyi olduklarını anlamanın bir yolu, teknik bir konuyu teknik olmayan birine anlatmalarını gözlemlemektir. Hepimiz, genellikle zeki olan ama bu konuda komik derecede yeteneksiz kişileri tanıyoruzdur. Eğer biri onlara bir yemekte programlama dilinin ne olduğunu sorarsa, muhtemelen ""Oh, yüksek seviyeli dil, derleyicinin nesne kodu oluşturmak için kullandığı şeydir."" derler. Yüksek seviyeli dil? Derleyici? Nesne kodu? Bu, empati eksikliğinin mükemmel bir örneğidir.Bir programlama dilinin ne olduğunu bilmeyen biri, bu terimlerin ne anlama geldiğini tabii ki bilmez. Ama endişelenmeyin, bu konuda size yardımcı olabilirim!

Yazılım dünyasında, bir programın kendini anlatması çok önemlidir. Kullanıcıların ne kadar az şey anladığını anlamak, iyi bir yazılım yazmanın temel taşlarından biridir. Kullanıcılar genellikle herhangi bir önceden bilgi sahibi olmadan yazılıma yaklaşırlar ve beklentileri, yazılımın onların tahmin ettiklerini yapmasıdır. Çünkü çoğu zaman kullanıcılar, kullanım kılavuzunu okumak yerine doğrudan yazılımı kullanmayı tercih ederler. Bu konuda en iyi örneği, 1985 yılında çıkan orijinal Macintosh bilgisayarı olarak görüyorum. O dönemde yazılımların çoğunlukla yapamadığı bir şeyi başardı: Sadece ve sadece çalıştı!

Aynı şekilde, **kaynak kodunun da kendini anlatması** gerekir. Eğer programlama ile ilgili sadece bir alıntı hatırlamamız gerekiyorsa, bu kesinlikle *Bilgisayar Programlarının Yapısı ve Yorumlanması* kitabının başındaki bir cümle olurdu.

> ""Programlar, aslında insanların okuması için yazılır ve sadece yanı sıra makineler tarafından çalıştırılır.""

Bu nedenle, bir yazılım geliştiricisi olarak, kullanıcılarınızın yanı sıra okuyucularınız için de empati kurabiliyor olmanız çok önemlidir. Sonuçta, siz de bir okuyucusunuz. Birçok yazılımcı, bir program yazdıktan altı ay sonra geri döndüğünde, programın nasıl işlediğini anlamadığını fark eder. Bu tür deneyimler yaşayan ve Perl'den vazgeçen birkaç kişi tanıyorum.

Empati eksikliği, bazı yerlerde öyle moda ki, zeka ile bile ilişkilendiriliyor. Ama bence bu iki özellik arasında bir bağlantı yok. Matematik ve doğa bilimlerinde başarılı olmak için empati yeteneğine sahip olmanız gerekmiyor ve bu alanlardaki insanlar genellikle zekiler, bu yüzden bu iki nitelik birbirine bağlanmış gibi görünüyor. Ama empatide pek de becerikli olmayan zeki olmayan insanlar da bol miktarda var. Sadece tartışma programlarına telefonla bağlanıp soru soranları dinleyin. Sorularını o kadar dolambaçlı bir şekilde soruyorlar ki, sunucular genellikle sorularını onlar adına yeniden ifade etmek zorunda kalıyorlar.

Yani, eğer hackleme resim yapmak ve yazmak gibi bir şeyse, o da aynı şekilde havalı mı? Ne de olsa, sadece bir hayatın var. Neden onu harika bir şey üzerinde çalışarak geçirmeyesin ki?

Maalesef, bu soruya yanıt vermek zor. Prestij konusunda her zaman büyük bir zaman gecikmesi söz konusudur. Bu, uzak bir yıldızdan gelen ışığa benzer. Resim, şu an prestijli çünkü beş yüz yıl önce insanlar harika işler çıkarmıştı. O dönemde, bu resimlerin bugün bizim için ne kadar önemli olduğunu düşünen yoktu. O zamanlar yaşayanlar için, Urbino Dükü Federico da Montefeltro'nun bir gün Piero della Francesca'nın bir tablosunda tuhaf burnu olan adam olarak anılacağı çok garip gelirdi.

Dolayısıyla, kabul ediyorum, programlama yazmanın bugün resim yapmak kadar havalı göründüğünü söyleyemem. Ancak unutmayın ki, resim yapmanın da altın çağında bugün olduğu kadar havalı göründüğünü söylemek zor.

Bir miktar özgüvenle söyleyebiliriz ki, hacklemek konusunda altın çağımızı yaşıyoruz. Çoğu disiplinde en büyük eserler genellikle başlangıçta ortaya çıkar. 1430 ile 1500 yılları arasında yapılan resimler hala aşılmış değil. Shakespeare, profesyonel tiyatronun yeni yeni doğduğu bir dönemde ortaya çıktı ve tiyatroyu o kadar ileri bir seviyeye taşıdı ki, ondan sonraki tüm oyun yazarları kendi gölgelerinde kaldılar. Albrecht Durer baskı sanatıyla, Jane Austen ise roman yazımla aynı etkiyi yarattı.

Aynı durum durmaksızın karşımıza çıkıyor. Yeni bir alan doğuyor ve insanlar bu alana öylesine merak salıyorlar ki, ilk birkaç jenerasyon içinde hemen hemen tüm olasılıkları keşfediyorlar. Şu anda da hackerlık dünyası tam bu evrede gibi görünüyor.

Leonardo'nun döneminde resim, onun eserlerinin katkılarıyla bu kadar popüler değildi. Hacking'in ne kadar popüler olacağı ise bu yeni alanla neler başarabileceğimize bağlı.

#### Notlar

[1] Fotoğrafçılığın resim sanatına verdiği belki de en büyük zarar, en iyi mesleği yani 'anaparayı' ortadan kaldırmış olmasıdır.Sanat tarihine baktığımızda, birçok büyük ressamın hayatını portre çizerek idame ettirdiğini görürüz. Bu, onların hem yeteneklerini sergilemeleri hem de geçimlerini sağlamaları için mükemmel bir yol olmuştur.

[2] Microsoft'un çalışanlarının, hatta boş zamanlarında bile, açık kaynaklı projelere katkıda bulunmalarını engellediğini duydum. Ancak şu an en iyi yazılımcıların çoğu açık kaynak projelerde çalışıyor. Bu politika sonucunda, Microsoft'un en iyi yazılımcıları işe alma şansını kaybedebileceğini düşünüyorum. Bu, biraz ironik değil mi?

[3] Üniversitede programlama hakkında öğrendiğiniz şey, kitaplar, kıyafetler ya da flörtleşme hakkında lisede öğrendiklerinize benzer: lisedeki zevkinizin ne kadar kötü olduğunu fark edersiniz. Programlama dünyasına girdiğinizde, lisede öğrendiğinizin ne kadar yetersiz olduğunu anlarsınız.

[4] İşte, uygulamalı empatinin canlı bir örneği. Viaweb'de, iki alternatif arasında seçim yapmamız gerektiğinde, rakiplerimizin hangi seçeneği daha çok nefret edeceğini düşünürdük. Bir keresinde, bir rakibimiz, aslında hiçbir işe yaramayan bir özelliği kendi yazılımlarına eklemişti. Ancak, bu özellik bizim yazılımımızda olmadığı için, sektör basınında bir hayli öne çıkarıyorlardı. Bu özelliğin aslında işe yaramadığını açıklamayı düşünebilirdik, ama bizim de bu özelliği bizim yazılımımıza eklememizin rakibi daha çok rahatsız edeceğini düşündük. Ve o öğleden sonra kendi versiyonumuzu oluşturduk. Bu, rekabetin ne kadar yaratıcı olmanızı sağlayabileceğinin bir örneğidir.

[5] Metin editörleri ve derleyiciler hariç tabii ki. Hackerların bunları tasarlarken empatiye ihtiyaçları yok, çünkü zaten kendileri bu araçların sık kullanıcıları. Hackerların, kullanıcı deneyimini düşünerek bu araçları tasarlamaları, onları daha etkili ve kullanıcı dostu hale getirebilir.

[6] Hemen hemen diyebiliriz. Biraz fazla RAM kullanıldı, bu da disklerin sık sık değiştirilmesi gerektiği anlamına geliyordu. Ancak bu sorun, birkaç ay içinde ek bir disk alarak çözülebilirdi. Teknoloji bazen beklenmedik sorunlar yaratabilir, ama genellikle çözümü de vardır.

[7] Programları okunabilir kılmak için onları yorumlarla doldurmak pek de doğru bir yol değil. Hatta, Abelson ve Sussman'ın söylediklerini bir adım daha ileri götürebilirim. Programlama dilleri, algoritmaları açıklamak için tasarlanmalı ve sadece ikincil olarak bilgisayarlara bunları nasıl uygulayacağını belirtmeli. İyi bir programlama dili, yazılımı açıklamak için İngilizce'den daha iyi olmalı. Yorumlara sadece, okuyucuları bir tür geçici çözüm hakkında uyarmak gerektiğinde ihtiyaç duyulur. Bu, bir yolda sadece beklenmedik derecede keskin virajlar olduğunda ok işaretlerinin bulunduğu duruma benzer. Programlama dilleri, yazılımın nasıl çalıştığını açıklamak için bir harita gibi olmalıdır.

**Özel Teşekkürler**:Bu yazının taslaklarını okuyup yorumlarını paylaşan Trevor Blackwell, Robert Morris, Dan Giffin ve Lisa Randall'a, ve beni konuşmak için davet eden Henry Leitner ve Larry Finkelstein'a teşekkürlerimi sunuyorum. Bu yazıyı daha iyi bir hale getirmemdeki katkıları için minnettarım.""""

---

İlişkili Konseptler: hackerlar ve ressamlar, hacking ve resim arasındaki karşılaştırma, programlamanın yaratıcı bir süreç olması, yazılım tasarımında empati, açık kaynaklı hacking, hacking öğrenme, yazılım tasarım süreci, programlama dilleri, programlamada empatinin önemi, yazılım işbirliği, programlamanın bir günlük iş olarak, hackingin evrimi, programlama ve sanatkarlık, hacking ve yazılım geliştirme, yazılım geliştirmede kullanıcıları anlama."