Genç yazılım geliştiricilere ‘dark side’dan öğütler
Arama
Yazılım

Genç yazılım geliştiricilere ‘dark side’dan öğütler

Açıklama: Webrazzi’de yeni bir yazı dizisiyle karşınızdayız. Türkiye internet sektörünün tecrübeli yazılım geliştiricilerini teker teker Webrazzi.com’da konuk edip, kendilerinden genç yazılım geliştiricilere olan tavsiyelerini ve tecrübelerini dinliyoruz.

Konuk yazarımız Osman Yüksel; sahibinden.com, Kartaca, Tart New Media ve Rocket Internet gibi şirketlerde yazılım geliştirme üzerine çalışmış, şu an kendi kurduğu Sonsuzdöngü‘de çalışmaktadır.

come-to-dark-side-cookiesGözlemlediğim kadarıyla, iki ana tip yazılım geliştirici grubu var. Birinci grup açık kaynak yazılım dünyasına daha yakın olan, startup kültürüne daha yakın firmalarda çalışanlar. İkinci grup ise kurumsal dünyaya daha yakın çalışanlar. (bankalar, askeri projeler, sağlık sektörü yazılımları vs.)

Sanırım üniversite yıllarımda birinci gruba daha yakın olduğumdan, profesyonel yaşantımda açık kaynak dünyasının içinde buldum kendimi. Startup kültürüne yakın şirketlerde çalıştım.

30’una gelmiş bir geliştirici olarak da, haddim olmayarak, genç geliştiricilere, en azından birinci gruptan edindiğim tecrübelerle bazı tavsiyeler vermek isterim.

Normalde burada, herkesin duymak istediği şu tip şeyler söylemem gerek:

  • Eğer okuyorsanız, o zamanınızın kıymetini bilin. Okuldaki, başta yazılım kulüpleri olmak üzere kulüplerde görev alın, etkinliklere katılın
  • Açık kaynak projeleri inceleyin ve elinizden geldiğince kod veya çeviri desteği yapmaya çalışın. Çeviri yaparken bile ne çok şey öğreneceğinizi tahmin dahi edemezsiniz.
  • Kendinizi sadece okulda gördüklerinizle sınırlamayın, eğer bir konuyu merak ediyorsanız dersi almayı beklemeden araştırıp öğrenmeye çalışın
  • İmkanınız varsa yurt dışındaki büyük şirketlerde staj yapmayı deneyin
  • Google Summer of Code gibi organizasyonlara katılın, “büyük topluluklar bu işi nasıl yapıyor” daha yakından görün.
  • Yazılım geliştirici toplulukları içinde aktif olarak görev alın
  • HackerNews, reddit, stackoverflow gibi sitelerden sektörü takip etmeye özen gösterin.
  • Bir şirkette çalışıyorsanız; şirketi sahiplenin, sorumluluk almaya çalışın
  • Sadece çalışmak için bir şirkette çalışmayın. Gelişiminize katkısı olacak, şirket kültürünü önemseyen bir şirketi tercih edin.
  • Kendinizi her zaman teknik olarak geliştirmeye çalışın
  • Kod yazarken düzenli olmaya ve kullandığınız dilin kurallarına bağlı kalmaya özen gösterin. Temel yazılım mühendisliği prensiplerine bağlı kalın. KISS, DRY prensiplerini benimseyin.
  • Mümkünse kodlarınızın testlerini yazın
  • İşinizle ilgili verdiğiniz sözlere sadık olun. Dürüstlük her zaman kazandırır
  • Öğrendiğiniz şeyleri içinde bulunduğunuz yerel topluluklarda paylaşın (konferans, meetup, vs.)
  • Kodunuzu, sizden sonraki geliştiricilerin de geliştirmeye devam edeceğini unutmayın. Sürdürülebilir kod yazmaya özen gösterin.
  • Sürüm kontrol yazılımlarını kullanmayı tercih edin. git/mercurial/svn/bazaar gibi araçları tanıyın; mümkünse tüm yazdıklarınızı açık kaynak olarak github, jsfiddle vb. sitelerde paylaşın.
  • Kendinize ait bir web siteniz olsun

