Kaldığımız yerden devam edelim. Bu yazıyı kısa tutup, “in your face March mirmirik” diyelim.

En son “Yazılımcı / Uzman yazılımcı” konusunda ahkam kesmiştim. Bu konuda ve öncesindeki “Stajyer” ve “Jr. Yazılımcı” konularında yazdıklarımda hala haklı olduğumu düşünüyorum. Bu konularda fikrimi değiştirecek bir gelişme göremedim geçtiğimiz dönemde. Bu yazının konusu da “Teknik lider” ya da “Ekip lideri” adı verilen titre ile ilgili olsun. İçimi bir dökeyim. Oradaydım, bu işi de yaptım.

4. Teknik Lider, Ekip Lideri

Gerçekler: Ekip lideri / teknik lider kavramlarına bir açıklık getirmekte fayda var. Benim fikrimce, ekip lideri kod yazmayan, teknik konulara mümkün olduğu kadar uzak duran, daha çok ekibinin İK problemleri ve projelerin yürütülmesi ile uğraşan birisiyken; teknik lider tam tersine yazılımın mimarisi hakkında da söz sahibi olup, ilgili “core” kodları yazan, yazılımın ana şeklini oluşturan ve bu konularda da haleflerine yol gösterici olan kişidir. Evet, sevgili ülkemizde bu iki titre de ramazan çadırlarında dağıtılan yemeklere dönmüş olsa da, bu benim kişisel görüşüm. Yine önceki konuda belirttiğim, herkesin “senior olması” gibi kendisinden 1 ya da 2 yıl tecrübesiz herhangi iki kişi ile birlikte çalışan çoğu arkadaşım ya “ekip lideri” ya da “teknik lider” ve hatta çoğu zaman her ikisi birden oluyor.  Liderlik başlı başına çalışılması, üzerinde akıl yürütülmesi, ciddi anlamda “pişilmesi” gereken ve sosyal tarafı da ağır basan bir kavram iken hem ekibin hem de teknik gelişmelerin lideri olan arkadaşlar ile karşılaştıkça gözlerim doluyor (Tamamen yalan. Profesyonel bir empati yoksunu olarak hiç bir şey hissetmiyorum tabi ki).

Gereken: Benim, ekip ve teknik liderlik kavramları ile ilgili görüşüm şu şekilde görselleştirilebilir sanırım:

‘Teknik Lider‘ dediğimiz kişi daha çok ekibin içinde olan ve geliştirmeye de yardımcı, ‘Ekip Lideri‘ ise geliştirme ekibinin görev tanımlarının biraz daha dışındaki bir kişi. Tabi ki teknik lider iş birimleri ile konuşuyor ve tabi ki ekip lideri de geliştirme ekibi ile dirsek temasında. Ancak her iki işi de yüklenmeye çalışınca -ya da işte, üst yönetim tarafından yükletilince- işler sarpa sarabiliyor. Atılması gereken adımların çoğunun yönetim kademesinden gelmesine inanıyorum yine. Tamam, uzman yazılımcı arkadaşlar yine liderlik için kendilerini zorlasın ama onlardaki yatkınlık seviyesini ölçemeyen ya da farkına varamayan yönetim kademesinin sırf “title dağıtmak ile” geleceğe yatırım yapmadığını bilmesinde fayda var.

Kişisel eklenti: Çoğu zaman gördüğüm şu oldu. Şirkette uzun yıllardır bir projede çalışan arkadaşın niyeti/isteği/yeteneği göz ardı edilip sırf bir “title” vermek için, ekip lideri ünvanı veriliyor. Kadın (ya da adam) aslında teknik olarak profesyonel iken, üzerine bir de uğraşması gereken ve hiç de zevk almadığı onlarca İK problemi de ekleniyor. Bu durumun da iki çetrefilli derdi var. Teknik anlamdaki birisinin ne yazık ki “sosyal becerileri” biraz düşük olabiliyor (bende öyleydi diye herkeste olmak zorunda değil ama dediğim gibi: ‘gördüğüm bu’). Ekip lideri dediğimiz arkadaş da, proje yönetim, İK konuları, yönetimsel konularda doyurucu olsa bile, teknik konulara #muffinbey‘in kırmızı ete duyduğu sevgi kadar uzakta durmayı seçebiliyor. Bu konu da hem onun geliştirme ekibi içindeki saygınlığını yerle bir ediyor hem de ekibi olması gerektiği gibi yönetemediği için verim kaybına sebep oluyor.

