Genç Yazılımlılar İçin – II: Master yapmak ya da yapmamak.

Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği , , ,

Çok komik… Aslında traji komik… Bakın anlatayım:

Üniversiteli gençlerle hemen her buluşmamda bana sorulan sorulardan birisi de “hocam master yapalım mı?” oluyor. Çocuklarının kafasını daha lisedeyken “doktora yapma” fikriyle yıkamış bir adama sorulacak soru mu bu? Ya da yaşı 40’nı geçmesine rağmen, bir de Felsefe masterı yapsam diye düşünen bir adamın bu soruya cevabı ne olabilir ki? Dolayısıyla bu soruya, “tabi ki yapın” ya da “sadece master değil doktora da yapmalıyız” şeklinde cevaplar veriyorum. Toplumumuzun eğitim seviyesinin yükselmesi, sektörde bilgi birikiminin olması, herşeyden önce bilgi ve bilgi sevgisi kültürünün yaygınlaşması vb. tonla sebepten dolayı master ve doktora yapmanın önemli olduğuna inanıyorum. Tabi ki bu işin bir vechesi. Diğer vechesi ise o kadar da zevkli değil malesef.

Şöyle bir soru sorsam size: Ülkemizdeki BT sektörünün ihtiyacı açısından, ortalama bir BT çalışanının ne kadar eğitime ihtiyacı vardır? Zor soru tabi. Ama cevap kesinlikle “üniversite lisans eğitimi” değil bence.  Ülkemiz BT sektöründe var olan yerleşik yazılım geliştirme kültürü ve pratiği açısından ele alındığında, benim iddiam şudur: Akıllı bir lise mezunu, var olan işlerin ezici çoğunluğunu, makul miktarda iş başı eğitim ve yol gösterme ile başarabilir. Efendim BT sektöründe çalışanlar zaten liselerden gelen en zeki çocuklardanmış, ÖSS’de ilk bilmem kaça girenler bu sektörde çalışıyorlarmış, yok lisedeyken fizik olimpiyatlarına katılmışlarmış ya da yazılım sektörü çok analitik bir zeka istiyormuş, falan filan… Bence hepsi hikaye. Bunun, heyecanlı Bilgisayar Mühendisliği öğrencilerinin canını sıkacak bir iddia olduğunun farkındayım ama bence durum bu kadar vahim. Bence sadece bizim sektörde değil, pek çok mühendislikte durum bu kadar vahim: İnşaat Mühendisliği ve “bina inşa etme” kültürümüzde de durum pek farklı değil. Ya da bakın, ortalık Endüstri Mühendisliği mezunu dolu ama görüyor musunuz süreç tabanlı bir çalışma? Ben görmüyorum…  Kadın, “Endüsti Mühendisliği mezunuyum ve 10 senedir falan bankada iş analisti olarak çalışıyorum” diye tanıtıyor kendini. Soruyorum, “nasıl iş analizi yapıyorsunuz?” diye. Cevap veriyor “işte, müşterimiz iç müşteri oluyor her zaman. Onlardan istek geliyor. Gidip görüşüyorum onlarla, sonra görüşmeden çıkardıklarımdan bir Word dokümanı oluşturuyorum. Ayrıca PowerPoint’de ekran tasarımı yapıyorum.” “Peki” diyorum içimden ve soruyorum kendi kendime: Burada “analiz” nerede?: PowerPoint ile yapılan şeyin analiz olmadığı kesin çünkü zaten adında “tasarım” var. Geriye kalıyor “Word dokümanı”. Oradan birşeyler çıkarmaya çalışıyorum, çünkü kadının anlatımından “Word dokümanına yazılan şey, iş analizidir” ya da “cümleleri, analitik yapan şey, onların bir Word dokümanına yazılmış olmasıdır” (!) şeklinde birşey çıkıyor. Soruyorum,” o Word dokümanındaki temel kısımlar, başlıklar nelerdir?” Ya da “herhangi bir diyagram çiziyor musunuz” diye, ama nafile. Tek derdim, “iş analisti” olarak çalışan Endüstri Mühendisi arkadaşımızın zihninde “iş” ve “analiz” ile ilgili bir kırıntı var mı onu anlamak. Belli ki iş analisti olarak çalışan herkes kendine göre bir “analitik” 🙂 süreç izliyor.Ve Word dokümanına yazılan şeyler bir şekilde “analiz” oluyor ama dokümanda herhangi bir yapısallık bile yok. Peki söyler misiniz bana böyle bir işi akıllı bir lise mezunu niye yapamasın? Bu işin neresinde analitik bir işlem var? Bu işin postacılıktan ya da sekreterlikten ne farkı var? Postacılıktan farkı yok, çünkü analitik bir katma değer olmadan sadece bilgiyi taşıma söz konusu, herhangi bir çözümleme ve dönüştürme yok. Sekreterlikten farkı yok çünkü Word dokümanına geçiriliyor anlatılanlar. Halbuki, işi soyut olarak bir süreç olarak ifade etme, gerçek olaylardan oluşan senaryolarla, bu soyut süreci kurgulama ve doğrulama, iş kurallarını farklı kriterlerle yakalayıp ifade etme, nesne-merkezli bir yaklaşım söz konusuysa bir kavramsal nesne modeli çıkarma vb. yaklaşım ve tekniklerden bahsetmesi gerekirdi. Literatürde ve pratik uygulamada tonla “iş ve ihtiyaç analizi” (business and requirements analysis) yaklaşımı, tekniği, şablonu (patterns), diyagramları (örneğin UML), en iyi uygulamaları (best practices) vs. var. Var mı uygulayan? Olsa, bir Endüstri Mühendisliği disiplininin sağladığı alt yapıya ihtiyaç olurdu. Ve siz de derdiniz ki “bu işi ancak bir Endüsti Mühendisi” yapabilir.

