Yazılım geliştirme olayını bir bütün olarak ele aldığımızda kod yazmanın çok küçük bir parçayı temsil ettiğini görüyoruz. Hataların en fazla yapıldığı ve müşteri isteklerinin programa dönüştürüldüğü geçiş süreci olduğu için de yanlış anlaşılmalara ve uygulamalara en açık bölüm. Hal böyle olunca buna bir de yazılımcının yetersiz deneyimini ve yönetimin ilgisizliğini katarsak ortaya kalitenin çok düşük olacağı bir ürün çıkacaktır. Yazılım uzmanı kullandığı programlama dilini çok iyi biliyor olabilir. Yazılımı yapılan işi de bilmek en az programlamayı bilmek kadar önemlidir. Örneğin muhasebe kurallarını bilmeden nasıl muhasebe programı yazacağız? Yada diğer sistemlerin girdi çıktılarını öğrenmeden nasıl entegre bir sistem yazacağız?

Çoğu zaman program geliştirmek; favori text editörümüzü açıp bir kaç satır kod yazmak, veritabanına iki üç tablo yerleştirmek ile başlar. Bu bazı firmalarda dahi böyle. Bu tür bir projeye devam ettiğinizi düşünelim eminim 5 ay sonra ilk yazılan kodun tek satırı dahi kalmaz. Diğer bir konuda yazılan kodun müşteri istekleri ile örtüşmesi. Örneğin yazdığınız bir fonksiyonun hangi müşteri isteği tarafından kullanıldığını biliyor musunuz?

Kitap Okuyun

Kullandığınız yazılım dili ile ilgili en az bir referans kitap bulundurmalısınız. Araştırıp en iyisini veya tavsiye edilenleri alın. Dil ile ilgili kitapların yanında insan ilişkilerini anlatan kitaplar, proje yönetimini anlatan kitaplar, süreç iyileştirme ile ilgili kitaplar, IEEE, CMMI yada ISO standart kitapları, UML ve nesne yönelimli dizayn konularını anlatan kitaplar, kullandığınız yazılım araçlarını anlatan kitaplar, güvenli kod yazmak ile ilgili kitaplar sayılabilir. Burada kitap reklamı yapmayacağım, eğer ilgileniyorsanız benimle bağlatıya geçip bilgi alabilirsiniz.

Bu kitaplardan öğreneceğiniz yöntemler yazdığınız kodun kalitesini oldukça arttıracaktır.

Listelere Üye Olun

E-posta listeleri bedava destek alabileceğiniz yerlerden bir tanesi. Çoğunlukla üretici firmalar tarafından da kontrol edilmekte. Bir listeye üye olduğunuzda muhakkak liste kurallarını öğrenin. Örneğin nasıl üye olacağınızı veya üyelikten çıkacağınız iyi bilin. Benim takıldığım listelere her gün bir kaç kişi direk listeye gönderdiği UNSUBSCRIBE e-postası ile hem kendini rezil ediyor hemde üyelikten çıkamıyor. Listede her zaman saygılı olun ve şakayı yeri gelince kullanın. Şaka yaptığınızı belirtmek içinde :-) imleçlerini kullanın ki herkes şaka yaptığınızı anlasın, aksi takdirde sonu gelmez tartışmalara girersiniz. Konu dışı bir şey soracaksanız liste kurallarına göre postayı işaretleyin. Örneğin benim üye olduğum bir listede OT harflerini konu kısmında görünce konu dışı olduğunu anlıyorum. Liste üyeleri e-maıl programlarında bu başlıklara göre kurallar oluşturabiliyor.

Sorduğunuz sorular cevaplanınca teşekkür edin ve daha sonra bir özet postası atıp problemi nasıl çözdüğünüzü anlatın ki herkes yararlanabilsin. Listedeki insanlarla fırsat doğarsa tanışmaya çalışın. Listeye sormadan evvel Google’da arayın.Yüzde 95 ihtimalle sizin karşılaştığınız problem birileri tarafından zaten çözülmüştür.

Açık Kaynak Araçları Kullanmayı Öğrenin