Bugün yaptığım işten mutsuz olsam, ben kurumsal bir yere döneyim, her ay maaşımı rahat rahat alayım, emeklim/sgk’m olsun baş göz olayım, evlenip çoluk çocuğa karışayım bari desem “teknik liderlik” yapabilme kapasitem bunca yıllık iş birikimime rağmen yok örneğin. Bugün teknik liderlik yapabilecek durumda hiç değilim, çünkü “bilmiyorum”. Günümüzün teknolojik gelişmelerine çoğu yazılımcı arkadaşım kadar yatkın değilim ne yazık ki. Uzun yıllardır yazılım projelerinde “hands-on” görev almadım ve bu bana teknik bilgi anlamında çok şey kaybettirdi. Öylesine bir seçim ile, R, React, NodeJS, Python, jQuery kütüphaneleri ve/veya geliştirme dillerini, Docker/AWS yapılarının veya bu dillerin avantaj ve dezavantajlarını, küçük performans ipuçlarını kişisel olarak deneyimlemediğim için “teknik anlamda” ekipteki arkadaşlara çok şey katamam. Ama “ekip lideri” olarak hala işe yarayabilirim. Çünkü bu konuya diğerinden daha çok eğildim ve bu konuda kendimi de eğittim. Ekipteki hangi arkadaş erkek ya da kız arkadaşından ayrılmış, kimin evinde ev arkadaşı (ya da ailesi) ile ilgili bir problem var, hangi “manager” pozisyonundaki ekipteki kime ne şekilde baskı yapıyor, kimin iş yerindeki çay yapım saatleri ile ilgili bir sıkıntısı var sorularının cevabı bende olmak zorunda (dedikodu ile ilgili değil bunlar) ve bu konuların hiçbirisinin benim NodeJS sunucusunun nasıl başlatılabileceği ya da yeni bir Conda ortamının nasıl kurulabileceği ile ilgisi yok (zevkli konular, o ayrı).

Biterken çalıyordu:

The post Yazılımcı maskesini çıkarıp yönetici olmak / III appeared first on mirmirik.net.

Bir önce yazdığım yazıda, Türkiye’deki bir yazılımcının kariyer adımlarından Stajyer ve Jr. Yazılımcı konularında ahkam kesmiş, samimi özgeçmişimi de yazı içine ekleyeceğimi belirtmiş, azıcık içinde bulunduğumuz yönetim/sosyal çevre durumlarına çemkirmiş ve devamının Eylül’de geleceğini yazmıştım. Hakkında onlarca şarkı olan Eylül ayı geldiğine göre sözümüzde duralım o zaman. Hazır sözümüzde dururken de, şu çalsın arka planda(Rakı opsiyonel ama tavsiye edilir):

https://www.youtube.com/watch?v=ZFobOUv942k

Bu yazıdaki planım, bir öncekinde belirttiğim adımlardan “Yazılımcı” ve “Uzman / Senior yazılımcı” kavramlarını bir arada almak. Bu konuda biraz doluyum açıkçası. Sonrasında da “Teknik lider / mimar” ve “Takım/ekip yöneticisi” titrelerini kendi görüş açıma göre yorumlamak var aklımda ama bu büyük ihtimalle Ekim Mırmırık’ına kalacak. “IT Yöneticisi” ve “CTO/CIO” kavramlarını da Kasım Mırmırık’ına “sallayarak” üstümden atma niyetim var açıkçası. Bu arada şunu özellikle tekrarlamak istiyorum. Burada yazdıklarım sadece ve sadece benim görüşlerim. Ne benim çalışma/işbirliği ya da ortaklığı yaptığım şirketleri ve çalışanlarını, ne önceden çalışmış olduğum şirketleri(ve çalışanlarını) ne de eş/sevgili/eski sevgili/tanıdık/dost/akraba/arkadaş/komşularımı bağlar. Tüm fikirler, kişisel deneyimlerim ve görüşlerimdir.