Tonla iş analistine eğitim verdim, bir tanesinin de zihninde “ihtiyaç tipleri” gibi bir ayırım görmedim. Hatta analiz ile tasarım arasındaki farkı bilene bile pek rastlamadım. Her eğitimde ya da danışmanlıkta Karl Wiegers’ın nefis Software Requirements kitaplarını ebook olarak dağıttım, nefis örneklerinden verdim… Çünkü ihtiyacınızı ya da işinizi analitik olarak ele alıp, çözümlemezseniz, ne istediğinizi ya da nasıl iş yaptığınızı tarif edemiyorsunuz demektir. Bunu yapamadığınızda, hangi yazılımı, hangi en ileri teknoloji ile geliştirdiğinizin hiç bir önemi yoktur. Yazılım projelerinde, ne yapacağınızı bilmediğinizde, ne kadar adam-gün, ne zaman, ne kadar maliyet vb. hiçbir soruya yanılma payıyla bile olsa cevap veremezsiniz. Ne proje planı yapabilirseniz ne de test. Yaparsanız, sadece “yaptım oldu” olur. “Dostlar sizi PMP’lerinizle proje planı yaparken görsün”den öteye gidemezsiniz. İşimizi ve ihtiyacımızı tarif etmeyi bu şekilde algıladığımzıda ne master yapmış bir Endüstri Mühendisi’nin katma değer sağlaması mümkündür ne de bu duruma master sahibi olmak tercih sebebidir.

Aynı durum, yazılım geliştiren programcılar için de geçerli. Tonla Bilgisayar, Endüstri, Matematik vb. mühendisin çalıştığı bir yazılım geliştirme ortamında en temel kavram “ekran” nasıl olur? “Ekran aşağı, ekran yukarı”. Her şey sadece ve sadece ekran ile anlatılıyor. O yukarıda bahsettiğim ünlü Word dokumanını, tamamen ekran tasarımı ve üzerindeki arayüz elemanlarının özelliklerini yazarak oluşturan ve buna “iş analizi” diyen iş analistleri de gördüm bu ülkede ben. Herşeyin ekran üzerinden anlatıldığı bir yerde “iş” ve “analiz” nerede Allah aşkına? En önemli soyutlamanın “ekran” olduğu bir iş ortamının anlamlı olması için orasının, CRT ya da LCD ekran geliştiren bir elektronik vb. bir AR-GE birimi olması gerekmez mi? 🙂 Yazılım gibi tamamen süreç odaklı bir işi, “ekran” kavramı etrafında kurgulamamız için ne kadar eğitim almamız gerekiyor? Bunun için ne kadar Matematik, ne kadar differantial equations, ne kadar operating systems, ne kadar algorithms, ne kadar artificial intelligence öğrenmemiz gerekiyor?