Eskiden kod yazarken Allah ne verdiyse harala gürele yazıyorduk. Ne bir dökümantasyon ne bir ünite testi nede kurulum için herhangi bir şey yapıyorduk. Programı edinen kişilerin en az bizim kadar bildiğini varsayarak, kurulum sırasında problem yaşamayacaklarını düşünürdük. Şimdi o günler geride kaldı. Artık kod yazarken gerekli açıklama satırlarını XML olarak yazıyoruz. Daha sonra açık kaynak programlar ile bunları yardım dosyalarına dönüştürmek mümkün. Ünite testleri içinde bir sürü açık kaynak sistem var. Programı yazmadan önce testini yazıyoruz artık. Sonrada bu testlerden geçmek için kod yazıyoruz. Sonuçta ortaya çıkan ürün en azından bazı testleri yapılmış olarak çıkıyor. Kodun ne kadarının ünite testine girdiğini anlayacak araçlar da var. Testleri yapılmamış kısımları hemen görmek mümkün. Ayrıca bu işleri tamamen otomatize edip sonuçları her derleme işleminde görmekte mümkün. Belli kurallara uyulup uyulmadığını kontrol edecek araçlar da mevcut. Örneğin herkes member değişkenler için m kullanmış mı? Bu araçların bugün mevcut olması bizim için bulunmaz bir fırsat. Belli bir programlama diline yönelik yazmadığım için araç isimlerini vermiyorum fakat .NET ile ilgili araç isimlerini isterseniz benimle bağlantıya geçiniz.

Sürüm ve Konfigürasyon Yönetimi Konusunda Bilgilenin

Bir ekip içinde yazılım geliştirmenin sorumluluğu, diğer kişilerin ne yaptığını bilmekten geçer. İşlerin paylaştırılması, planların yapılması ve çalışmaya başlamak için kendi payınıza düşen kod parçasını alıp değiştirmek, ünite testlerini yapmak ve en sonunda da diğer kişilerin kullanımına açmak gerekir. Kullandığınız kod kontrol programının özelliklerini öğrenmek bir yana, proje içinde kullanılan konfigürasyon yönetimi metodunu öğrenmek te çok önemlidir. Yapılan her işin, üretilen her dökümanın kısacası zaman içinde değişime uğrayacağını bildiğiniz her türlü materyal kod kontrol sunucularında tutulmalıdır. Yazdığınız kodun eski sürümüne dönmek yada farklı sürümlerde paralel geliştirme yapmak ancak bu şekilde mümkün olabilir.

Bir Bilene Sorun

İşte herkesin korktuğu bir olay. Genelde kişiler suçlanmaktan yada küçük düşmekten korktuğu için soru sormaz. Ama soru sormadan da öğrenme olmuyor. Yazdığınız bir kodun daha iyi nasıl yazılabileceğini sordunuz mu hiç? Yada bir problemi en iyi hangi yolla çözebileceğinizi öğrenmek için soru sordunuz mu? Eğer korkularınız varsa yukarıda anlattığım e-posta listeleri sizin için biçilmiş kaftan. Kendi isminizi kullanmadan soru sorabilirsiniz. Yada patronunuzun ismine GMail’de bir hesap açıp onu kullanın Smile evet bu bir şaka…

Soru soracağınız kişileride iyi belirlemeniz lazım. En azından yeterli bilgiye sahip olup olmadıklarını anlamaya çalışın. Aldığınız bilgiyi vakit geçirmeden uygulayın ve sonuçları tekrar bir bilenle tartışın.

Seminerlere Katılın

Yeni ürünleri görmek, yeni insanlarla tanışmak, yaptığınız iş hakkında daha da fazla bilgilenmek ve sıfatınızın daha da fazla tanınması için en mükemmel yol. Peki yazdığınız kodun kalitesini nasıl arttıracak? Ben genelde hands-on denilen oturup kod yazdığımız seminerleri tercih ediyorum. Hem uygulama var hem öğrenme. Bu arada da kodu nasıl yazmışlar görme imkanımız oluyor. Eğer birinin daha iyi bir fikri varsa çıkıp söylüyor.