Süper bir geliştirici değilim, profesyonel iş yaşantımda, çok iyi bir geliştirici olmasam da yukarıdaki prensiplere olabildiğince sadık kalmaya çalıştım. Üniversite yıllarımda çeviriler yaptım zaman buldukça, açık kaynak topluluklarda aktif görevler aldım. İş yaşantımda, görev tanımımda hiç olmayan sorumluluklar aldım, kendimi teknik olarak her zaman geliştirmeye çalıştım. Dökümanlar yazdım, çeşitli etkinliklerde yukarıdaki maddeleri aşılayan sunumlar yapmaya çalıştım.

Yakın zamana kadar da tavsiye isteyen gençlere yukarıdaki maddeleri sıraladım. Ta ki tavsiyeyi verdiğim gençlerden birisi “Neden?” sorusunu duyuncaya kadar:

  • “Neden bu kadar çabalamalıyım?”
  • “Neden üniversite okumalıyım? Üniversite okumak bana bir şey kazandıracak mı?”
  • “Neden şirketi sahiplenmeliyim? Şirket beni gerçekten sahiplenecek mi?”
  • “Neden düzgün kod yazmalıyım? Düzgün kod yazınca daha fazla mı maaş alacağım?”
  • “Bu kadar çabanın karşılığını alabilecek miyim?”

Cevab veremedim 🙁

osman-yuksel
Osman Yüksel

Yazılım maalesef, ölçümü çok zor olan bir alan. Yabancıların “You can’t manage what you don’t measure” lafına istinaden de “yönetimi” zor bir alan. Ölçümü zor olsa da nispeten mümkün olduğu halde bu ölçüm çoğu yerde yapılmıyor. İşin “Business” tarafı için de, çoğu zaman haklı olarak hızlı çıkan ürün her zaman kaliteli üründen daha kıymetli oluyor.

Ama biz yazılım geliştiriciler bunu anlamakta biraz zorlanıyoruz, zira bizi bu işe bağlayan en büyük şey “güzel bir şeyleri, son teknolojilerle dökümanlarda kitaplarda okuduğumuz şeyleri uygulayarak üretme hazzı“. “Kendimizi geliştirelim, daha iyi kod yazalım!” aslında business dünyasının çok da umrunda değil. Startup Business’lar, az önce de söylediğim gibi, her zaman hızlı çıkan ürüne değer veriyor, ve bunda oldukça haklı sebepleri var. Sizin hangi dili, hangi teknolojiyi, hangi metodolojiyi kullandığınız onların umurlarında değil. Business tarafı, işin ne kadar sürede ortaya çıktığı ve ne kadar iyi olduğu ile ilgileniyor. Böyle olunca analiz ve test süreçleri de bir “gereklilik” olarak öngörülmüyor ve günün sonunda kaliteden ödün veriliyor.

Peki hızlı ve kaliteli ürün mümkün değil mi?” sorusunu sorduğumuzda da bu işin ölçümünü yapmanın, kısaca kaliteyi belirlemenin ne kadar zor olduğunu ve bunun çoğu yerde yapılmadığı/yapılamadığını görüyoruz.

Ve tekrardan soruyoruz:

  • Neden düzgün kod yazmalıyım? Neden düzgün kod yazmak için kendimi geliştirmeliyim? Neden buna zaman harcamalıyım?“.
  • Kimse düzgün kod yazdım diye daha fazla para vermiyorsa neden bu işe emek harcamalıyım?
  • Daha fazla sorumluluk alınca kimse daha fazla para vermiyorsa neden sorumluluk almalıyım?
  • Daha sonra karşılığını alamayacağım bir yatırımı neden yapayım?

Başka bir konu da şu ki; bu işin ölçümü yapılıyor olsa bile, 10 kat daha iyi geliştirici maalesef 2 kat bile fazla ücret alamıyor. O zaman:

  • 10 kat iyi geliştirici olmak için çaba sarfetmeye gerek var mı?

Bu sorulara “Ee gerek yok o zaman?” cevabı veren yazılımcılar bir anda kendini yazılımın karanlık tarafı olan DGOP dehlizinde buluyor. Böyle bir durumu görünce de maalesef tavsiye isteyen gençlere verdiğiniz cevaplar değişmeye başlıyor. Onlara ister istemez “10 kat iyi geliştirici olmayın, karşılığını alabileceğiniz kadar kendinize yatırım yapın. Çalıştığınız işi sahiplenmeyin. Şirketler sahiplerinindir. Onlar hancı, siz yolcu. Patronunuz babanız, işiniz eviniz değildir.” gibi dark side’dan öğütler vermeye başlıyorsunuz.