Bakın ilanlara, pek çok ilanda Bilgisayar Mühendisi ile başlanır, sonra Elektronik Mühendisliği vb. mühendislikler sıralanır. Yahu BM’in yapacağı iş için niye EM ya da “ilgili bölümler” gibi ortaya karışık bir şey söylenir? Sebebi şu: Aslında aranılan şey, biraz mürekkep yalamış adam. Ne okuduğu çok da önemli değil. Gerçek bu.

Dolayısıyla “master yapalım mı” sorusunun cevabı yine tamamen kendi içinizde yatıyor. Kimse sizden master yapmış olmanızı beklemez bu ülkede, ama siz kendinizden bekliyorsanız ona saygı duyarım. Dolayısıyla bilgi sizin için önemliyse, master da yapın doktora da. Yok “erken kalkan yol alır” derseniz, bir an önce işe girin, nasıl olsa masterlı olmak çok da fazla bir avantaj sağlamayacak.

Toplam görüntülenme sayısı: 2038

Eşleştirme mi Haritalama mı? Not mu Dip Not mu? Bir “Chicken Translation” Hikayesi Daha

Java, Kültür, Bilgi ve Düşünce , , , , , , ,

Sağlıklı düşünmenin göstergesi dili sağlıklı kulanmaktır. Kafası karışık insanların dili kullanma şekilleri, kelimeleri olgulara karşı getirmeleri, bunlar üzerine argüman bina etmeleri problemlidir. Bu tür kafa karışıklıklarının bir kısmı da, teknolojiyi ve ilgili terimleri ve ifadeleri, yabancı dilden, özellikle de İngilizce’den devşirirken takındığımız tutumla ilgili. Bu günlükte olgunun ya da sürecin ruhuna uymayan ve bu yüzden iğreti duran çevirilerden daha önce de bahsetmiştim. (Örneğin “object-oriented” kavramının “nesne-yönelimli” ya da daha da yanlış olarak “nesne-tabanlı” olarak çevrilmesi ile ilgili bu yazıya bakılabilir.)

Bu yazıda bu tip çevirilerden ikisine dikkat çekmek istiyorum: İlki “annotation” kelimesinin “dip not” olarak çevrilmesi. “Annotation” Java’ya 5 versiyonuyla gelen özelliklerden birisi ve “annotation”ları, bazen kod üretme, bazen de konfigürasyon amaçlı olarak uzun süredir kullanmaktayız. Pek çok Javacı, popüler bir Java bileşeni olan JPA ayarlarını, genelde XML yerine annotation denen elemanlarla yapmayı tercih eder. Bu annotationlar başlarında “@” işaretiyle kullanılır ve değişkenler gibi, nitelenen diğer dil elemanlarının hemen öncesine, ya da geleneksel olarak bir üst satırına yerleştirilir. Yani

 

@Entity(name="Person")
@Table(name="Persons")
public class Person{

   @Id
   private String tckn;
   ...
}

örneğinde olduğu gibi. Çok sıklıkla, “annotation” kelimesinin dilimize, özellikle JPA ile ilgili yazılarda “dip not” diye çevrildiğini görüyorum. İki problem var burada: İlki “annotation”, bir yazıya yapılan herhangi bir nottur. Bir yazıda bazı yerleri sarı kalemle işaretlemek ya da çizmek bile “annotation”dur İngilizce’de, yani not alma, notlandırma, işaretleme vb. kelimelerle dilimize çevrilecek bir harekettir. Her not bu anlamda bir dipnot değildir, olması da gerekmez. İkincisi ve ironik olanı, JPA’da olup da “dip not” olarak çevrilen bu “annotation”lar, yukarıdaki örnekten de görüleceği üzere “dip”te değil, aksine nitelediği dil elemanının öncesinde/üstünde yazılır :). Bu Java’nın bir kuralıdır.