Ürün tanıtım seminerleri de yararlı eğer kod yazmada kullandığınız araçlar ile ilgiliyse yada üretkenliği arttıracak araçlar anlatılıyorsa. Bu araçlara erişiminiz olmayabilir fakat en azından böyle bir teknolojinin varlığından haberdarsınız.

Yeni İnsanlarla Tanışın

İnsan ilişkilerine yukarıdaki paragraflarda değindim. Yeni insanlarla tanışmak önünüze yeni ufuklar açabilir. Bu kişilerden öğreneceğiniz hiç bilmediğiniz hiç görmediğiniz yada pek önemsemediğiniz konular problemlerinize farklı bir bakış açısı katabilir. Yada siz onlara bir şeyler katabilirsiniz. Yeni insanlarla tanışmak benim hayatımda her zaman değişikliklere yol açmıştır. Ayrıca iş konuları dışında birlikte yapılacak aktiviteler çok değişik iş imkanları açabilir.

Blog Yazın/Okuyun

Deminden beri yaptığım olay… Eğer benim blogumu okuyorsanız ne mutlu bana. Bir iki yorum da atarsanız çok mutlu olurum. Şaka bir yana öğrendiğim konuları ders notları gibi başkalarına anlatmak amaçlı yazdığımda daha da pekiştiriyorum. Hatta bazen farklı yollar bile bulmak mümkün oluyor. Ek olarak iş verenler blogunuzu okuyup ne işler yaptığınızı öğrenebilir ve buna göre size teklifte bulunabilirler. Blogunuzda belli konulara yönelin ve iş hayatınızda karşılaştığınız konuları yazın. Tanıdıklarımın bir kaç blogu birden var, bir tanesi kesinlikle işleri ile ilgili konuları yazmak için diğeri ise sırf geyik olsun diye yazdıkları yada aile fertleri ile resim paylaşmak için kullandıkları blogları.

Kod yazarken çeşitli problemlerin çözümünü genelde bloglarda buluyorum. Bir kaç yazışmadan sonra kodu alıp kullanabiliyorum. Kimi zaman örnek projeler bile indirmek mümkün. Böylece yazdığım kodun kalitesi artmış oluyor.

Refactoring Nedir Öğrenin

Refactoring yazılan kodun performansının, bakımının, okunabilirliğinin ve yeniden kullanılabilirliğinin arttırılması için uygulanan bir dizi metoddan ibarettir.Örneğin tekrar eden rutinleri ayrı fonksiyonlara ayırmak, ilgili rutinleri bir sınıf altında toplamak, değişken isimlerini değiştirmek, algoritmaları daha hızlı çalışır hale getirmek vb gibi. Tüm bunları yaparkende zaten çalışan kodu bozmamak. Sonuçta işin kalitesi artmış oluyor.

İnsan İlişkilerini Sıcak Tutun

Firma içinde olsun, bağlı olduğunuz sektörde olsun; tanıştığınız insanlar ile ilişkilerinizi sıcak tutmaya çalışın. Bir gün bir probleminiz olduğunda gene onlara soracaksınız ama sadece probleminiz olduğunda bu kişilerle bağlantı kurarsanız biraz ayıp olur. Ayrıca soru sormayıda öğrenmek gerek. Örneğin benim blogumda bir kaç tane yorum var, sadece hata aldığı kısmı kopyalayıp yapıştırmış. Ne bir açıklayıcı not var nede takip ettiği adımları anlatmış. Neyse bende çıkarttım kristal küremi baktım neymiş hatası. Geriye mesaj atıp 3 vakte kadar çözeceksin dedim :-) .

Değişime ve Yenilenmeye Açık Olun