Neyse…
Başlayalım!

3. Yazılımcı / Uzman yazılımcı

Gerçekler: Bu iki ünvanı birleştirme sebebim aslında Türkiye’de (özellikle son iki yıldır) ‘yazılımcı’ bulamamam ile ilgili. Herkes ya çok işin başında(Jr.) ya da çoktan uzman seviyeye(Sr.) erişmiş durumda! Arada kalan bir arkadaş yok! Bir zamanlar ünvanım öyle gibi görünse de, geçmişime baktığımda kendimi bir konuda “uzmanlaşmış” göremiyorum nedense. Yönetim kademesine adım attığımda, kendimi geçmiş işlerim ile ilgili “uzman” sanmam büyük bir yanılgıydı. Şu anda gördüğüm de bir çok yazılım geliştirici arkadaşta aynı durum söz konusu. Aynı şirkette 1-1.5 yıl geçirmiş bir çok kişi maaş görüşmeleri ya da yeni iş görüşmelerinde mutlaka “uzman” olarak devam etmek istiyorlar. Bunun suçunu da ne yazık ki yine ikiye bölüyorum. Hep o şikayet konusu olan Y ve Z kuşağı ile şirketlerin yönetimsel beceriksizlikleri. Türkiye’de şirketlerin bir çoğu hala 1970 kuşağındaki babalarımızdan gördüğümüz şirket yönetim anlayışında işliyor. Üzgünüm ki, buna yazılım şirketleri de dahil. Y veya Z kuşağının anlayış / beklenti veya yaşanmışlık farklılıklarını hesaba katmadan, sadece daha fazla para ve “ünvan” ile şirket bağımlılığı yaratabileceğini (hala) düşünen yüzlerce şirket yöneticisi var. Aynı şekilde, Y/Z kuşağındaki arkadaşlar da bir önceki yazıda anlattığım gibi stajyerliğini “çakma” yaparak, Jr. döneminde sadece ezbere dayalı, iki Google araması ile çözülecek sorunları çözerek geçirmiş olmalarına rağmen kendilerini bulunmaz hint kumaşı sanıyorlar. Şu karikatür için -her ne kadar işvereni haksız görsem de- özür dileyemeyeceğim arkadaşlar…

Gereken: Yazılım süreçleri danışmanlığı yaptığım bir şirkette, “Dünyanın parasını döküyoruz, adam/kadın hala ‘o iş öyle olmaz’ diye itiraz ediyor” cümlesini duydum. “Improvements” konu başlığında yönetici aleyhine “kırmızı” madde olarak yerini aldı. Bir yönetici olarak bana gelen “o iş öyle olmaz” itirazı, en güzel ve en yerinde tartışma konusu aslında. Çünkü bu sorunun karşılığı olan “nasıl olur peki? İkna et beni” cümlesinin karşılığını verebilecek bir uzman yazılımcı varsa, o kişi aklı çalışan birisidir. 10 yıl boyunca C# yazmış olması bir kişiyi uzman yapmayabilir. “İkna edebilir misin beni?” sorusunun karşılığını ne kadar verebildiği ve ne kadar veriye dayalı ikna kabiliyeti olduğu belli eder uzmanlığını. Bir konuya veriler ile itiraz edebilmek, düşünebilmek ile ilgilidir ve yazılım uzmanlığı aslında herhangi bir programlama dilinde kaç yıldır kod yazabildiğiniz ile ilgili değildir. O yıllar sadece, o spesifik dildeki uzmanlığınızı/ezberinizi gösterir. MS Word kullanmak gibi düşünün(ben asla MS Word ya da MS Excel uzmanı olamadım örneğin [denedim!]. Hala içinde hem “portrait” hem de “landscape” sayfalar olan doküman yaratmakta ya da özel bir pivot oluşturmada Google araması yapıyorum).