Çeviri konusunda esas “chicken translation” örneği bu değil. Esas bomba, yine JPA ile ilgili olarak, uygulamadaki nesnelerin ilişkisel veri tabanındaki tablolar, nesnelerin değişkenlerinin ise tablolardaki kolonlar ile “eşleştirilmesi”nin dilimize “haritalama” olarak çevrilmesi. Sebebi, bu kavramın İngilizcesi olan “object-relational mapping” tamlamasında “map” kelimesinin geçiyor olması. Eeee, tabi taa İngilizce öğrendiğimiz ilk yıldan bu yana biliyoruz, “map” “harita” demek. Dolayısıyla bu tamlama da “nesne-ilişkisel haritalama” olarak çevrilmelidir. Halbuki işin ruhu, yapılan işin mahiyeti ele alındığında ki bunu ayrıntılı olarak bu yazıda açıkladım, olan biten şey, iki farklı ortamdaki yazılım elemanının birbiriyle eşleştirimesi ya da birbirlerine karşı getirilmesidir. Bu durum bir maçta, savunan takımın oyuncularının, hücum eden takımın oyuncularını, savunma amacıyla “alması” ya da onlarla “eşleşmesi”nden başka birşey değildir. JPA’daki bu “eşleştirme” işlemi o kadar da işin merkezindedir ki, anlamak için öyle çok da uzman olmaya gerek yoktur. Örneğin, 5 günlük bir JPA ya da Hibernate eğitiminin ilk bir ya da iki saatinde bu eşleştirmeyi katılımcılara anlatmış ve basit de olsa bir örneğini vermiş oluyorum ben. Ondan sonra eğitim yoğun olarak bu eşleştirmeyle geçiyor. Yani buradaki durum, zamanında, kendilerine saygım sonsuz olmakla birlikte, “object-oriented” terimini dilimize, bu kavramın neyi ifade ettiğini, pratikte dillerde nasıl kullanıldığını tamamen bilmeden, iyi niyetle bir sözlük çevirisi yapanların halinden daha berbat. JPA ya da bunun en yaygın ürünü olan Hibernate’i, üniversitede bir Bilgisayar Mühendisliği 2. yıl öğrencisi biliyor, eşleştirme işini pratik olarak da bizzat yapıyor. Dolayısıyla aklım, yapılanın tabiatının “bir karşı getirme” ya da “eşleştirme” olduğunu bilmemize rağmen, neden sözlükte “map” kelimesinin ilk anlamını alıp, “haritalama” diyerek yeni bir “chicken translation” komedisi yaratıyoruza takılmadan edemiyor. Halbuki, biraz İngilizce bilen, “map” kelimesinin farklı bağlamlarda kullanıldığını ve bilmem kaç yüzyıl önce etimolojik olarak harita kavramından çıksa bile artık genel olarak İngilizce’de bir karşı getirme, bir eşleştirme anlamına geldiğini bilir. Örneğin, matematik’teki fonksiyonlar bir “mapping” yani karşı getirme ya da eşleştirmedir.

Gün geçmiyor ki yenilerde Facebook vb. yerlerde, eskilerde forum vb. paylaşım ortamlarında, “eğitimsiz” olduğunu düşündüğümüz özellikle esnaf kesiminden olan insanların yanlış ya da komik İngilizce tercümeleri yayınlanmasın. Peki biz “eğitimli”ler niye aynı şeyi yapıyoruz? “Batı’dan kopyalamak” acaba eğitimle falan ilgisi olmayan, tamamen kültürel bir öğe olarak taa zihnimizin derinliklerine işlemiş bir hastalık mı yoksa?

Merak ediyorum, “map” kelimesini “harita” diye çevirenler Windows’daki “Map Network Drive”ı nasıl çeviriyorlar? Ya da “Director or his/her proxy must be present in the meeting” kelimesindeki “proxy”i de bir ağ (network) elemanı olarak mı düşünüyorlar?