Değişik metodları ve yeni ürünleri kurmaktan, kullanmaktan çekinmeyin. Değişmeyen ve yenilenmeyen beyinler bir gün gelir sistem dışı kalırlar. Değişiklik ve yenilik her zaman iyi olmayabilir ama bunun muhakemesini yapacak olan sizlersiniz.Benim en çok karşılaştığım tipler “gündüz programcıları”. Bunlar sadece yazılım sektörü iyi maaş ödüyor diye sektöre atılmış kişilerdir. Bir iki kurstan sonra hayata atılıp kendilerini işin ehli gibiymiş gösterip ahkam keserler. Bu kişiler kullandıkları yöntemleri değiştirmek istemezler çünkü öğrenmek ve uygulamak beraberinde yeni külfetler getirecektir. Zaten bildikleri yoldan şaşmayıp işlerini zamanında bitirmeye çalışırlar. Mükemmele ulaşmak gibi bir çabaları yoktur. Refactoring deyince küfür zannederler :-)

Birde “gece programcıları” vardır. Burada anlattıklarımı yüzde 70 yapan kişiler sanırım bu kategoriye giriyorlar. Gece programcısı araştırıp öğrenmek, yenilikleri denemek için sonsuz bir istek içindedir. Mükemmelliğe ulaşana kadar her yolu dener. Sistemleri değiştirmekten kaçınmaz.

Sektörün her iki tip insana da ihtiyacı var. Biri iyidir, diğeri kötüdür diye bir yorum yapmayalım. Projelerde bazen zamanlama ön plandadır, kimi zamanda kalite. Duruma göre bu iki tip yazılım uzmanının dengeli bir karışımı kaliteli bir ürünü zamanında teslim etmenize sebep olabilir.

Firma Kültürünü Öğrenin

Firma içindeki işleyiş şemasını iyi öğrenin. Firma kurallarını iyi öğrenin. Bazı kurallar yazılı olmayabilir ve zamanla öğrenilecek kurallardır. Yazılım standartlarını, kullanılan araçları, ve ağ yapısını öğrenin. Yazdığınız kodun standartlara uyduğundan emin olun.

Kişisel Bilgisayarınıza Yazılım Araçlarını Kurun

Yazılım olayına gönül vermiş iseniz zaten bunu söylemeye gerek yok. Ama ben öyle insanlar ile çalıştım ki adam sadece firma duvarları arasında yazılım uzmanı olarak geçiyor. Evinde bir bilgisayarı dahi yok, varsa bile örütbağı amaçlı kullanıyor. Bir kişisel e-posta adresi yok. Seminerlerden, toplantılardan, etkinliklerden bi haber. Ben bu işi yapmaktan zevk alıyorsam tabii ki evimdeki bilgisayarıma gerekli araçları yüklerim. Evde de bazı projeler geliştirmek isterim. Amaç daha çok denemek, daha çok yanılmak ve bilgiyi arttırmak değil mi?

Açık Kaynak Projelere Katılın

Açık kaynak projeler size bir ekip içinde nasıl çalışacağınızı ve ne tür araçları kullanacağınız hakkında bilgi verir. Katılacağınız bir projeyi eminim Sourceforge yada başka açık kaynak proje sitelerinde bulabilirsiniz. Sonuçta yazdığınız kod başkaları tarafından kontrol edileceği için değişiklikleri takip edip en iyi nasıl yazılır öğrenebilirsiniz.

Hayal Kurun

Hayal kurmak beynimizin en üretken işlerinden biridir. Hayal kurarken problemlere yeni çözümler bulabilir veya yeni projelere başlamak için malzeme toplayabilirsiniz. Ben bir defter alıp buna aklıma gelen olası projeleri yazıyorum. Gerçi ben projeleri hayata geçirene kadar birileri benden önce yapıyor ama olsun. Bu yöntemin amacı aslında yeni projeler bulmak değil var olan projelerin belirli kısımlarının nasıl düzeltilebileceğini araştırmaktır. Örneğin bir projede şöyle bir durumla karşı karşıya kaldık. Bir dökümanın onaylanması için 3 ayrı kişinin onay vermesi gerekiyordu. 5 yıl önce programı dizayn edenler veritabanında ki Dokuman tablosunda bu 3 kişi için birer saha tanımlamış. Gel zaman git zaman, onaylama süreçleri organizasyonun yapısı ile değişmiş fakat yeni sistemi karşılayacak veritabanında yeteri kadar saha yok. Olayın çözümü basit. Ek bir tablo yaratıp onaylayacak kişileri burada tutabilir ve her döküman için istendiği kadar çok onaylayacak kişi tanımlanabilir.