Bir problem karşısındaki çözümü değerlendirebilip, o çözümün uygulamaya ne kadar uyabileceğini tartmak, araştırma yapmak, veriler üzerinde analiz yapmak, sonuca varmak, o sonucun işe yaramayacağını görebilmek ve işe yarar bir alternatif çözüm üretebilmek; her uzmanlıkta olduğu gibi, “yazılım uzmanlığı” ünvanında da değerlidir. Bu değeri bir de “itiraz edebilme cesareti” ile birleştirebilirseniz, uğraşınız sizi “Teknik Lider”liğe de hazırlar. İnce noktayı bir daha belirteyim ki “abi ben de mükemmel itiraz ediyorum da, kovdular yahu” tarzı mesajların önüne şimdiden geçeyim. İtiraz noktasının sonrasında gerçekten ispatlanabilir, bilimsel metodlar ile gerçekliği gösterilebilir veriler sunabiliyorsanız anlamlı ve mantıklı olursunuz. Diğer türlü her şeye itiraz eden huysuz şirinden farkınız kalmaz. İki ünvan öncesine dönersek, matematik ve algoritmalar konularına eğilmeniz gereken zaman ile ilgili hala bir şeyler yapabilirsiniz. Okuyun, araştırın, meraklı olun ve öğrenin. Yüzlerce ücretsiz internet kursu, binlerce ücretsiz kitap var internette. Aklınızın gözünü açın. Okuyun, araştırın ve öğrenin lütfen. Bu zamandaki üniversiteler tabi ki “öğrenme” ve “sorgulama” konularında basiretsiz kalacaklar üst otoriteye biat ettikleri yüzünden ama, geleceğinizi düşünüyorsanız tek düşünceye esir olmayın, soru sormayı, aklın ve bilimin yolunu bulmaya çalışın. Önümüzdeki yüz yıl geçmiş fantastik hikayelerinin değil, aklın ve bilimin yüz yılı olacak. Kendinizi buna göre hazırlayın.

Kişisel eklenti: Kendimi “yazılım uzmanı” olarak gördüğüm zamanlar sanırım proje yönetimine geçiş öncesi dönemlerime rastlıyor. 2005-2007 gibi işte. Her şeyi en iyi bilen, assembly ve pascal dillerinde kod yazarken, internetin TR’de doğuşuna şahitlik etmiş bir yazılımcıydım sonuçta. Backend – frontend – DB – tasarım ve mimari konularında sabaha kadar tartışabilecek bilgiye sahiptim. Byte değil bit hesabı yapıyordum kullandığım değişkenlerde. Onlarca proje başarmış, bir yarısı kadar da batırmıştım (proje batırma konusu ayrı yazı konusu olsun, çok değerlidir). Bu etrafta gezinen proje yöneticileri ve / veya ekip yöneticileri ne iş yapıyorlardı ki gelip benimle “iş” konusunda tartışma cesaretine sahip olabiliyorlardı…

Şu anda düşündüğümde, tabi ki bu fikirlerim komik geliyor. “İş” konusunda bilgim o kadar azdı ki… Teknik konulardaki bilgilerim ne kadar yüksek olursa olsun, iş konusunda kocaman bir sıfırdım ve “iş” için çok farklı disiplinlerden, çok farklı şeyler öğrenmem gerekiyordu. Bir değişkenin bellekte tutacağı yerin bir “word” ya da bir “bit” olmasını bilmek, 6 ay sonrasının getirilerindeki “forecast” değerleri için çok da önemli olmayabiliyordu bazı durumlarda. Ben ise “forecast” kelimesini duymuş olmama rağmen, yeni öğreniyordum… “İş” öğrenmem gerekiyordu, işi öğrenmem için ise kendimi biraz daha pişirmem ve “teknik ekip lideri” pozisyonuna koşmam gerekiyordu.

Geri kalan hikaye ve görüşler Ekim Mırmırık’ının olsun (“in your face October Mırmırık” diyeyim ben de Ağustos’taki gibi.)

Biterken çalıyordu:

The post Yazılımcı maskesini çıkarıp yönetici olmak / II appeared first on mirmirik.net.