Her çeviri bir yorumdur. Her yorum da kaçınılmaz olarak %100 nesnel olamaz, bunun farkındayım. Ama yukarıdaki örneklerin bununla yakından uzaktan alakası yok malesef.

Toplam görüntülenme sayısı: 1302

Düşünce Azığı: Outliers (Çizginin Dışındakiler)

Kitaplar, Kültür, Bilgi ve Düşünce

Outliers (Çizginin Dışındakiler) –Bazı İnsanlar Neden Daha Başarılı Olur? – Malcolm Gladwell

MediaCat  9. Baskı – 2009 İstanbul

Malcolm Gladwell, Kanadalı aslıllı ve New York’ta yaşayan, bir araştırmacı, gazeteci ve yazar.  Gladwell, dördü de dilimize çevrilen, Tipping Point (Kıvılcım Anı) (2000), Blink (Düşünmeden Düşünebilmenin Gücü) (2005),  Outliers (Çizginin Dışındakiler) (2008) ve What The Dog Saw (Köpeğin Gördüğü) (2009) isimli, ABD’de çok satan kitapların yazarı. Yazar, her kitabında, hayatın tamamen içinde olan, herkesin bir şekilde az ya da çok bilgi ya da çoğunlukla his sahibi olduğu ama dile getirmekte zorlandığı bir konuyu ele alıyor,  kuvvetli gözlem ve delillerle anlaşılır hale getirip, sebep sonuç ilişkileri üzerinden giderek çözümlemeci bir yaklaşım sunuyor. Outliers’da da yaptığı, başarının bileşenlerini ele almak. Öncelikle Gadwell’in yaklaşımının, popüler kişisel gelişim kitaplarındakinden çok farklı olduğunu belirtelim. Gladwell, nasıl başarılı olabileceğinizi size öğretmeye çalışmıyor. Sadece, çok başarılı kişilerin hayatlarını ve başarı hikayelerini, kurduğu bir çerçeve içerisinde değerlendiriyor ve tezini doğrulamaya çalışıyor.

Gladwell Outliers’da dahiler, zengin ve güçlü avukatlar, rock yıldızları ve başarılı programcılardan yola çıkarak, “bireysel başarı” şeklinde ifade edilebilecek olan genel başarı algısının yanlış olduğunu ispatlamaya koyuluyor. Outliers’da iddia ettiği tez şu: Başarı, bireysel değildir. Başarı, ancak doğru şartlarda oluşabilir. Bu şartların pek çoğu ise kişinin elinde değildir, olsa olsa kişi, o başarıyı hazırlayan şartların içine doğar. Bu şartlar ise temelde zaman, toplum ve bu çerçevede ele alınabilecek olan imkanlar ya da şanslardır. Gladwell Outliers’ı, insanların başarıyı, başarılı insanların üstün zekalarına ve yeteneklerine atfetmelerini çürütmek amacıyla  yazdığını ifade ediyor. İnsanlar genel olarak, başarıda zirveye çıkmanın ancak çok sıradışı zeka ve yeteneğe sahip olmakla mümkün olduğunu düşünürler. Fakat Gladwell, normal bir zekaya sahip olduktan sonra başarı için bir bireyin yapabileceği tek şeyin çok çalışmak olduğunu vurguluyor. Peki çok çalışanların hepsi çok başarılı olabilir mi? Hayır olamazlar, çünkü, kişilerin doğduklarında kendilerini içinde bulundukları aile başta olmak üzere her türlü ortam ve zaman ile bunların sunduğu fırsatlar, onların başarılarında, zeka ve çalışmalarından çok daha etkilidir.

Outliers’in Türkçe çevirisi 224 sayfa ve MediaCat yayınları arasından 2009 yılından itibaren okuyucuya ulaşmış durumda. Kitap 9 bölümden oluşuyor. Akıcı bir dile sahip olan kitap, birkaç günde bitirilebilecek şekilde sizi kendine bağlıyor.

Kitabın ilk beş bölümü “Fırsat” başlığı altında, geri kalan dört bölümü ise “Miras” başlığı altında toplanmış. Fırsat kısmındaki bölümlerde başarılı kişlerin, nasıl fırsatlar dünyasına doğdukları inceleniyor. Miras başlığındaki bölümlerde ise atalar ve aileden gelen kültürel yapıların, başarıda oynadığı rol ele alınıyor.