Kod Teftişi

Kod teftişi başkasının yazdığı kodun gözden geçirilmesi ve aksaklıkların not edilmesidir. Proje açık kaynak ise, kodu düzeltmek te işin içine girer. Eğer firma içinde yazılım geliştiriyorsanız, kodun yazarına bir not gönderip değişmesi gereken yerleri ve nedenlerini bildirebilirsiniz. Kod teftişinin amacı var olan kodu daha iyi çalışır hale getirmek yada proje standartlarına uydurmaktır. Agile metodları ile geliştirme yapanlar Pair Programming olayını bilirler. Bu yöntemde iki kişi bilgisayarın karşısına geçer. Birisi kod yazarken diğeride yazılan koda puan verir. 10’dan başlayan bu puanlamada her hata da 1 puan düşülür. Kodlama bitince programın aldığı puana bakılır ve 10 puan almak için neler yapılabilir tartışılır. Gerekli olan düzeltmeler uygulanır.

Var mı hala böyle programcılar :)

  

Neden herkes böyle bir telaş içinde?

Herhangi bir kitapçıya gittiğinizde Teach Yourself Java in 7 Days (7 Günde Java Öğrenin) benzeri, size birkaç günde veya birkaç saatte Visual Basic, Windows, Internet (vs.) öğretmeyi vadeden kitaplarla karşılaşırsınız. Amazon.com’da şöyle bir arama yapınca:

    pubdate: after 1992 and title: days and (title: learn or title: teach yourself)
	(1992’den sonra basılmış baslığında gün ve öğrenin kelimeleri geçen kitaplar)

karşıma 248 sonuç geldi. Bunların ilk 78 tanesi bilgisayar kitaplarıydı (79. ise, Learn Bengali in 30 Days (30 Günde Bengalice Öğrenin)). “Gün” anahtar sözcüğünü “saat” ile değiştirdiğimde ise sonuç benzerdi: ilk 77 bilgisayar kitabını 78. olarak Teach Yourself Grammar and Style in 24 Hours (24 Saatte Gramer ve Stil Öğrenin) takip ediyordu. Gelen toplam 253 sonucun ilk 200’ünün %96’sını bilgisayar kitapları oluşturuyordu.

Birkaç günde, Beethoven, Kuantum Fiziği ya da köpek eğitimi öğreten kitaplar yok. Bu sonuçlara bakılırsa, ya insanlar bilgisayar hakkında yeni şeyler öğrenmek için çok hevesli ve aceleci ya da bu iş bir şekilde inanılmaz derecede kolay.

Bakalım Learn Pascal in Three Days (3 günde Pascal Öğrenin) benzeri bir başlık ne anlama gelebilir:

  • Learn(öğrenin): İlk olarak 3 gün kayda değer programlar yazarak, yazdığınız programlardaki başarı ve başarısızlıklarınızdan ders almanıza yetecek bir süre değildir. Ne tecrübeli bir programcıyla çalışmaya, ne de o ortamın içinde yaşamanın nasıl bir şey olduğunu anlamaya zamanınız olmayacaktır. Bu durumda sadece yüzeysel bir aşinalıktan bahsedilebilir, derinlemesine bir kavramadan değil. Kısacası dili iyi öğrenmeye fırsatınız olmayacaktır. Alexander Pope’nin de söylediği gibi bir “yarı bilgili olmak çok tehlikelidir”.
  • Pascal: 3 gün Pascal’ın sözdizimini öğrenmeye yetebilir (tabii eğer benzer sözdizimli bir dili önceden biliyorsanız), ama bu sözdizimini verimli bir şekilde kullanmayı öğrenemezsiniz. Kısacası, eğer bir Basic programcısıysanız, Pascal’da Basic mantığına dayanan programlar yazmayı öğrenebilirsiniz ama Pascal’ın hangi özellikler için iyi (ve nelerde kötü) olduğunu öğrenemezsiniz. O zaman ne anlamı kalır ki? Alan Perlis “Programla mantığınızı etkilemeyen bir dili öğrenmiş olmanın bir değeri yoktur.” demis. Bir ihtimal, belirli bir işin üstesinden gelmek için biraz Pascal (yada muhtemelen Visual Basic ya da JavaScript) öğrenmeniz gerekiyordur. Bu durumda da nasıl programlama yapacağınızı değil, ancak o anki sorunun üstesinden nasıl geleceğinizi öğrenirsiniz.
  • in Three Days(üç günde): Malesef, ilerki bölümde de göreceğiniz gibi bu süre yetersiz.