Ve sektör, bir şekilde ölçümlemeyi, ölçümledikten sonra düzgün yönetmeyi ve ödüllendirmeyi başaramadığı sürece de karanlık tarafın oldukça güçleneceğini görüp hüzünleniyorsunuz. Halbuki, genç geliştiriciler, Obi-Wan’ın da dediği gibi “güce dengeyi getirecek seçilmişler olmalı”.

Yorumları GösterYorumlar Gizle (28)
  1. aydin dedi ki:

    Sitedeki üslup dili gerçekten çok hoşuma gitti.
    tebrik ediyorum 🙂

  2. genç sith dedi ki:

    Genç Sith’ler rahatsız!

  3. 38 Years Old Developer dedi ki:

    ve lütfen yapamadığınız beceremediğiniz bir iş için saatlerce günlerce bir engelde takılıp kalmayın, önce google amcaya sonra da bir büyüğünüze sorun, hızlıca çözün ve devam edin.

  4. Enver Gökmen dedi ki:

    ne olacak bu yazılımcıların çilesi.

  5. Alper Kanat dedi ki:

    En kısa sürede antitezimi yayınlayacağım 🙂

    1. Osman Yüksel dedi ki:

      “Powerful you have become, the dark side I sense in you.” – Yoda :p

  6. Bir yazılımcı dedi ki:

    zira bizi bu işe bağlayan en büyük şey “güzel bir şeyleri, son teknolojilerle dökümanlarda kitaplarda okuduğumuz şeyleri uygulayarak üretme hazzı“.

    Aslında bizi en iyi anlatan bölüm burası.

    Ama iş sahiplerinin de haklı olduğu noktalar var tabi ki hızlı olmasını istiyorlar sonuç istiyorlar. Sonuç odaklılar.

    ooouuuff of Allah herkese sabır versin 🙂

  7. Metin Çoban dedi ki:

    İlk baştaki öğütleri okuyunca sevindim, sonra işin dark-side tarafını okuyunca sinirlendim “gençlere böyle mi örnek oluyorsunuz” diye düşündüm.

    Sorna tekrar düşündüm ve aslında kendimin uzun zaman önce karanlık tarafa geçtiğini farkettim.

    Güzel ama acı bir yazı olmus

  8. Çok doğru tespitler. Maalesef tüm gerçekleri acı bir şekilde söylemiş Osman Yüksel.

    Buradaki sorun temel algının değişikliğinden kaynaklanıyor bence. Yazılımcıların örnek aldığı firmaların (Silikon Vadisi) ürün çıkarma süreçleri daha çok “Technology Driven Product Management” iken, Türkiye’de işler -tüccar bir gelenekle- daha çok “Business Driven Product Management” üzerinde yürüyor. Bu arada oluşan açık da tam olarak Osman’ın bahsettiği sorunlarla dolup taşıyor.

    Bu biraz da eski dönem “sanat için mi sanat, toplum için mi sanat” tartışmasının günümüzdeki yansıması gibi. Business, teknolojinin her zaman kendisine hizmet etmesi gerektiği inancındayken, bir geliştirici için teknoloji kimi zaman sadece teknoloji olabiliyor.

    Yanılmıyorsam Peyami Safa’ya, “hangi kitaplarınızı daha çok seviyorsunuz” diye sorduklarında “para için yazmadıklarım” cevabını veriyor. Buradan da aynı çıkarımı yapabiliyoruz; “business driven” ürünlerin, “technology driven” ürünlere nazaran kalitesiz olma potansiyeli daha yüksek. Çünkü endişeler farklı, amaçlar farklı. Ve bu endişelerin olmadığı bir ekosistemde bir yazılımcının bu endişeyi taşıması o sistem için yazılımcının işini iyi yapmıyor olmasına denk. Çünkü yazılımcının o ekosistemdeki işi teknoloji geliştirmek değil, business’a hizmet etmek.

    Her anlamda çok başarılı ve farkındalığı artıran bir yazı olmuş. Teşekkürler.

  9. Akil Bilgin dedi ki:

    38 Years Old Developer arkadaşın dediğin doğru..Developer’lık ile coder’lik kavramlarınıda ayırmak gerekiyor ki bu mevzu cok su götürür.Nacizane önerim bir amacınız olsun.. Bunun için çalışmak koymaz.. O zaman bulunduğunuz durumun geçici olduğunu bilerek profesyonelce davranmaya , incitmemeye ve önemlisi büyük resmi görenlerden olmaya yönelik bir tutum içinde olursunuz ki bu da zaman zaman “amk nerden buluyor bu enerjiyi.. WTF.. =!!_^+^?=+? ” gibi yorumları duymanıza sebep olur..

    Nacizane bir önerim de efendi olun.. Bilginizle hava taslamayın bundan dolayı hava taslıyorsanız “ezik” olmaktan öteye gidemezsiniz. İnsan olun , herkesin sizi sevmesi gerekmez ama işini gerçekten iyi yapana herkes saygı duyar ki bu zamanda saygı duyulası işler yapmak ayrıca takdire şayan.

    Ha ayrıca Osman’ın da dediği gibi paylaşın..

    Bu ülkede niye Open Source kod yok demeyin paylaşın ki olsun.. Kalite yükselsin…

  10. Çok güzel ve gerçekçi bir yazı olmuş, harbiden de durum böyle ne yazık ki. Ama ben kendime (bu neden soruları karşısında) şu cevabı veriyorum; Bilgi açlığımı gidermek için, merakımı gidermek için ve gerçekten sevdiğim şeylerle uğraşarak zaman geçirmek için. Tamam kendimi bu cevaplarla tatmin ediyorum belki bir yere kadar ama işin birde maddi kısmı var e aç kalacak ta değiliz tabi bilgimizin paraya paranında bizim ihtiyaçlarımıza dönmesi gerekli. Ben şahsen Türkiye’de özel yada kamu kuruluşlarının hala ( yıl olmuş 2014 🙂 ) yazılımcılara bakış açılarının çok umutsuz vaka olduğunu düşünüyorum. Çok yol alınması gerek ama yolu gören yok gibi bir durum var ortada.

  11. Enes Gür dedi ki:

    Yazıya olduğu gibi katılıyorum, benim gibi genç geliştiriciler ne kadar iyi kod yazarsa yazsın, ne kadar düzgün kodlanırsa kodlansın en nihayetinde kötü yada iyi fark etmeden çalışan sistemle bir tutulduğu zaman içimizdeki geliştirme istediğini yok etmiş oluyorlar.

    Tabi sorun tamamiyle iş verenin yada projeyi başlatan firmaya ait değil. Asıl sorun bu işi denetleyen gözlemleyen proje sorumlularının kullanılan teknolojilerden bir haber olmasıdır.

  12. Volkan AKKUŞ dedi ki:

    Her insana aynı formül olmaz. Silver bullet yok demiş, eskiler.
    Sadece yazılım yapmak sizi memnun ediyorsa, paraya bakmayın. Para memnun ediyorsa da, başınızı sallayın.
    İkisini birden isterim diyorsanız da gerçekten çok niş,aranan bir özellik/bilgi edinin, para sizin peşinizden koşsun.
    “Hem az çalışayım, hem kimse bana karışmasın canımın istediğini yapayım” derseniz, o da olur da, sabaha uyanmak gerekecek.

  13. HakaN dedi ki:

    Developer’lık ile coder’lik kavramlarınıda ayırmak gerekiyor

    işin özeti

  14. bcakir dedi ki:

    Yazıya katılmakla birlikte, bu yazıda eksik bir nokta görüyorum. Eğer çalıştığınız şirket sizden spagetti kod üretmenizi istiyorsa ya da diğer bir deyişle, 30 kişinin elinden geçmiş bir nevi çorbaya dönmüş kodu sende o şekilde yaz ama işi bitir diyorsa napacaksınız? Tek çareniz kendinizi geliştirmek yerine o şekilde yazıp işi teslim etmeye çalışmak. Ben denedim, çok büyük bir spagetti kodda refactoring yaparak işin bitme ihtimali yok.

  15. Megacephalis dedi ki:

    Elinize saglik cok guzel bir yazi olmus ama benim bir kac yorumum olacak fakir bir business tarafi olarak… oncelikle aldigim bir kac programlama kursundan sonra isinize saygim cok artti kesinlikle… ama bana daha fazla para vermiyorlarsa neden kendimi dugun koda yazmaya zorlamaliyim veya kendimi gelistirmeliyim sorusu bence yanlis…

    kod yazan arkadaslarin kendini cok erken zamanlardan itibaren gelistirmesi fikrine sonuna kadar katiliyorum… hic bir patron elemanini cok sevdigi icin calistirmiyor, onun isine yaradigi icin calistiriyor ama ayni zamanda calisanda orada kendince bir fayda icin bulunuyor… insan kendi isini baskasi icin gelistirmez, sadece hava atmak icin yeni seyleri ogrenmek icin isten arta kalan kisa zamanini da ekran karsisinda gecirmez… kendi hayalleri icin, ulasmak istedigi bir hedef icin yapar… bence calisanlar da projelerini kendi hayallerine gore secip sadece para degil kendini gelistirme firsati da yakalayabilirler… ama “cok calisiyorsun sirketi sen mi kurtaracaksin?” veya ” bu sirketin enayisi sen misin?” gibi yorumlara eger gulup gecmiyor hatta sinirleniyorsaniz bence yaptiginiz isle ilgili bir hayaliniz yok demektir…

    ben yillardir lojistik isi icinde kodcularla calismis birisi olarak surekli yeni bir seyler yaratma fikriyle ogrenemeye calissam da basaramadigim kod yazma isini sadece para kazanmak icin yapiyor olmak bence cok agir bir yuktur… tum kodcularin parmaklarina ve gozlerine saglik dilerim…

    son not: turkiye’nin toplam ihracati icinde yazilim ihracati %0,2 iken israil’de oran %25… tek eksigimiz hayallerimize dogru kosarken “enayi” yakistirmasina gulup gecebilmek ve o ekstra emegi neden verdigimiz bilmek…

  16. “Daya Geç Yönelimli Programlama” terimi supermis 🙂

    Yazilim gelistirmek tamamen tutku isi, ve tutkusu olmayan insanlar da DGYP yapiyor malesef.

  17. Yıllardır aramızda konuşup bir türlü halka haykıramadığımız bu konuyu kaleme alan Osman’a ve yayınladığı için Webrazzi’ye kocaman bir teşekkür ediyorum.

    İşler “laz müteahit” zihniyetiyle yapıldığı sürece, bizler bu konuları daha çok konuşacağz. “Kervan yolda düzülür”, “Biz döküman yazmıyoruz, iş yapıyoruz!”, “class yazma yavaş oluyor”, “analiz bottleneck oluşturuyor. Biz bi yazalım hele sonra bakarız.”

    Business, yazılım geliştirme süreçlerinin yalnızca kod yazmaktan ibaret olmadığını, analiz ve test süreçlerinin OLMAZSA OLMAZ! olduğunu, minimum 1 ay sürecek bir projenin dökümantasyonun yalnızca bir A4 kağıdından oluşamayacağını, mockup a bakıp süre tahmini yapılamayacağını, bir web projesinin, önyüz kodlamasının tamamlanmasını takip eden 2 gün içinde production’a çıkamayacağını ve son olarak prototip denen şeyin ne olduğunu öğrendiği gün hayat güzel, günler güneşli, benzin 1 TL olacak…

  18. Cihangir SAVAS dedi ki:

    > Mümkünse kodlarınızın testlerini yazın

    bunu okuduktan sonra devamini okumadim 🙂

    herzaman `testlerinizin kodunu yazin` diyen adama ne olmus 🙂

    1. Osman Yüksel dedi ki:

      Dark side’a geçmiş işte 😉

  19. Hasan dedi ki:

    Programcilari bir dogru üzerinde bir noktaya yerlestirecek olalim. Bana göre bir uçta “ürüne odaklanmis programcilar” dedigim kesim, diger uçta ise “olaya odaklanmis programcilar” dedigim kesim bulunuyor.

    Ürüne odaklanmis programcilar için programlama dili ya da gelistirme ortami tamamen bir araçtir. Ortada bir proje vardir. Ya da kafada bir fikir vardir.

    Amaç bu projeyi ya da fikri gelistirerek ürün haline getirmektir. Bunu saglayacak en kolay araç en iyi araçtir. Bu tür programcilar olaylarin nasil gelistigini pek merak etmezler. Merak etseler de bu meraklarini kolaylikla bastirabilirler. Örnegin, onlar için klavyenin nasil çalistiginin, görüntünün ekranda nasil olustugunun, isletim sisteminin programi nasil yüklediginin, dosyalarin diskte nasil tutuldugunun hiç önemli yoktur. Önemli olan ürünün kendisidir. Bu tür programcilar kolay kullanilabilen, hizli ögrenilebilen, gelistirme sürecinde kendilerini sonuna kadar destekleyebilecek, yüz üstü birakmayacak programama dillerini ve araçlarinitercih ederler. Ürün gelistirecek düzeye çabuk gelirler. Iyileri çok güzel projeler çikartir. Kötüleri kullanici ile gelistirici olma arasinda gidip gelirler…

    Halbuki olaya odaklanmis programcilar üründen çok olaylarin nasil gelistigi üzerinde kafa yorarlar. Olaylarin hep nasil gerçeklestigini merak ederler.

    Bu meraklarini bastiramazlar. Onlar için ürünün gelistirilmesi ikinci plandadir. Olaylarin nasil gerçeklestigini bilmeden bir sey yapmak istemezler. Bu tür programcilar örnegin gelismis araçlari kullanmak istemezler. Yüksek seviyeli kütüphanelerden nefret ederler. Her seyi kendileri yapmak isterler. Her zaman daha ayrintiya inerler. Bazen durum amacindan sapar, obsesif bir hal alir. Standart ezberlemeye kadar gider…

    Olaya odaklanmis programcilarlarin sirket patronlariyla ve ürüne odaklanmis programcilarla arasi pek iyi degildir. Patronlarla iyi degildir, çünkü patronlar için amaç ürünün kendisidir. Programcinin olayin ayrintilarini anlama güdüsü yüzünden ürünü gelistirmekte geri kaldigini farkederler. Ürüne odaklanmis programcilarla arasi iyi degildir, çünkü kendilerinin bu kadar ayrintisiyla bildigi konularin hiç bir ayrintiyi bilmeden ve neredeyse daha ise yarar bir biçimde çarçabuk olusturulmasi onlari içten içten sinirlendirmektedir. Neyse ki derinlemesine bilgi gerektiren konular söz konusu oldugunda bu tür programcilar devreye girerek küçük ama önemli kodlarla kendilerini kurtarirlar. Yaptiklarini çok az kisi yapabildiginden saygi da görürler. Olaya odaklanmis programcilar asagi seviyeli dillerle islerini görürler. Bu tür programcilarin is görür noktaya gelmeleri uzun zaman alir. Ürüne odaklanmis programcilarla olaya odaklanmis programcilarin ögrenme ve konuyu ele alma sistematigi ve süreci tamamen farklidir.

    Ürüne odaklanmis programci ve olaya odaklanmis programci olmak çogu kez kisinin bilinçli bir seçimiyle olmaz. Bu olusumun kisilikle, geçmis deneyimlerle, tutumlarla ilgisi vardir. Ürüne odaklanmis bir programci zorla olaya odaklandirilamayacagi gibi tersi de söz konusu degildir. Zorlamalar iyi sonuç da vermemektedir.

    Ürüne odaklanmis ve olaya odaklamis programcilar iki uç noktayi temsil ediyorlar. Kisiler bu dogru üzerinde çesitli yerlerde olabilirler. Ben iki gruptan da çok kisi tanidim. Örnegin, ürüne odaklanmis bir arkadasima ne zaman “Ya bunu gerçekten merak etmiyor musun?” diye sorsam bana hep söyle yanit verirdi. “Yoo neden merak edeyim ki?” Ya da örnegin, tipik bir olaya odaklanmis programci olan ögrencimiz is yerinde yüksek seviyeli bir araçla çalismak zorunda birakildiginda patronuna “kusura bakmayin bünyem kaldirmiyor” demisti.

    CSD kurucusu, Kaan Aslan’ın 2002 yılında anet news grubunda yazdığı bir entry’den alıntıdır.

  20. Aygül Hayal dedi ki:

    sonsuzdöngü’nün hakkımızda sayfasında şu ifadeler geçiyor;
    “PHP, MySQL ile back-end’ini yazdıkları, yeri geldiğinde Memcached, Redis, Varnish, RabbitMQ gibi araçları düşmanlarına karşı kullanmaktan çekinmeyen, bunun üzerine Front-end tarafında atalarından edindikleri öğretiler ile hızlı ve sorunsuz arayüzler ile düşman kuvvetlerine korku salan, ‘Software Development Lifecycle’da gördükleri vatan hainliklerini temizlemeyi kendine görev addetmiş, PHP/MySQL, JavaScript, HTML/CSS, Git/Gitosis, PHPUnit, Jasmine gibi uzun menzilli silahları diğer ordu askerlerine de öğretmeyi borç bilmiş bu ekip, Kadıköy ovasında ilk yerleşkesini edinmiştir.”
    ülkemizde böyle yazılımcılar görmek güzel şey doğrusu.

  21. Gökhan E. dedi ki:

    Uzun oldu ancak okunursa mesaj verir diye umuyorum.

    Framework veya shared development area veya subversion gibi sürdürülebilirlik adına kullanılan tüm alet edevatı ve aynı şekilde bunların öğrenilmesini kamçılayan, aynı zamanda – gençlere – bilinç aşılayan yazını gerçekten jargonundan ötürü beğendim. Bir geliştiricinin bir diğer yükünün işletim sistemi olduğunu söylemenide isterdim.

    .NET geliştiricileri için obje yönetimi bulunduğundan ötürü bu ve bunun gibi otoriter dillerde çoğu kez sürdürülebilirlik konusunda sürekli devam eden problemler yok lakin PHP, Python gibi open source ve sık kullanılan geliştirme dillerinde şöyle bir sorun var.

    1. Seçilebilir fazlaca framework bulunuyor, buda hem işverenin uzun zaman kaybetmesine, hemde çalışanın bir kez daha düşünmesine veya kem küm demesine neden oluyor.

    2. Çok fazla extension / plugin gibi araçlara ihtiyacınız var. Haliyle bir dili bilmek ile o dilde hızlı çözüm üretmek konusunda tecrübeli olmak ne yazık ki junior yada senior kimliği kazanmanızı sağlamıyor. Bugün mysql_query() kullanan bir PHP’ci senior ve mysqli class kullanan bir PHP’ci ise juior olarak sınıflandırılabilir, kanımca bu düpedüz kendini geliştirmeyen bir kişi olduğunu kabaca ortaya koyar. Üstelik buna bunlardan haberi olmayan ve sadece framework kullanmayı bilen PHP geliştiricilerde dahil.

    3. Bir dilin hangi işletim sistemi veya platformda çalıştığını bilmeyen senior yazılımcı olmaz. Bu, iyi sürücü olduğunu söyleyen ancak hiç kaputu açıp motoruna su koymamış bir şöföre benzer. Şöförün sorumluluk sahası, direksiyon, gaz, fren ve aynalar değildir. Motor yağsızlıktan kol kırarsa onlarca insanı hayatından edebilir, projelerde böyledir.

    4. En önemlisi ise proje yöneticisi / ekip lideri / şirket sahibi veya o anda kendini o birimin tanrısı sanan kişinin / kişilerin neyi sevdikleri konusu. Tıpkı bir futbol takımı severcesine, tıpkı Windows 2003’den vazgeçmeme pahasına ve tıpkı CentOS 5 vs CentOS 6 güvenliği konusunda diretenler gibi, neyi kullanabiliyorlarsa veya seviyorlarsa yeni yazılımcıda bunu öğrensin isterler, asla kendilerini bir adım öteye geçirmezler. İşe başlayacak kişi bununla ilgili dökümanlara zaman harcasın, deli gibi ingilizce bilsin, orada kullanılanları öğrenmek zorunda kalsın ve bol bol ufuksuz kişilerin ona statü belirten takma hitaplarda bulunmasını isterler. Bu bir gerçek ki; şunu düşünmezler: Bu gerçekten bu yazılımcıya gerekli mi? Çünkü yazılımcıya gerekliyse kendisine eminim ki gereklidir. Yazılımcıya gerekli değilse, iş savuşturma şeklinde ilerliyordur ve bu yazılımcının uzun vadeli hayaller kurmasını engeller, peki ya sonra?

    Benimde affınıza sığınarak kelamım şu şekilde; Proje veya iş sahibi olarak bir çalışanı işe alacaksanız yada freelance dahil outsource bir iş setleyecekseniz ve herhangi bir framework veya herhangi bir subversion kullanıyorsanız bir çalışana yada çalışacak arkadaşa dayatma yapmadan önce lütfen kullandığınız alet edevatın ne olduğunu, kullanılabilirliğini, hayatı ne kadar kolaşlaştırdığını, gelecek junior veya senior yazılımcıların gelecekteki çalışma hayatını ne kadar sağlıklı kılacağını düşünün. Düşünün ki; daha sonra tekrar birlikte çalışabileceğinizi unutmayın. Özellikle start-up projelerde yeteri kadar bilgi toplamadan bu işe asla son noktayı koymayın. Bu önemli ve malesef halen çözüm bulunamamış bir konu. Çünkü eğer bir şirket sözkonusu ise çalışacak arkadaşın işe ihtiyacı olduğundan bu husuları belirtmiyor, işveren ise önemli görmediği için sormaktan / danışmaktan gerikalıyor.

    Türkiye’de herkes projesini Ebay, Amazon veya Google’a satacağını düşündüğü yada kendince “milyon dolar” bedel biçtiği için değişiklik yapmak konusunda canını verir, kurallarını değiştirmezler. Şirketler hep gelenden sonrada işlerin yürümesini ister ancak ne yazık ki, gidenlerin iş hayatlarının yürüyüp yürümeyeceği konusunda kaygı duymazlar. Bu yüzden her yazılımcı genelde isyankar modundadır ve ne yazık ki büyük bir oranı genel anlamda “X” birşeyden her zaman şikayetçidir. Çünkü ilişki baştan yanlış başlamıştır.

    Yazılımcıların eğitilmesi kadar ekip liderleri veya patronların bilinçlenmesi gerekiyor. Gerisinin kolayca geleceğinden, geliştiricilerinde ardından başarılı kafileyi takip edeceğinden gayet eminim.

    1. Tuncer Yıldız dedi ki:

      En az yazı kadar yararlı bir yorum olmuş, ellerinze sağlık.

      Başarılı olarak değerlendirilebilecek, en azından kod çöplüğü haline gelmemiş projelerin başarısının nedeni büyük oranda proje yönetiminin başarısına bağlı. İş bölümü, versiyonlama yönetimi, kod dökümantasyonu, kodlama standartları gibi konulardaki kararı yanlış planlanmış bir zaman çizelgesi karar vermeye başladığı an, üretilen herşeye çöp gözüyle bakmak mümkün.

      Yazılım üretimi planlaması yapabilecek tecrübe ve vizyona sahip kaç kişi var olduğunu gerçekten merak ediyorum.

  22. Huseyin Berberoglu dedi ki:

    Çok güzel yazı olmuş, eline sağlık.

  23. Sektorun derdini bilip ona gore kendimizi gelistirmek cok onemli gercekten de. Belli bir seviyeden sonra o bilgiyi satamamaniz cok normal. Kimse 10 kat iyi gelistiriciye (frontend, backend, sistem yonetimi, mobil programlama, photoshop bilen ve bu konularda iyi olan diye daha acik olayim) ihtiyac duymuyor cunku. Insanlara sadece “mobil programci” yeterli cogu zaman.

    Ben bu yuzden “full-stack developer” olmak yerine sadece belli bir alanda uzmanlasan programcilar olmamiz gerektigini savunuyorum.

    Onyuz gelistiricisi iseniz, sistem programlama ogrenmek cok isinize yaramayabilir. Ogrenecekseniz de “derdinizi anlatacak kadar ogrenip” ilerisinde gecmemek mantikli.

    Guzel bir yazi olmus,

  24. Benim hem anlamadığım ve hem de ilgi alanımda olmayan bir konu olmasına rağmen, makaleyi sonuna kadar okuyup bilgilenmiş ve oldukça beğenmiş durumdayım. Yazar Osman YÜKSEL’e ve benimle bu makaleyi paylaşan Osman Fikret CEYLAN’a teşekkürler…

  25. Hediyedi dedi ki:

    Merhabalar,

    Ayrıca, birden fazla projeye el atmak yerine her zaman tek projeye odaklanın. Bir şeye çalışın, ama sürekli çalışın.

    Teşekkürler.

Bir Yorum Yazın