Kitabın birimci bölümü “Matta Etkisi” başlığını taşıyor ve sosyologların “kümülatif avantaj” dedikleri olguyu, Kanada hokey ligindeki oyuncuların doğum tarihleri üzerinden açıklıyor. Kanada hokey ligi oyuncuları, ilkokuldan başlayıp devam eden okul liglerinde başarı gösterip sivrilen, en yetenekli oyuncular arasından geliyorlar. Ve Kanada okullarında o yılki hokey takımına seçilmenin yaş bakımından şartı, 1 Ocak’tan sonra doğmuş olmak.  Dolayısıyla takımda olan 1 Ocak doğumlu bir çocuk, aynı takımdaki 30 Aralık doğumlı bir diğer çocuğa göre çok daha gelişmiş ve yapılı oluyor.  Bu durum, bireysel liyakat prensibi üzerine kurulu olan bu sporda, en başarıların ezici  çoğunluğunun, yılın ilk aylarında doğmuş olanlardan çıkmasını sağlıyor. Ve Gladwell diyor ki, Kanada’da hokeyde ne kadar iyi olduğunuz ve ne kadar çok çalıştığınızdan daha önemli olan, yılın hangi ayında doğduğunuzdur.

Kitabın ikinci bölümünün adı “On Bin Saat Kuralı”. Bu bölümde Gladwell, doğru zamanda doğup, fırsatları değerlendirerek 10.000 saat çalışmış olma avantajını yakalayanların, şartların elverdiğinde, bu bilgi ve tecrübe ile, dallarında dünyanın en iyisi olduklarını vurguluyor.

Kitabın üçüncü ve dördüncü bölümleri “Dehaların Sorunu, 1. Bölüm” ve “Dehaların Sorunu, 2. Bölüm” isimlerini taşıyor. Gladwell bu bölümlerde, zeka ile başarı arasında bir zorunluluk ilişkisi olmadığını, dehaların hayatları ve onlar üzerine yapılan araştırmalardan yola çıkarak savunuyor. Yani yeterli zekaya sahipseniz, çalışmanız ve elinizde olmayan diğer şartların elvermesiyle, sizden çok daha yüksek zekaya sahip birinden pekala daha başarılı olabilirsiniz.

Beşinci bölüm, “Joe Flom’dan Alınacak 3 Ders”  başlığını taşıyor ve Avrupa’dan göçen yahudilerin, New York’ta nasıl zor şartlarda kendilerine yer edindiklerini ve yeni nesillerin, ailelerinin bu zorlu tecrübelerinin üzerine, zamanla, şartların değişmesiyle, oluşan fırsatları değerlendirerek nasıl başarıyı bina ettiklerini anlatıyor.

Altıncı bölüm “Kentacky, Harlan” başlığını taşıyor ve kültürel mirasın başarıdaki rolünü ele alıyor.

Yedinci bölüm “Uçak Kazalarına İlişkin Etnik Kuram” başlığını taşıyor ve pilotların içinde yetiştikleri kültürün, onlara empoze ettiği güç anlayışının, pilotların iletişim kurma biçimlerini nasıl belirlediğini ve bu durumun uçak kazalarının sebebi olarak nasıl ortaya çıktığını anlatıyor.

Sekizinci bölüm “Çeltik Tarlaları ve Matematik Testleri” başlığını taşıyor ve uzak doğuda, yüzyıllar boyunca, çok dar alanlarda ve çok dikkatli ve zahmetli çalışmalarla prinç yetiştiren insanların kültürü ile dillerinin, o topraklarda matematiksel zekanın gelişimini nasıl kolaylaştırdığı ele alınıyor.

Dokuzuncu bölüm “Marita’nın Pazarlığı” başlığını taşıyor ve ABD’de, sekizinci bölümde ele alınan kültürel yapıya benzer bir anlayışla kurulmuş özel yapıdaki bazı devlet okullarına kabul edilen ve bu fırsatın farkında olanların başarıya ulaşmalarını ele alıyor. Bu bölüm, başarının, ne sadece zeka ne de sadece çalışma ve yetenekle bina edildiğini, daha çok bir armağan olduğunu ve fırsatı değerlendirme güç ve soğukkanlılığını göstermeye bağlı olduğunu ifade ederek bitiyor.