On yılda Programlama Öğrenin

Araştırmacıların da (Hayes, Bloom) ortaya koyduğu üzere, satranç oynamaktan beste yapmaya, resimden piyanoya, yüzmeden tenise ya da nöropiskoloji ve topoloji alanlarında araştırma yapmaya kadar bir çok alanda uzman olmak, on yıl civarında bir zaman alıyor ve bunun bir kısayolu var gibi gözükmüyor. Daha 4 yaşında müzik dahisi olduğu anlaşılan Mozart bile, ancak 13 sene sonra dünya çapında ses getirecek bestelerini yapmaya başlamış. Diğer bir tarzda, Beatles, 1964’te sahnelere, ardarda hit olan şarkıları ve Ed Sullivan’ın programında çıkmalarıyla gelmiş gibi gözükseler de, aslında 1957’den beri Liverpool ve Hamburg’da küçük klüplerde çalıyorlardı. Başlangıçta kitleleri çabuk cezbetmelerine rağmen ilk kayda değer başarılarını 1967’de Sgt. Peppers ile yakaladılar. Samuel Johnson’a göre bu süreç on yıldan da fazla sürmekte: “Herhangi bir alanda kusursuzluğun, bir ömürboyu o iş için çalışmaktan daha hafif bir bedeli yoktur.” Chaucer de, bir sanatı öğrenmenin çok uzun sürdüğünden, ama hayatın çok kısa olduğundan yakınır.