Kitabın, “Bir Jamaika Hikayesi” isimli son sözünde ise yazar, kendi atalarını ve onlardan devraldığı mirası bize aktarıyor.

Gladwell’in kitaplarında sunduğu yaklaşım, bazı tekil olaylardan yaptığı çıkarımları genellemesinden dolayı eleştiriliyor. Bu anlamda kitabın bilimsel doğruluğu elde etmeye çalışmadığını söylemek gerekir. Dolayısıyla, kitap, doğruyu tam olarak ifade etmekten çok, doğrunun bir kısmını güzel bir şekilde ortaya koymuş olmakla övülebilir.

Kitap, bir cümlede özetlemek gerekirse, “başarılı insanlar yoktur, başarılı toplumlar vardır” fikrini güzel bir şekilde savunmaktadır.

Toplam görüntülenme sayısı: 3436

Genç Yazılımlılar İçin – I

Diğer, Yazılım Mühendisliği

Gerek yüzyüze görüştüğüm gerek ise email yoluyla bana ulaşan gençler, çok sıklıkla benden “yol gösterme” istiyorlar. Hepsine ayrı ayrı birşeyler yazmaya çalışıyorum ama bir müddet sonra bunları topluca ifade etmenin daha faydalı olduğunu düşünüp bu yazıyı kaleme aldım. “Yol gösterme” isteği ile ilgili öncelikle şu iki şeyi belirtmem lazım. Benden yol gösterme ve tavsiye isteyen gençler öncelikle hakkımda hüsn-ü zanda bulunup, bana büyük bir sorumluluk yüklüyorlar. Bu durum onların iyi niyetini gösterirken beni ise sıkıntıya sokuyor. Öte taraftan gençlerin bu isteği tamamen bir ihtiyaçtan kaynaklanıyor. Her toplumda, önden gidenler, bilgi ve tecrübelerini arkadan gelenlarle paylaşırlar; bundan daha tabi birşey olamaz. Bu konuda belki dikkat edilmesi gereken şeyin, herkesin kendi tecrübesinden elde ettiklerini paylaşıyor olmasıdır, dolayısıyla her paylaşım da tabi olarak pek çok şahsi kanıyı ve tecrübeyi içinde barındıracaktır. Ülkemizde yaygın olan düşünce yapısının taklitçi ve detaycı olduğunun çok iyi farkındayım. Yani düşüncemiz yapımızda özgünlük az ve soyut kavramlar yerine tek tek olaylarla ilgilenerek vaktimizi harcıyoruz. Tek tek olaylardan yola çıkarak, sistematik olarak, soyut bir düşünce dünyası kurgulamaktan çok uzağız. Dolayısıyla da büyük resmi görmekte zorlanıyoruz. Eğitim kurumlarımız, eğitim ve gelişimi, kuru malumat ile problem çözme olarak ele aldıklarından, soyut düşünce yapımızın gelişmesine katkıda bulunmuyor. Bu da tek tek ağaçları gören ve sayan ama ormanda olduğunu farkedemeyen bireyler ortaya çıkarıyor. Dolayısıyla önden gitmiş olanların bilgi ve tecrübeleri, ormanı farketmek için daha önemli hale geliyor. İşte acizane tavsiyelerim:

  1. Öncelikle kendinizi tanıyın. Yazılım dünyasıyla ilgili nelerden hoşlanıyorsunuz, neleri yapmak size zevk veriyor, merakınız ne yönde gibi sorularla başladığınız bu tanıma süreci, nelere yeteneğim var şeklinde daha zor soruların cevabını alacak şekilde daima aklınızın bir yerinde çalışır halde olsun. Kendinizi ne kadar erken tanırsanız o kadar isabetli karar verirsiniz. Bir kişinin kendini tanıması zor ve ömür boyu süren bir faaliyettir, bunun farkındayım. “Kendini bilmek”, dini olsun olmasın her hikmet kaynağı disiplinin en temel öğretilerindendir. Kendinizi tanıdıkça, toplumda kol gezen ideolojik söylemlere kanmaz, daha sağlıklı adımlar atarsınız. (Bu konuda “Her Zeki Öğrenci, Programcı mı Olmalı?” başlıklı yazıma gözatabilirsiniz.)
  2. Odaklanın.  Gençlerde gördüğüm en temel sıkıntı, bir odaktan yoksun olmaları. Kendine bir konu belirlemiş ve o konunun üstadı olmak için var gücüyle çalışan gençler yerine, her çiçekten bir damla almaya çalışan gençler görmek çok daha ihtimal dahilinde malesef. Bu da pek çok konudan birşeyler bilen ama hiç birini tam olarak kavramamış, dolayısıyla da bir şeyi baştan sona ele alıp çözme yeteneğini haiz olmayan kişiler demek. Çok sık sahit olduğum şeylerden birisi: Hem Oracle veri tabanı, hem Java hem de Cisco için sertifika almayı planlamak ya da ne bileyim sadece birkaç yıllık kariyerinde üç-beş tane Java ya da .Net gibi heyula bilgi birikimine sahip yapılarla uğraşmış olup, hiç birinde bir projenin farklı katmanlarını, farklı vechelerini tam olarak görmemiş ve hiçbirinde yetkin bir duruma gelmemiş olmak. Günümüzde dünyasında “genişlik” yerine “derinlik” daha önemli. “Genişlik” ancak farklı ama ilişkili konularda derinleşerek elde edildiğinde anlamlı olur. Yüzeysel, “turistik” seviyedeki malumatın, yetkinlik açısından önemi yoktur. Dolayısıyla hedef belirleyin, odaklanıp, gerektiği kadar üzerinde çalışın, belli bir yetkinlik seviyesine gelin, sonra ilgili bir başka yan alana geçin öyle ki ikisi bir araya geldiğinde anlamlı bir bütün oluştursunlar.
  3. Bilgi hiyerarşisine önem verin. Temelleri anlamadan ileri konulara dalmayın. Yani daha iyi bir ifade ile “bilgi sahibi olmadan fikir sahibi olma” hastalığına kapılmayın. Unutmayın bu bizim milli hastalığımız. Gerçekliği kavramak için önce onu ciddiye alın, en temelinden başlayarak anlamaya çalışın, sonra üzerinde yorum yapın. Dolayısıyla okulda “Operating Systems” derslerine girmeden Android ya da Linux gurusu olma hayaline kapılmayın. Kendisine hayranlık duyduğunuz o işletim sistemlerinin ya da programlama dillerinin yaratıcıları ya formal ya da informal yollarla, ama muhakkak en temelinden başlayarak kendilerini yetiştirmişlerdir. Pek çoğu Stanford ya da MIT gibi okullardan doktora sahibidir. Pek çoğu, okuldayken “gerçek hayatta ne işimize yarayacak bu” diye sorduğumuz Matematik derslerini ya da hocasını beğenmediğimiz için derslerini astığımız mesela Algorithms dersine gereken önemi vermiştir. Formal bir eğitim imkanı bulamayanların ise bir şekilde tırmalayarak gerekli altyapıyı kazandıklarını görürsünüz. Dolayısıyla şu ya da bu şekilde, en temel Matematik, İşletim Sistemleri, Algoritamlar, Veri Yapıları vb. konularda gerekli altyapıya önem vermeden, aklınıza gelecek süper bir fikirle yeni bir Steve Jobs olmayı düşünüyorsanız, büyük bir ihtimalle ne eğitim ne başarı ne de Jobs hakkında fazla birşey bilmiyorsunuz demektir. Bunun için “Outliers” kitabı iyi bir başlangıç olabilir.

Şimdilik bu kadar. Aklıma geldikçe yenilerini paylaşacağım. Fikirlerinizi ve eleştirilerinizi her zaman beklediğimi ifade etmeliyim.

Toplam görüntülenme sayısı: 2307

«< 57 58 59 60 61 >»