Benim programcılıkta başarı için tavsiyelerim şunlardır:

  • Sırf ne kadar eğlenceli olduğunu görmek için programcılıkla biraz uğraşın, programlar yazın. Programcılığın, on sene uğraşmak istemenizi sağlaycak kadar eğlenceli olan boyutunu kaybetmemesini sağlayın.
  • Diğer programcılarla konuşun, başka programları okuyun. Bu herhangi bir kitap veya kurstan daha önemli ve yararlıdır.
  • Programlar yazın. Öğrenmenin en iyi yolu pratiktir. Daha teknik bir şekilde ifade edecek olursak; “Bireylerin performanslarının en üst düzeyine, elde edilen tecrübelerle erişilemez, fakat çok deneyimli bireylerin bile gelişme yönündeki yoğun çabaları performanslaını yükseltmeye yeter.” (s.366) ve “En verimli öğrenme şekli, bireyin seviyesine uygun bir konu üzerinde, bilgilendirici geri beslemeler, tekrarlama fırsatları ve hataların düzeltilmesi gibi çalışmalar gerektirir.” (s.20-21) “ Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life” isimli kitap bu bakış açısı için ilginç bir referans olabilir.
  • İsterseniz, üniversitede alacağınız dört yıllık bir eğitim ile (veya yüksek lisans için daha fazlası ile) bazı işler için gereken referansları elde edebilirsiniz. Ayrıca bu sayede konu üzerinde derinlemesine çalışmalar yapma şansı da bulabilirsiniz. Ama okuldan keyif almıyorsanız, biraz daha fazla çaba ile iş ortamında da bu tecrübeyi kazanabilirsiniz. Her iki durumda da kitaplardan öğrendikleriniz yetersiz kalacaktır. The New Hacker’s Dictionary(Yeni Hacker Sözlüğü) yazarı Eric Raymond “Sadece boya ve fırça sizi iyi bir ressam yapmayacağı gibi bilgisayar bilimleri eğitimi de, hiçkimseyi uzman bir programcı haline getirmez” der. İşe aldığım en iyi programcılardan biri sadece lise mezunuydu. Çok güçlü ve çok iyi yazılımlar üretti, kendi USENET haber grubuna sahipti ve hiç şüphe yok ki hisse senetleri sayesinde şu anda benim hiçbir zaman olamayacağım kadar zengin.
  • Başka programcıların da katıldığı projelerde yer alın. Bazı projelerde en iyi, bazılarında en kötü programcı siz olun. Ekibin en iyisi siz olduğunuzda, bir projeyi yönetebilme becerinizi test edebilme imkanı ve vizyonunuzla takım arkadaşlarınızı etkileme fırsatı bulacaksınız. En kötü olduğunuz durumda ise, ustaların neler yaptıklarını ve neleri yapmaktan hoşlanmadıklarını (ki bu size yaptırdıklarıdır) gözlemleme şansı bulacaksınız.
  • Başka programcıların katıldığı projelerde onlardan sonra yer alın. Başka bir programcının yazdığı programı anlayabilecek seviyeye gelin. Yazılımın yazarı yokken onu anlamak ve düzeltmek neler gerektiriyor görün. Kendi yazdığınız programları da sizden sonra üzerinde çalışacakların işini kolaylaştıracak şekilde nasıl tasarlayacağınızı düşünün.
  • En az yarım düzine programlama dili öğrenin. Bunların içinde, sınıf soyutlamalarını içeren bir dil (Java veya C++ gibi), fonksiyonel soyutlamaları destekleyen bir dil (Lisp veya ML gibi), sözdizimi soyutlamalarını destekleyen bir dil (Lisp gibi), tanımlama özelleştirmelerini içeren bir dil (Prolog veya C++ kalıpları gibi), eşrutinleri destekleyen bir dil (Icon ve Scheme gibi) ve paralelliği destekleyen bir dil (Sisal gibi) mutlaka bulunsun.
  • “Bilgisayar bilimleri”nde “bilgisayar”ın da olduğunu unutmayın. Bilgisayarınızın bir komutu çalıştırmasının, ön ya da ana bellekten bir kelime yakalamasının, ardıl kelimeleri diskten okumasının ve disk üzerinde yeni bir yer bulmasının ne kadar zaman aldığını öğrenin.
  • Dil standartlaştırma çalışmalarından birinde yer alın. Bu ANSI C++ komitesi de olabilir, yerel programcılar olarak içe kaydırma standartlarınızın seviyesini belirleyecek bir çalışma da. Her iki durumda da diğer programcıların bir dilde neyi, ne kadar ve biraz da şanslıysanız neden sevdiklerini öğrenebilirsiniz.
  • Bu dil Standartlaştırma çalışmalarından bir an önce ayrılabilecek sağduyuya sahip olun.

Tüm bunları göz önünde bulundurunca, sadece kitaplardan öğrendiklerinizle ne kadar ilerleyebileceğiniz tartışılır. İlk çocuğum doğmadan önce, bütün How To (Nasıl) … kitaplarını okumuştum ve buna rağmen kendimi hala bilgisiz bir çömez gibi hissediyordum. 30 ay sonra, ikinci çocuğum doğacakken, bir tekrar için kitaplara geri mi döndüm dersiniz? Hayır, bunun yerine kişisel tecrübelerime güvendim ve daha sonra gördüm ki bu, uzmanlar tarafından yazılmış binlerce sayfadan çok daha yararlı ve güven verici.

Fred Brooks, “No Silver Bullets” isimli eserinde iyi yazılım uzmanları bulmak için üç seviyelik bir plan tanımlamış:

  1. Sistematik olarak ve mümkün olduğunca erken iyi tasarımcıları belirleyin.
  2. Yeni başlayanların kariyer dosyalarını düzenlemesi için onların gelişiminden sorumlu bir kariyer yöneticisi görevlendirin.
  3. Yetişmekte olan tasarımcıların birbirlerinden etkilenip harekete geçecekleri imkanlar yaratın.

Bu gösteriyor ki bazı kişiler müthiş birer tasarımcı olmak için gerekli özelliklere zaten sahipler, iş onları ikna etmeye kalıyor. Alan Perlis bunu daha özlü bir biçimde “Herkese heykel yapmak öğretilebilir: Michelangelo’ya ise nasıl yapılamayacağı öğretilmeliydi. Bu çok iyi programcılar için de böyledir.” şeklinde ifade etmiştir.

Hadi, şimdi gidip o Java kitabını satın alın; muhtemelen işinize yarayacaktır. Ama 24 saatte, günde hatta ayda, hayatınızın değişmesini veya programcı olarak gerçek yetenek ve deneyimlerinizin gelişmesini beklemeyin.
http://ileriseviye.org/arasayfa.php?inode=programmingtenyears.html

Konu alıntıdır. Yazının birçok yerinde çok güzel tespitler yapılmıştır. Hoşuma gitti, paylaştım:

Bu konu uzun zamandır bende takıntı olan tuhaf bir konu. Artık gınağı (bıkkınlık) geldi. Ağzıma geleni saymanın vaktidir :)

Bu bölümde yetkiliyim. Birşey bildiğimden değil yanlış anlaşılmasın. Sadece sivri dilimden :) Bu tür platformlarda zaman zaman hak dene hakkı verilmeli düsturu içinde hareket ettiğimde doğrudur. Ama hak edenlerin haddi hesabı yok ki kardeşim. Hakeza başka platformlarda veya msn de. Ya bi sakin olun. Ağır olun. Paniklemeyin. Boynuz olun sonra kulağa geçin. Cin olun sonra adam çarpın. Bu gençlik benim ömrümü yedi.

Ben coder değilim, olmayada pek niyetim yok açıkcası. Birkaç tanıdığım CODER var o sebeple pek cazip gelmiyor halleri. Ama asıl mesele şu ki “Kimdir Coder?”
Kod yazan diye atlamayın hemen :) İlk manası elbette kod yazan. Ama anladınız siz benim neyi kastettiğimi. Bu bir ünvan.
Atalarımız ne demiş;
“Herkes programcı olabilir ama Coder olamaz”
“Programcı bugünü, Coder yarını düşünür”

Malum yurdum gençliği ya hobi olarak ya da okuldaki dersleri itibariyle programlamaya adım atmakta gecikmiyorlar. Çok güzel Allah zihin açıklığı versin. Bu gençler sürekli olarak forumda Help Me! demektedirler. Eh hadi buraya kadar da tamam. Ama…. Yardım istemenin de adabı maşeret kuralları vardır. Hadi bunları bilmiyorsun uyarılara da mı kulak asılmaz be gençlik? Burada iki şık devreye giriyor;

1. Yardım istediğine pişman olur ve küser. Hatta yapıcı uyarılara bile içerler.
2. Doğru dürüst yardım istemeyi öğrenir ve istediğini alır.

Her iki durumda da balık tutmasını öğrenmek isteyen çok azdır. Bu isteyenler arasından da öğrenenler abaküsle bile saymaya değmeyecek sayıdadır.

Asıl curcuna Veritabanı bağlantısını gerçekleştirip, 3-5 butona OnClick yazdıkları zaman başlıyor ki hiç sormayın. Daha dün “üstad bu butona basılınca ’Hello World!’ nasıl yazdıracam ? diye sorduklarını çabucak unutan genç arkadaşların artık havasından geçilmez hale gelmiş oluyor. Bir de msn ye Kişisel ileti yazdılar mı tamamdır. “Ben coder oldum”.. eveeet oldun canım.
Devam et sen bu kafayla daha çok şey olursun. Ama CODER ı ı maalesef… bir ömür olamazsın.

Birde bu olayın Görsel boyutu var, gayet güzel anlatılmış.

Kill Bill Programlama Dersi from Hardwaretim on Vimeo.